Open Data Internship – Week 5 – The Omnibus Edition

Alas there is no creative writing to go at the top of this blog, mostly because it would end up being very similar to the ‘What have the Romans done for us?’ scene from ‘Life of Brian’, but with ‘What have I done recently?’ being the main question. As whilst I have been busy for the last 3 weeks it did not feel like it at the time and so I had neglected to write blog about the stuff which has happened. I shall now try to rectify this.

Lean 6 Sigma

Recent changes in management in iSolutions have led to a plan to introduce new management practices in the form of Lean 6 Sigma. This included a training afternoon that I was invited on along with the rest of the team. The system is made up of two parallel practices ‘Lean’ and ‘6 Sigma’. Lean was developed by Toyota about 70 years ago and its aim is to reduce waste, or as Lean calls it ‘non-value adding tasks’. Waste includes anything that the customer did not ask for such as testing, transport or waiting. Whilst this is clearly geared towards manufacturing processes, I can see how it could be mostly implemented in a software development environment.

6 Sigma on the other hand focuses on improving the quality of products delivered. It does this by modelling the delivery of the product/service as a normal distribution, and finding what percentage of these tasks are completed in an acceptable time/to an acceptable level. From this data, the process is given a ‘sigma rating’, which is the number of standard deviations above the mean the process is. The process is then improved upon with the aim of making it a ‘6 sigma’ process, meaning that the process is being completed such that 99.99966% of outputs are defect free. Personally, I am less positive about 6 Sigma than Lean as 6 Sigma is aimed towards improving standard procedures, but I find there is little to be standardised about software development than project management, and how would you go about determining a standard metric for “defect” free products.

Campus Navigation App

I have spent most of my time for the last 3 weeks building and getting data for an internal and external campus navigation app. The app itself is reasonably simple, each room, fork in path and building entrance is a node, which is connected to other nodes in a simple graph. From there it is a simple case of traversing the graph to find a route. I did look into for other existing solutions similar to this one, but found that most of them were paid solutions and the one that was not had some undesirable features. One such feature was that it required floors to have an image to represent them, typically a floor plan which I didn’t have at the time, and even if I had I would not have wanted to place them on a publicly visible service.

Open Data Service Website

I took a few days off from developing my app to look at the development build for the data.southampton.ac.uk website to find any issues with it, since it was largely procedurally generated from the data the service acts as a from end to it was unsurprisingly low in issues, with the main issue being dead links present in the data. So I chased down these dead links and where possible found new links for the data in question. A not very interesting task but one which will improve the quality of the affected data on the open data service.

A second task which got push back behind app development was to look into how to make the university’s open data more accessible to people, as whist it exists and is quite comprehensive it appears not be regularly used by the university populace, but existing applications such as ‘Room Finder’ and ‘maps.soton’ are regularly used by people at the university even if they do not know that this is part of the open data service. The main conclusions I drew were that example SPARQL queries and easily accessible source code for current services would be a good place to start, but I am open to suggestions (as is the rest of the Open Data service).