Academic Software Request Process for the Information Commons

Draft: 23 May 2007

Please address comments on the draft to ic.software@anu.edu.au

The notion of the Information Commons is one of a connected virtual space in which learning, research and teaching can occur. The computing equipment provided by the Division of Information within the libraries and tutorial rooms provides the physical infrastructure for staff and students to participate in the Information Commons. As technology changes so too will the infrastructure provided.

At present the University has determined that the best way to facilitate this access is via desktop computers. To meet this need, the DOI has currently provided 1200 desktop computers that are comprised of 900 Intel PC and 300 PPC or Intel Macintosh systems.  It must be emphasised that the number and composition of machines is under constant review and is subject to change.

The software on these desktop computers provides the tools to enable the most effective use of the Commons.  The software facilitates communication between staff, students and the wider research communities.  The software and the hardware together provide the enabling technology for research, learning and teaching to occur.

These desktop systems and the backend support systems are colloquially referred to as the IC computers.

In an ideal world there would be unlimited access, unlimited computational power and every software title ever made readily available within this space to all staff and students. The real world unfortunately is bounded by physical and financial limitations. It is therefore necessary to identify a core set of software that will provide the greatest functionality and the least impediment to academic success within the Division’s and the University’s resource base.

The Division of Information maintains a set of core software, for the benefit of the University community, through a consultative process on the IC desktop computers.  As part of this consultative process academics and students are able to request software that they believe will assist in research, learning and teaching. Given the budgetary restrictions on the DOI not all software requests can be fulfilled and a process for determining academic need and impact must be undertaken with the community.  In cases where software is required for a specific purpose (i.e. teaching a single course) and is expensive or will have limited use, the Division may enter into an agreement with a local area. Options are available, from simply managing the software on IC desktop machines (at the expense of the local area) through to the creation of a cost sharing special facility where the support, software and potentially the hardware is tailored to the needs of a local area.

It is against the above context that the following procedures and process have been developed.

Software Requests

Software requests may be submitted at any time via the web form at http://diana.anu.edu.au/, email to ic.software@anu.edu.au or though the DOI liaison officer for your local area. In addition to this the DOI will send out periodically a “call for software requests”, with instructions, as a reminder to all academic staff.

Over 70% of all software requests are successfully deployed into the IC. Of that 70%, 90% of the software requests are processed and successful deployed to the User Acceptance Testing (UAT) IC desktop computers within 90 days by DOI. The exact length of time for any one particular request will vary due to a number of factors, some of which are beyond the control of DOI.  Regardless of how long the process takes, the software requester will be kept informed of their request and will be notified as it progresses through the approval process.

Many of the requests we receive for software applications are from lecturing staff that would like to make a particular piece of software available to students studying their course.  To help ensure that requested software is available for start of teaching in a particular semester, the DOI publishes a schedule of dates by which requests should be received.

NOTE: Requests for software received by these dates are given priority but cannot be guaranteed to be available. Lecturing staff must monitor their requests and are advised to  have a contingency plan should the software not be available.

Academic Needs Analysis

All software requests go through this initial analysis to determine the academic need for the software, to identify a funding source and to assign an internal priority for technical analysis.

If you have not already provided the information via the web form, you will be contacted for the following details:

• Software title and version requested
• Known alternative titles (should the requested software not be suitable or unavailable)
• Number of students (for a course related) or Expected number of users (for non course related)
• Expected usage – daily, weekly, monthly etc
• Expected number of concurrent users
• Priority location for deployment 
• Date required
• Period software is required  (Maximum allowed is 12 months before review)
• Funding source (if known or available)
• Academic Impact  (self rated)
• Alternative contact

The “Academic Impact” is an attempt to gain a measure of academic importance placed on this software to the University business.  It does not guarantee funding nor it’s availability in the IC. It is used purely as internal measure to help set priorities for the technical analysis phase and as an internal alert/impact measure should the software fail in production.

To assist with selecting the correct academic impact, the following definitions have been provided:

Critical -         Research unable to proceed or there is a legal requirement for software. No teaching application can be given this rating.

High -              Teaching severely impacted.  Software needed to teach course and is required by students on a daily basis.

Important -     Research or Teaching heavily impacted. Software needed for regular weekly tutorial.

Medium -        Research effectiveness impacted or Teaching impacted.  Software used for 1 – 3 sessions in a course.

Low -               Minor teaching impact or generic request. Typically software is used only once in a course, or nice to have available.

Once this information has been collected, the DOI attempts to source the software, determine the licensing arrangements and obtain a quotation for the software.

This part of the process typically takes about 2 weeks but may take significantly longer if we are unable to contact the software vendor.  Should the process take longer than 2 weeks you will be contacted and then given weekly progress updates.

Reasons for NOT proceeding with requests at this stage will fall into 4 categories:

• Abandoned by requester  – e.g. software unavailable, vendor gone out of business etc.  After consultation with DOI staff a decision is taken by the requester not to proceed.
• Abandoned by DOI – process has taken 2 months and DOI have been unable to contact requester or the alternative contact that was provided
• Software licence restrictions
• No source of funding identified.

An automatic alert based on price will be triggered if it has been identified as costing greater than $50 per student for a course and/or greater than $5,000.  The requester will then be contacted and asked if they wish to proceed.  The reason for this is that it is unlikely that the DOI would fund this software without some local contribution.

The DOI level of co-funding for any software, above or below the limits above will be assessed on a case-by-case basis.  Approval at this stage of the software request process does NOT commit the DOI to funding the software.

At the completion of the Academic Needs Analysis a decision to proceed or not will be taken. Either way the requester will be given a report summarising the information and the decision taken.  Successful requests are then moved to the technical analysis phase.

Technical Analysis

The technical analysis phase of the process test the software application’s suitability for inclusion within the IC software image.

The chance of an application not working well is higher on these computers, compared to what it might be on your home or office computer. This is because of the complexity of the systems (there are more than 100 applications installed on each computer) and the need to have them tightly secured in this shared environment.

The IC software image is the complete collection of software that is installed onto an IC desktop computer.  DOI maintains a base software image and a number of specialist images that are deployed automatically to IC desktop computers based on academic requirements.  Each piece of software installed as part of the image needs to be packaged. Packaging software allows for the software to be installed and removed remotely and for updates to the software to be incorporated.

Each piece of software therefore needs to be tested to see if it can be packaged.

If a software application cannot be packaged, then it is not possible for the software to be installed on an IC machine.  The DOI does not have the resources available to physically install software on each individual machine. Additionally, manual installation of software onto an IC machine can adversely affect the management of the other software on the system.

Packaging of software is not a simple process and the interactions between all the installed software packages needs be investigated.  For instance, installation of one application can affect shared files used by another application rendering one or both pieces of software unstable or unusable. In some other cases the order in which applications are installed can affect the stability of the entire system.

Over time the staff have become skilled in various approaches to packing an application and maintaining stability of the system.  Due to the large number of software vendors and title, there are no simple recipes to packaging and each piece of software will have its own peculiarities. As a consequence there are no hard and fast rules to determine how long or even if a particular application can be packaged. Timings range from a few hours to weeks and even months for some specialist applications.

In general the various methods attempted to package an application are not communicated back to the requester due to the complexity and being conscious of not bombarding the requester with potentially irrelevant information.  (Details can be made available if requested.)  The requester will however be informed when work commences on their application and they will be given a basic update on how the process is progressing on a weekly basis.

If an application is determined to be technically infeasible, the request will be abandoned and a report sent back to the requester.  IF an alternative application was suggested as part of the original request, this alternative application will then be tried. The alternative application would be started as if it was a new request and will go through academic needs analysis and the technical analysis phase.

User Acceptance Testing

User Acceptance Testing is an important final phase for the deployment of software.  The DOI staff will test the basic functionality of software as part of packaging the software.  It should be noted that DOI staff are not expert users of all applications and so must rely on the requester testing the application thoroughly.  The software requester will be contacted and a time arranged for the requester to test the application.  As part of the UAT, the requester needs to test the application with the appropriate datasets and verify that the software behaves as expected.

If the application does not work, the errors are noted and DOI works with the requester to resolve the problem.

NOTE: If problems are discovered with the application AFTER it has been deployed, a helpdesk job needs to be logged and it is prioritised appropriately.  In general application problems cannot be resolved quickly and may take a significant amount of time to fix. It is therefore in your interests that software is thoroughly tested and all issues resolved during the UAT phase before signing off.

Applications can only be moved onto the IC computers once all requesters have signed them off as working. UAT sign-off will therefore need to be done at least 72 hours before the software is required, to allow sufficient time for it to be deployed.

When the requester has approved it, the software application is ready to deploy and is included in the next scheduled update.

Once the software has been successfully deployed, the software request process is complete and a final report is generated and sent to the requester.

Requesters should be aware that updating the version of an application would not generally happen unless the deployed software has been configured to update automatically.  The only exception to this is the installation of security related patches that will be automatically installed to preserve the integrity of the machine.

Within 3 weeks of the date that the request was closed (whether or not it was implemented) you will be contacted to complete a survey as part of the quality control process. Your cooperation in completing this survey would be appreciated as it is one our primary feedback mechanisms to improve the process and end user experience.