Installation and Customisation

Installation

Although software installation procedures can vary between repository platforms many of the initial steps prior to installation are similar. Technical staff and repository administrators should be aware of steps such as checking technical requirements of the software, understanding installation instructions, user and system testing, migration from development to production platforms and backup strategies. This list is by no means exhaustive but highlights some areas that should be considered. The Gantt chart below gives an indication as to some of the areas a repository team should consider throughout a repository's lifecycle giving approximate timescales for each phase.

Gantt chart showing relative time scales for introduction of repository software service

Planning Checklists

Planning checklists are used to identify the key phases in a project lifecycle. The use of a planning checklist allows the team to focus on what goals/targets need to be completed in order for a project to run successfully. The above Gantt chart is a common method that is used by managers to illustrate the phases, activities and dependencies of a software project's work breakdown structure.

Project Scope Analysis

Defining the scope of a project is often a critical part in the project lifecycle. The scope defines what the project aims to achieve throughout its lifecycle and can be used as a marker at the end of a project to determine if the project outcome has been successful. It is often useful to define a mission statement which defines areas like; project deliverables, project objectives, project assumptions and project constraints.

Hardware Solution

Choosing the correct hardware for a repository installation is often dependent on a number of factors. Some of the overriding factors that will often determine the hardware route an institution takes are listed below:

• Current hardware set-up at the institution. IT departments will often prefer to choose similar hardware to the current systems. It is not uncommon for the repository to share resources with other institutional systems
• Available funding for the repository will have an effect on what hardware can be purchased
• Estimated usage of the repository. Is there a large storage requirement? Is there a need for a high performance, resilient solution?

Requirements Specification

Requirements specification involves identifying the conditions that the repository solution must meet to satisfy the various users or stakeholders of the system. This can be a very time-intensive phase in the repository lifecycle. It is important to capture the requirements precisely during this phase of the project as the success of the repository will often depend on the accuracy of the requirements. In many software projects requirements analysis can be broken down into:

• Requirements Gathering (determining the requirements of the users of the system)
• Requirement Analysis (analysing these requirements, resolving issues, determining use cases)

Supporting Software Installation

Repository software such as DSpace and EPrints often require additional third party software to be installed on hardware before installation of the repository can take place. It is important to schedule supporting software installation into the software lifecycle and make provision for any issues you may encounter while installing these supporting systems.

Backup Strategy Implementation

A good backup strategy is essential to ensure the repository is protected against unforeseen events whether this is for disaster recovery or to restore files which may have been accidently deleted or corrupted. For many organisations backing up the repository may be a simple case of incorporating the repository backup into the institutional backup strategy. Whatever method is chosen it is important that regular checks are performed to ensure data can be recovered in the event of a problem.

Repository Roll-Out

Providing all the phases leading up to the repository roll-out have been carefully considered and completed successfully, the rollout of the repository across an institution should be free from issue. Repository administrators and IT staff should be prepared to field questions regarding the repository and in many cases my need to provide hands on support and training.

Maintenance

Throughout the project lifecycle the repository will require maintenance, whether this be to fix a bug, install a new patch or feature request or upgrade to a new version of the repository software. It is important that major changes be made to the development system before modifying the live system. In this way, if any changes cause issues in the development system, the live system will still be operational. System maintenance is part of any software lifecycle and IT staff need to be aware that support for the repository does not end when the software is rolled out.

Production Customisation

It is desirable, given the efforts that have been made on its behalf to retain a portion of the institutional IPR, for institutional repositories to be clearly branded as belonging to a particular organisation. Basic issues include picking an appropriate name, including the institutional logo and visual identity, and in some cases incorporating the local standard full web template.

Customisation challenges

There are risks when customising your repository interface such as losing track of changes or problems encountered when upgrading your software. To avoid these kinds of issues the best advice is meticulous documentation both within code or scripts, and, if at all possible, in offline documents as well.

In many cases the introduction of a standard operating practice when it comes to introducing changes will aid in the integration of new technical or administrative staff, as well as protecting against issues around staff succession and replacement. Hosting a mirror test server where new implementations or changes can be introduced and any issues explored before going live is a simple but effective route to trouble free upgrading.