DICE development projects - gdutton

Unit:

What:

Description: Produce a VM Image which allows a variant of the current DICE Lab Exam environment to be provided on non-DICE hardware.

Deliverables:

Secure VM Environment on IS Labs

Secure VM Environment on DICE lab desktops

Virtual Machine Image which can be deployed to both of the above

Backend on DICE servers which allows existing exam functions to work with the above

Why:

Customer:

Case statement: As class sizes exceed lab capacity and the popularity of the lab-exam format for assessment increases, it will be necessary to find a mechanism to allow all students to take an exam simultaneously in a way which does not disadvantage any students.

When:

Status:

Timescales: Preferably in time for next year's mock exam diet.

Priority:

Time:
A rough estimate follows.

Notes:

The requirement to perform much of this work offsite and in collaboration with other schools will contribute to latency and effort, the latter of which is hopefully accounted for here.
The below does not include CSO time which should be assumed at approximately 25% of the defiend FTE for starred* and 50% for double-starred** items.

1-2 FTE weeks image creation
3* FTE week image application management, of which
1. 1 wk initial environment creation
2. 2 wks application / environment management tools
2 FTE week redevelopment of paper retrieval / submission tools
3 FTE week redevelopment of server-side tools, of which:
1. 1 wk support of paper retrieval / submission
2. 2 wks logging, backup and recovery mechanisms
3-5* FTE week image deployment and runtime mechanism, of which:
1. 1-2 wk DICE lab deployment incl. redevelopment of "Exam Mode"
2. 2-3 wks IS lab deployment
3-5** FTE weeks testing, of which
1. 1-2 wks (lab / firewall) security testing
2. 2-3 wks procedural and application testing

Risks to the above lie in assumptions made on:

Virtualisation technology
Chosen OS / release for exam image
Ability to achieve parity with teaching software requirements
??

How:

Proposal:

Resources: Will require significant CSO time to assist in physical lab configuration
Will require IS' CO time for IS lab consultation and configuration

Plan: See time below for the rough outline.

Url: https://wiki.inf.ed.ac.uk/DICE/LabExamsVirtual

Other:

Dependencies: IS Public Lab environment.

Risks:

Risk that one or more of the given environments cannot be secured adequately

High risk of unforeseen obstacles on IS equipment given our lack of knowledge in this area

Risk that IS cannot devote the effort required

Risk that project costs more than the repeated setting of multiple (staggered) exams

Risk the development overruns past exam setting / sitting deadlines

Milestones

Proposed date	Achieved date	Name	Description

Tutor Allocation Management

boss — Fri, 25 Jan 2013 15:46:17 +0000

Project ID:

208

Current stage:

0_Pending

Manager:

Unit:

What:

Description: The reduction in funding for PGR tutors will result in a change in procedure in allocating tutors to courses. The new process would be more streamlined if it was run through a set of web forms that could use data from Theon and update information held in Theon directly.

Deliverables: Probably a set of Webmark forms integrated with Theon.

Why:

Customer: ITO/ISS

Case statement: The new process for managing tutors will be more administratively heavyweight, web forms and direct database update will reduce the impact. Theon already has the data structure to support tutor allocation and contracts and it would seem simplest just to extend this slightly to support the new application process.

When:

Status:

Timescales: In place for June/July?

Priority: The ISS will need to adopt a paper based system without this.

Time: 2 FTE weeks (on the assumption that the Webmark revamp provides the necessary framework for the web forms themselves).

How:

Proposal:

Resources:

Plan:

Other:

Dependencies: Depends on Webmark revamp, which will provide very lightweight user web forms that are Theon integrated.

Risks: Insufficient effort to complete Webmark revamp (if that is even prioritised).

Milestones

Proposed date	Achieved date	Name	Description

Projects Database replacement

boss — Fri, 25 Jan 2013 15:46:16 +0000

Project ID:

204

Current stage:

1_Proposal

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

Webmark Reform

boss — Fri, 25 Jan 2013 15:46:16 +0000

Project ID:

205

Current stage:

1_Proposal

Manager:

Unit:

What:

Description: Enhance the existing 'Webmark' service, partially in response to recent requests, to produce a more general-purpose form generation and submission system, to be known as 'Reform'.

Deliverables:

A refreshed version of the existing Webmark service which functions similarly to the existing one.
Additional core functionality such as field validation, multiple data sources, chained inputs and outputs.
Generic input, output, form source APIs.
Allow external sources to define form contents.
Configuration format reworked to act as complete form descriptor (where appropriate)
Draft form storage
Session change handling.
All forms to be converted to new configuration format, or full support for legacy configuration
Project choice agreement form, if still required
Partial delegation of form structure to authors

Why:

Customer:

School of Informatics; Computing Support, Undergraduate and Graduate offices.

Features typically requested by members of the teaching offices, with input from academic staff.

Case statement:

New forms and features of the additional forms are now being requested by members of academic and teaching staff, and the existing Webmark framework can no longer cope easily with these changes.

For the past four years, most new forms have demanded some new functionality of the system, and while most could be integrated neatly, others were bolted on hastily and have demonstrated a limit to the flexibility of the core of the system. Continued augmentation is now difficult to do in a safe and clear way, and in particular integration with established School Database systems, which would save considerable effort for administrative and academic staff in teaching duties, is difficult. Requests continue, in particular a new requirement for a "project choice agreement" form which requires more complex interaction with school data, and demand for additional features continues to be expressed by ISS and teaching staff.

Furthermore, form configuration is straightforward at present, but enforces limited functionality. Without redevelopment, existing form commitments cannot be fulfilled in their entirety and future additions and modifications will be comparatively expensive and error-prone.

When:

Status:

Webmark was originally developed in 2007 as a means of generating the multiple paper marking forms required by both College and School for final-year undergraduate and MSc students. The initial design specifically limited the scope of the project and the first revisions met the requirements well.

The existing Webmark service continues to function reliably and allows the straightforward addition of new forms where the demands of those forms do not differ from existing ones, however new features become increasingly difficult to add to the existing structure.

Requests both for additional forms and extended features of existing forms have been pending for some time.

Timescales:

New form configuration is always ongoing and will likely be performed in parallel to development of the new service. The sooner the service is redeveloped, the more customer time will be saved.

Focus on this work will be affected by high-prior

Priority:

Time: Estimates:

~1 week to plan architecture for core
~2 weeks to fully rework core including
~1 week to reimplement dropped core features in new API
~1 weeks to refactor existing I/O and to add new modules
~2 weeks documentation, testing, support training

How:

Proposal: To follow the plan according to the description to provide the deliverables within the specified time.

Resources:

CO time
One Apache-capable DICE server (already exists)
Access to the school database

Plan:

Produce architectural overview, recommending development options.
Reconfirm requirements and pending augmentations of existing forms.
Work out wider picture wrt database connectivity.
Rework / rewrite core to allow full extensibility. Augment core with new functionality as required. Remove functionality where it can be provided in a more generic manner.
Rework inputs / outputs to use new core API
Document APIs and configuration format.
Evaluate form drafting functionality, potentially as generic input/output.
Add new input/output modules. Ensure these are self-documenting at a level usable by form authors
Adapt existing forms to new format (possibly delegated)
QA against existing form output

Other:

Dependencies:

Forms depend upon the "Theon" School Database , the Projects Database (though see project sortable list"; also utilises the ISS Request Tracker system.

At completion, expected to continue to depend on both the School Database and the ISS RT. Non-submission data (for example, for form coordination) might reasonably be expected to rely on a dedicated database.

Risks:

Usual risk of slippage.
Semi-public service: security of input to receive extra attention.
Insufficiently flexible redesign will be no more adaptable to customer requests.
Overly flexible redesign will be too complex for authors / support to administer.

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

Milestones

Proposed date	Achieved date	Name	Description

JEdit ML Interface enhancements

boss — Fri, 25 Jan 2013 15:46:02 +0000

Project ID:

142

Current stage:

Manager:

Unit:

What:

Description: MRG have developed an interface for working with PolyML, called the IDE-mode.
A prototype plugin for jEdit has been developed which allows exploration of type information, etc across this interface. The project is to further enhance this plugin, adding, for example, formatting of PolyML's output buffer. This project will involve close working with Lucas Dixon, who developed much of the prototype plugin.

Deliverables: A simple interface widget for the PolyML jEdit plugin developed by Lucas; basically a simple HTML-like panel which can present status / error messages from the ML process.

Why:

Customer: Lucas Dixon, for CISA.

Case statement: This project was created to use left-over effort owed to the customer. It is necessary to spend this time in some way.

When:

Status: Not started, though effort has already been paid for.

Timescales: One month of CO time, from 20th November 2009.

Priority: TBC. Effort already paid for.

Time: See 'Timescales'

How:

Proposal: See 'Deliverables'

Resources: Nothing special, though Lucas has requested use of a spare desk in his office for closer working.

Plan: See 'Description'

Other:

Dependencies: Lucas' time, which is to be dedicated to the project for the duration.

Risks: Slippage due to urgent CO operational tasks.

Entering predicted pandemic season.

URL: http://dream.inf.ed.ac.uk/projects/polyml/

Milestones

Achieved date	Name	Description
2009-11-21	environment	Download all relevant sources and code, and run the plugin as-is. Figure out toolchain for plugin development.
2009-12-10	code	Most code should be in place, and a working prototype with appropriate bug / enhancement list in place.
2009-12-21	Complete	Project should be complete; all effort will have been spent.

JavaMC - Proof-carrying Java Code

boss — Fri, 25 Jan 2013 15:45:47 +0000

Project ID:

Current stage:

Manager:

Unit:

What:

Description: Develop and enhance a system for verification of 'mobile' (web-transferable) code, utilising and/or enhancing the JavaMC code base.

Deliverables: All deliverables are to be produced in Java.
A simple lightweight web service which allows the transport of mobile code.
An extension to the provided JavaMC code which allows information to be sent and received from a prover for the purposes of code verification.
A configurable byte-code modification engine which allows instrumentation of code to be verified.
An extension or rewrite of the example 'photo server' web application for demonstration of the above.

Why:

Customer: Robert Atkey, for ReQueST project.

Case statement: See URL.

When:

Status: Final Report

Timescales: 3 months, spread over 1 year (March 2008 - March 2009).
Timescales of the deliverables to be confirmed.

Priority: High priority alongside Proof-General.
As usual, other duties could take priority for short periods of time.

Time: 3 months' CO effort, spread over March 2008 - March 2009.

How:

Proposal: Pre-approved as this effort is funded directly.

Resources: 1 x Computing Officer with part-time effort.
Project uses the Informatics subversion repository.

Plan: Complete deliverables as appropriate to overall development, and according to feedback.

Other:

Dependencies: No strict dependencies, except requiring periodic input from the customer.

Risks: Risk of slippage due to other tasks. Unlikely due to generous real-timeframe, but could contend with Proof General development.

URL: http://groups.inf.ed.ac.uk/request/

Milestones

Proposed date	Achieved date	Name	Description
	2009-01-20	Investigation	Investigate current system, examine technologies used
	2009-05-01	Test Service	Prepare a replacement example service based on the photo server example
	2009-03-01	Extend Service	Extend web service with a usable API
	2009-04-01	External Prover	Implement simple interface for an external application to verify submitted code
	2009-02-01	Byte-code analy	Implement enhanced byte-code checking routines
2009-01-10	2009-01-10	Aborted	Funding for this project has been withdrawn.

Proof General Eclipse Improvements

boss — Fri, 25 Jan 2013 15:45:44 +0000

Project ID:

Current stage:

3s_Stalled

Manager:

Unit:

What:

Description: Further improvements to the Proof General Eclipse system.

Deliverables: A number of items, as required, from the Proof General Trac system. Non-specifically, to leave Proof General Eclipse a more useable system than when the project began.

Why:

Customer: David Aspinall, for CISA.

Case statement: The new Proof General Eclipse system is a promising replacement for the existing Proof General, and also has the potential to provide useful new facilities. One of these is as an *integration platform* for proof tools developed within the Mathematical Reasoning Group and beyond.

When:

Status: This project has been 'pre-approved' by grant.

This will be an 'ongoing' project whose status is difficult to measure. See milestones.

Timescales: The project has been approved to take 3 months of CO time, spread over
12 months from July 2007. The timescale of each task is undefined; I anticipate a tradeoff between importance and number of tasks completed within this fixed period of time.

Priority: As this work is defined as 3 months' CO time, to be spread over 12 months, it can take as low a priority is required to deal with regular CO duties. Its priority will likely rise as the period draws to a close and 'tidy-up' work is performed.

Time: The project has been approved to take 3 months of CO time, spread over
12 months from July 2007.

How:

Proposal: The implementation work involved for this plan includes some refactoring and fixes to the existing Proof General Eclipse system, as well as an extension of the document model and connection to additional tools within Eclipse. The changes required are conceptually straightforward, but technically involved.

Resources: This project requires only a standard DICE environment, and a CO, preferably one who is familiar with the Proof General system.

Plan: The plan is to tackle one or two items from Trac at any one time, reporting back to David Aspinall. As the nature of these items is unknown until specified, there is no longer-term plan.

Other:

Dependencies: This project may depend on latest and changing builds of Isabelle.

Risks: As this project is based largely on as-yet undefined work, the only risk is that the specified tasks are so large or complex that only a small number of tasks are completed within the timescale. The risk of CO duties overriding the project is very small due to the extended timeframe within which the work can take place.

URL:http://proofgeneral.inf.ed.ac.uk/trac

Milestones

Proposed date	Achieved date	Name	Description
2007-08-10	2007-07-01	Establish goals	At this point, the Eclipse IDE should be updated with the latest Mylar plugin, and the environment optimised for work on an Eclipse Plug-in project. Registration with Trac will be required. First tasks should be selected from the Trac alongside discussion with DA.
2007-08-15	2007-08-01	Work Begins	Part-time implementation of the project begins. New items should be selected from Trac as previous ones are completed, or as specified by DA.
	2009-01-15	Wind-up	Nearing the end of the project period, final goals should be specified such that nothing is left in an unusable state.
	2009-01-31	Completion	Project is complete, with 'handover' of final work performed.
2008-12-20	2008-12-20	Work Continues	Fix as many Trac items as possible within the available time.
	2009-05-31	Residual effort	Remaining effort to be spent as directed.

Development of Proof General for Eclipse

boss — Fri, 25 Jan 2013 15:45:33 +0000

Project ID:

Current stage:

Manager:

Unit:

What:

Description:

Proof General is a generic interface for proof assistants (such as Isabelle, developed by LFCS and with a worldwide user base. Its interface is currently based on, and runs in XEmacs or GNU Emacs, but development has begun on porting this system to the IDE / development 'Platform' Eclipse.

Development of this software has so far been extensive but uncoordinated, and has been hampered by Eclipse's internals changing during development. The current version of Eclipse is 3.2, and this is the version which the proposed development effort will target.

The project is to create a usable product from the existing code, and a workable, single code base for future development on the project.

Deliverables: To fix a number of bugs and outstanding issues with the new Proof General platform. To update the Proof General codebase to be fully compatible with the latest version of Eclipse. To produce a product of at least beta quality. To create a framework of code tests and documentation.

Why:

Customer: This project has been requested by Alan Bundy for CISA, and is funded by a grant provided to the institute.

Case statement: As CISA have specifically requested and funded this support, the development is to be performed as 'paid support'.

When:

Status: This project has been allocated extra time, at the expense of the HiGraph project. It is now due for completion on 9-Feb-2007.

Timescales:

The entire project has a limited timescale of Oct - Dec 2006, as its time is constrained by the HiGraph development project and CISA's grant period.

It is desired that project should be complete by the end of 2006 (see status for update)

Priority:

This project is the only one scheduled during this timeframe, though as computing officer it is possible that operational matters might take priority, should any responsibilities require urgent attention.

At present there is no expectation that any other task should take a significant proportion of the allocated time.

Time:

At present there is no expectation that any other task should take a significant proportion of the allocated time.

How:

Proposal: The existing Proof General Eclipse code base should be improved to a packaged, distributable product for the considerable existing base of users of Proof General (Emacs). The work should also leave a workable (single) code base for future development on the project.

Resources:

The project will require the development time of one CO.

This is a straightforward software development project with no exceptional computing demands, therefore no additional resources will be required.

Plan:

pending discussion with da, re new priorities.

Familiarisation with existing code (ongoing)
Make a packeagable product
Fix most critical bugs
Add testing framework
Add user documentation
Improve programmer documentation
Implement more generic structure
Merge code

Other:

Dependencies:

The timescale for this project depends on the grant period, which ends in March and means that this project is sharing effort with the HiGraph project.

The project's development depends on external components which are also being developed; in particular work on the newer development branch involves working with the Proof General 'Broker', which is still under development, as is its communication protocol.

As these elements of the software are not guaranteed to be reliable, but which are outwith the scope of this project, it is important to note the project's dependency on this.

Risks: As this project involves a significant amount of familiarisation and refactoring of code, it carries with it a higher than average risk of becoming a larger task than specified. This risk resolves to one of two scenarios; either later milestones will not be reached, or the project will overrun into time allocated to CISA's HiGraphProject.

URL: https://wiki.inf.ed.ac.uk/DICE/ProofGenEclipseProject

Milestones

Proposed date	Achieved date	Name	Description
2007-12-01	2006-11-17	package	Make a packageable product
2007-02-05	2006-12-01	fix bugs	Fix most critical bugs -- this continue after project completion, but a number of high-priority bugs have been fixed as of February 07, sufficient to allow several new releases.
2007-02-05	2006-12-08	testing	Add testing framework this has not been completed, having instead been handed to an external developer as of 05-Feb-2007.
2007-01-20	2006-12-15	documentation	Add user documentation
2006-12-22	2006-12-22	developer docs	Create programmer documentation
2006-11-30	2006-12-15	merge	Merge code this was partially performed, but deemed unnecessary as code structure underwent large changes.
2007-02-09	2007-02-09	complete	Document completed work and remaining tasks for further development of Proof General.

Development of HiGraph Application

boss — Fri, 25 Jan 2013 15:45:33 +0000

Project ID:

Current stage:

Manager:

Unit: