1: Title: Deal Management Platform Core functions To develop a software as a service application that provides the following three core functions to transaction professionals (e.g. lawyers, accountants and bankers): (a) the secure distribution of transaction documents among transaction professionals and their clients and the presentation of the distribution, or if desired by the user, the documents, on a secure and ordered website; (b) the ability to construct a transaction diagram and graphically map the transaction documents across that diagram (e.g. showing that a loan document is associated with a flow of funds); and (c) at the conclusion of a transaction, the ability to generate an indexed collection of the final transaction documents. Presentation and ease of use need to be primary design considerations. Additional functions If there is capacity, it would be optimal to develop collateral transaction management tools which could be offered to users, for example, the ability to generate calendars and simple Gantt charts and display user profiles which could be associated with transactions. Degree of development As an initial stage, the application would ideally be developed to a beta stage, ready for further development or presentation to potential investors. If the application could be progressed to an alpha stage, that would obviously be greatly welcomed. ========================================================================== 2) Title: Squareweave Automated Reports of Wonder Description: A system to interface with a set of input systems on one end, aggregate the data into some useful representations, and interface with a set of possible output systems. This system is needed because Luke is lazy, and wants to replace himself with a very short script. A standard input example would be to get all of the commit messages from an svn repo of a certain structure, parse and manipulate the data therein contained, and show to a client that we haven't actually been playing arcade machines all day but actually doing work for them. A standard output would be - at the most basic level - an email with pdf, but ideally interfacing with online invoicing software Harvest (harvestapp.com) to automatically generate invoices with detailed information as to the work we have done. The system will need to be able to deal with additional input and output options. At a later stage, we may also want to include data from a bug tracker, a time tracker, project management software, or some other system. We may want to output the information as a site, pdfs, emails, or morse code. This project will be fun. We have a coffee machine at our studio. ========================================================================== 3) Title: Committees of Management Reporting Description: Victorian public land is looked after by over one-thousand Committees of Management, from the Great Ocean Road to Melbourne Zoo. Reporting for these committees is currently performed by paper, and we want to support committees reporting via a web application. In addition, due to legislation and policy changes, the reporting requirements for committees is continuously changing, so we need to be able to dynamically modify the web application structure and content (we probably need some sort of content management system). ========================================================================== 4) Title: Applications for AIDE Description: As discussed in the meeting, we are interested in 3rd year students working on individual applications using the AIDE (Application Integrated Development Environment) and NAIT (Nossal Application Installation Tool) systems being developed by the 4th year students. Some suggestions we discussed were: - Drug Dosage Application: A tool that produces a drug dosage prescription given: patient age and weight, and indication (i.e. purpose of the drug, e.g. "treating flu"). - Pneumonia Diagnosis Tool: The software tool that reads blood oxygenation/heart rate information from the pulse oximeter device. The tool will also read data from other devices such as a termistor (digital thermometer) for measuring temperature, and Focussed Impedance Measurement (FIM) device for measuring respiration rate. Using this data set, the application will determine probability of a patient's suffering from pneumonia, and if so, the severity of the illness which in turn determines how the patient should be treated (drugs, in the clinics/at home, urgently go to hospital, etc.) Although the 4th year students are supposed to be working on this, they may get side tracked as they are focussed on core functionalitities. perhaps the 3rd years students could develop this to alleviate pressure from the 4th year students. I won't announce this to the 4th year students at this stage, but just sounding it out to you and Ed as a possibility. ========================================================================== 5) Title: Choose to be Calm This project has three main components to it - all which surround the design and effective operation of two inter-linked websites. The websites that need to be developed are for two not-for-profit community ventures called 'Choose to be Calm' and 'Calm in the City'. The first key ingredient is that both websites need to give an experience of calm when viewed. The second feature is that there needs to be a booking engine through which people can make bookings for programmes, receive an automatic response, and information from that booking system should be able to extracted and analysed by the system administrator. Individuals should also be able to sign up for information about future events. The third aspect, if possible, is the design of a Calm Room on the website - through which people can choose whatever on-line experience they would like to have - whether listening to a short piece of music in their break, or an on-line choose-to-be-calm meditation commentary, or calming visuals. Programming of a reminder bell either on their desktop or through the website would be ideal since the bell serves the purpose of a reminder to take-time out. The individual should ideally be able to choose the timing of the reminders. Finally, the website needs to be able to be added to and amended by the administrator since this nation-wide project is in its early stages. ========================================================================== 6) Title: Research metrics Description: This project aims to use citation analysis to assess the relative importance of individual scientists, disciplines, institutions and countries over time. The project consists of two parts: 1) Part 1: Database Compilation 2) Part 2: Data Analysis & Visualization The first stage comprises a compilation of a citation database to be based on the Essential Science Indicators (ESI). The second part of the project is data visualization. The database is so vast it likely becomes unwieldy. Yet with advanced visualization techniques it is still possible to eyeball the data and to make sense of it visually. This visualization will enhance the quality of subsequent statistical analyses. This visualization requires two stages. The end result should be a user-friendly interface by which we can easily produce both static as well as dynamic analyses and visualization. 1) Stage 1: Static network analysis & visualization 2) Stage 2: Dynamic network analysis & visualization ========================================================================== The following projects (7 and 8) are internal projects -- that is, the client is internal to the CSSE department. Only one of these will run -- it will depend on team preferences -- to allow all of our external projects (1-6) to go ahead. 7) Title: MUGLE: A Collaborative and Interactive Game-based Learning Platform for Distance Learning Description: Melbourne University Game-based Learning Environment (MUGLE) is a software platform that supports the development of educational games deployed on the Goolge cloud (Google App Engine). This project involves extending MUGLE to support multi-player games and developing a multi-layer educational game as a proof of concept. Google has expressed interest in the platform and it is expected that we will be able to gain funding for this project from Google in the future. ========================================================================== 8) Title: Visualizing module dependencies in Mercury programs Description: Mercury is a purely declarative programming language designed and developed in this department. It has a modern module system: pretty much all programs consist of several modules, with each module declaring what entities it exports to other modules, and what other modules it imports entities from. The entities may be types, type classes, predicates, functions as well as a few other kinds of things. In large programs, it can be difficult for programmers to keep track of *which* entities module A needs from module B. Ideally, one wants to keep the coupling between modules to a minimum, and one wants to avoid circular dependencies between modules if at all possible, but in the absence of feedback from an automatic tool, it is difficult for programmers to follow these ideals. The main requirement is for a system that lets programmers visualize the dependencies between modules in their programs. These dependencies take the form of a directed graph, with the nodes being modules, and the edges being dependencies between the modules, with each edge being labelled with the entities imported by the target node from the source node. In many programs, these graphs are so big that they cannot fit on a screen all at once, so the visualizer will need controls to let programmers decide what they want to see, as well as sophisticated heuristics about what else to show, and how to lay it all out. A secondary requirement is for automatic detection of certain kinds of module dependency antipatterns.