Installing & Customising Software

Installation | Customisation | Customisation Challenges | Packages | PDF Tools

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 repositories lifecycle giving approximate timescales for each phase.

Gantt chart showing relative time scales for introduction of repository software service
	Planning Phase
	Pilot Phase
	Customisation (this is dependent on how much the institution wishes to diverge from the default software)
	Production Phase
	Support Phase

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 projects 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 dependant 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 setup at the institution. IT departments will often prefer to choose similar hardware to the current systems. It is not uncommon for the repository may 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

Requirement s 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 project 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.

Pilot Installation & Configuration

When installing and configuring a new repository, it is often good practice to have a pilot installation which is used as a test bed for a repository development with adversely affecting a live installation. In project conception, a pilot system will be used to tweak and configure the software, perform system testing and initial user acceptance testing until the repository is at a stage to be used as a production system. In latter stages of the repository lifecycle, the initial pilot installation will often grow into a development platform which can be used for testing upgrades and patches before applying them to the live institutional repository.

Pilot System Testing

System testing exists to iron out any bugs which may be prevalent in a new repository installation before it becomes a live service. It is prudent to dedicate a significant amount of time to system testing to ensure the service offered to users is as trouble free as possible. Bugs that are found in live systems will often cause agony to a user and can ruin a systems reputation.

Pilot User Acceptance Testing

In contrast to system testing, user acceptance testing on a repository is performed by the people who will use the system on a day to day basis, ensuring it meets with their requirements. Feedback from a subset of the users who will use the repository can be used to ensure that flaws and missing features can be rectified before the system becomes live.

Production Installation & Configuration

Once the pilot system is in a stable state and key stakeholders are happy with the repository, installation and configuration of the live system can take place. This phase of the repository lifecycle should be straight forward providing subsequent stages of the pilot installation where performed correctly.

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.

Production System Testing & User Acceptance Testing

Once the production system is live it is still important to perform both system testing and user acceptance testing to ensure bugs haven’t crept into the repository when moving from the pilot system to the production system. As the repository becomes live and is opened up to a greater user audience, there is a good chance that bugs will be found which may not have been identified in the pilot system.

Repository Roll-Out

Providing all the phases leading up to the repository rollout 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 obviously desirable for institutional repositories to be clearly branded as belonging to a particular organisation, after all the efforts that have been made on its behalf to retain a portion of the institutional IPR. 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. OpenDOAR and ROAR are good sources of suggestions for appropriate, and in some cases confusing, names for an institutional repository.

However, it is notable from audit work conducted for OpenDOAR that there is a split between clever acronyms and blandly functional nomenclature. While there is perhaps arguable marketing capital in utilising an imaginative acronym or title, a functional approach has been generally taken by members of the SHERPA Partnership for example.

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 kind of issues the best advice is meticulous documentation both within code or scripts, and if at all possible in off-line documents as well.

In many cases the introduction of a local recipe, or 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.

Specific Packages

There are number of repository software packages available, of which the most popular worldwide are EPrints and DSpace. Another name that people will have heard of is Fedora. Specific up to date installation instructions for each of these solutions can be found on the vendor’s homepage.

PDF Tools

[Information to follow.]