You are here

Projects Database replacement

Project ID: 
204
Current stage: 
Manager: 
Unit: 
What: 

Description: Replace the existing UG4/MSc project tracking database with a more integrated and maintainable service.

Deliverables:

  • Data to be mastered in (or with significant reference to) the School database.
  • Functionally identical replacement of the existing interfaces.
  • System to be free of existing data integrity issues.
  • Modifications to ensure all administration can be performed by project coordinators.
  • Single structure allowing data to be partitioned and functional behaviour to differ by both cohort and academic year as teaching requirements change.
Why: 

Customer: School of Informatics. The service will be used by teaching staff, teaching support staff and students.

Case statement:

The projects database was based on code provided by an undergraduate student some time around 2004. It was likely designed as a quick stop-gap, and required complete reconstruction each year, duplicating not only all working data but also its codebase. The system was, as a result, profoundly unreliable, unmaintainable and unsafe.

The system was taken on by computing support in 2006 in order to achieve several urgent goals of reducing the linear maintenance expansion and adding some form of secure authentication and authorisation, as well as a degree of stability. Maintenance has been ongoing since and, though hugely improved, even minor functional changes (as required by teaching policy) often have knock-on effects which risk availability and integrity of data, so maintenance continues to be expensive.

Additionally, much of the data stored in the projects database is unnecessary as it is (often inaccurate) duplication of data mastered in the School database. Administrative load could be reduced by integrating this data store.

When: 

Status:

  • The project deliverable will replace a working (albeit fragile and expensive) service.
  • Other portions of project administration are already becoming integrated with Theon, reducing data duplication elsewhere.
  • Maintenance of the system typically required every year, and is comparatively expensive as it almost always entails multiple changes throughout the system.

Timescales: Not entirely known. Basic functionality is very simple indeed, but the administration interface is surprisingly powerful and adapting the system to be an integral part of the school's wider data model is complex.

The transition should take into accoun

Priority: TBC. Points to consider in 'status' above.

Time:

Estimates:

1-2 weeks evaluation, (new) requirements capture, basic prototyping

3-4 weeks production code development and testing.

1-2 weeks QA, testing, extended requirements (if time). Extensive user documentation.

(FTE necessarily

How: 

Proposal:

Evaluate possible technical solutions and, in parallel, discuss existing requirements with those concerned, eliciting official procedures which are not always clear in existing system. (Note that additional requirements will almost certainly be generated at this stage; these might influence development but should be addressed separately.)

Implement integrated data model within Theon

(re)implement interface according to evaluation.

Resources:

  • CO time
  • An apache web server (host need not be dedicated)
  • Access to school database
  • [desirable] Working knowledge of school database
  • [desirable] Knowledge of typical user and data interactions of the system

Plan:

Implementation plan to be developed as part of project: see proposal.

Rework data model to integrate with Theon and reduce re-keying. Develop scripts to safely transfer project data into new model.

Develop new framework, then replicate functionality of each existing form or report into new framework.

Other: 

Dependencies:

The new project will depend upon, and interact (to a presently undefined degree) with, the "Theon" school database service.

Some "Webmark" forms depend upon the data provided by this service.

Various internal web pages and policy documents refer to project site URLs
representing views of the projects data. Consideration should be given to maintaining current URLs and notice given of any deprecation.

Risks:

Risk of overrun due to personal underestimate or conflicting demands - not disastrous, as slippage simply mandates extended use of existing system.

Risk of dangerous interactions with Theon - to be specifically guarded against.

URL: https://www.dice.inf.ed.ac.uk/units/rat/documentation/unit/projectsdb.html

Milestones

Proposed date Achieved date Name Description