An Agile Ontology

Image: dan /

The group in which I work at EBI applies Agile Software Development methods to developing software. The technique requires that iterations are frequent and that software is released often with an emphasis on collaboration between developers, especially with regards ‘customer’ requirements. Typically through these short iterations, the whole life cycle is reproduced, including some degree of requirements analysis, testing and delivery of product.

So why is this relevant to SWO? As part of the original SWORD proposal we suggested that Agile methods could be applied to building ontologies in order to formally collect requirements, evaluate the ontology built and to deliver the SWO often and early.

As part of the first SWORD workshop in Manchester, we engaged with a number of representatives from the digitial preservation and curation community and generally those interested in software, in order to elicit requirements for SWO. Initial exercises proved very successful in collecting a great number  of competency questions and feature requests.

The issue now is how to priortise this list of requirements, given the relatively short timeline of the project. Fortunately, Agile methods are at hand to help. Two methods were employed to do just this. First of all ‘planning poker‘. Normally used to estimate effort or relative size of tasks in software development, we took an ontology engineering perspective and turned those tasks into ‘components’ of software which were required to be added to the ontology to describe software. For example, version information, licensing, and so on. This exercise produces a list of requirements with some metric of effort required attached to each component. Next we applied a technique called ‘buy-a-feature‘ which allows users to prioritise components by spending points to ‘purchase’ features, the price of which is based on the initial complexity estimates.

So how did this work? Very well as it happens. The participants readily engaged with the approach (which always helps of course!) and the techniques were useful in identifying discrepancies in effort estimation, clarifying areas of ambiguity and producing a list of prioritised components moving forward.

Below is an image of the ‘priority list’ of components bought by users (shown in green) and will be the focus of the SWO project. Click the image to enlarge. In the image, the columns are the ‘component’ areas, i.e. bits of software we will describe in the ontology. The groupings are based on the previous card sorting exercise. The rows represent the different people’s ‘purchases’ with the final row showing the total spent on each component.

This entry was posted in methods, modeling, users, workshop. Bookmark the permalink.

6 Responses to An Agile Ontology

  1. I thought this exercise was both useful and engaging and I’m now on the lookout for ways I can use it with the team here at JISC to evaluate where to put effort into solving a complex set of issues. Thanks very much for running the workshop.

  2. Pingback: An Agile Ontology | Agile Development

  3. Pingback: Ins and Outs of software « SWORD

  4. Pingback: The second SWOP workshop « SWOP

  5. Fabio Kon says:

    I’m looking for an ontology modeling Agile Methods, preferably in OWL that can be edited in Protege. Do you know of any and could send me some pointers?


  6. Pingback: The Software Ontology (SWO) | Robert Stevens' Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s