HomeNews and blogs hub

Advanced School on Scientific Development - Day 5 Software Sustainability Exercises

Bookmark this page Bookmarked

Advanced School on Scientific Development - Day 5 Software Sustainability Exercises

Author(s)
Steve Crouch

Steve Crouch

Software Team Lead

Posted on 20 February 2012

Estimated read time: 6 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

Advanced School on Scientific Development - Day 5 Software Sustainability Exercises

The key objective of these exercises is to think about the current status and the future of your software.

Exercise 1 - Software Self Assessment

Being able to objectively self-assess your software project, to identify it's current state and what needs to be done to improve it for your community (as well as yourself!), is a critical skill. However, knowing what areas to analyse to identify such gaps is often difficult.

The SSI's Criteria-based Assessment can be applied to software to determine its strengths and weaknesses in a number of areas. You can either apply the assessment to software you have written, or to the software you intend to write next week to determine what you should focus on:

  1. Go through and answer the Criteria-based Assessment[1] for your own software, answering the questions and making a general list of those aspects that need improvement.
  2. Prioritise the list of improvements based on your own (or your community's) needs for the software.

You may identify a great many areas in which your software could be improved. The important outcome of the exercise is to identify those areas for improvement that are important for your software.

Note that software's self-assessment should be an ongoing process throughout the lifecycle of your software. You should consider a new assessment whenever the software reaches (ideally before!) an important milestone in it's development, e.g.:

  • The user base increases, or is expected to increase, e.g. in your laboratory or community, perhaps another project
  • The developer base increases, e.g. other external users wish to extend your software and possibly contribute new code to your project
  • Substantial changes or new features are made to the implementation

Of course, this exercise only looks at your opinions. A valuable next step is to ask the intended users of the software what is important for improvement, and then develop a high-level plan for future development. This constitutes a roadmap, and is an incredibly powerful process and tool for driving and supporting the needs of your community. Of course, at the moment the only intended user may be yourself! However, in either case, thinking about these aspects early is always better (and cheaper) than having to address them too late.

[1] http://software.ac.uk/sites/default/files/SSI-SoftwareEvaluationCriteria.doc

Exercise 2 - Catalogue the Significant Properties of your Software

You may have users or developers in your research group, or on other projects, that are looking to use your software. Alternatively, you may have had a user or developer randomly come across your software and proclaim 'Your software is exactly what I need!'

In either case, what are the essential elements they need to understand... e.g.

  • What the software does, input and output data formats, configuration
  • Architecture, implementation details, components
  • Documentation, tutorial material, releases, operating environment, ...

Good documentation, and a solid supporting website, can supply this. But in some cases this can be unstructured or expensive to produce. By capturing the significant properties of your software in a number of areas in a single place, you have a singular record that gives an overview of your software for others, whilst keeping development of this document, and its maintenance, to a minimum. It also gives you an understanding of what to look for in other software you want to use.

The Framework for Software Preservation, developed by STFC at Rutherford Appleton Laboratories in the UK, can enable you to capture these significant properties using a straightforward template.

  1. Look back at the Managing Sustainability into Software slides [2], and understand how the framework fits together (if you haven't already!).
  2. Take a look at an example filled-in template for the Grimoires software[3].
  3. Fill in a blank template for your existing software, or use it to specify what you think should be included for the software you intend to write next week[4].
  4. Taking the filled-in template into account, amend your prioritised list of improvements from the first exercise as appropriate.

You may not finish this today, but you can of course complete it after the School.

The idea is that you can keep this document under version control, updating it for each release. As with the SSI Criteria-based Assessment, it can help to identify gaps that need to be addressed, but at a number of more technical levels.

[2] http://elearn.escience-lab.org/file.php/10/ASOSSD-SSI-ManagingSoftware.pdf
[3] http://www.ecs.soton.ac.uk/~stc/ASOSSD/SoftPres-Grimoires.doc
[4] http://www.ecs.soton.ac.uk/~stc/ASOSSD/SoftPres-Template.doc

Exercise 3 - Planning a Sustainability Approach

This exercise builds on the previous two, where you have ascertained the status of your software, identified the areas for improvement, and prioritised this list. In this exercise, you'll select an overall sustainability approach to development, bringing together what you've learnt already, and develop a short plan for incorporating all these support infrastructure and improvements into your software.

In a text file or other document, write down the answers to the following questions:

  1. What are the sustainability requirements for your software? e.g. what are the communities that need to use it, what types of user (end-user, developers), how should the software be sustained for these types of user, what aspects of the software need to be sustained (e.g. source code, docs, other materials), what is the anticipated/desired lifetime of the software (e.g. beyond project lifetime?), etc.
  2. Select a suitable sustainability approach for your software - select from these alternatives[5].
  3. What are the reasons for your approach? - why is this approach suitable for your software?
  4. What are the support resources you will need for this approach, any why? e.g. project website, source code repository, issue tracker, support mailing lists, discussion forms, community Wiki, hardware, other software, etc.
  5. Use of resources - How would you use each of the support resources to help your users and build a community for your software?
  6. Plan next steps - develop a short, prioritised list of steps for what you will/could do to improve your software and its sustainability given your chosen approach.

[5] http://software.ac.uk/resources/approaches-software-sustainability

 

 

Share on blog/article:
Twitter LinkedIn