The Significant Properties of Software: a study


Appendix B: Questions to Analyse Software Preservation Practices



Download 0.66 Mb.
Page20/21
Date18.10.2016
Size0.66 Mb.
#2594
1   ...   13   14   15   16   17   18   19   20   21

Appendix B: Questions to Analyse Software Preservation Practices




Significant Properties of Software


Significant properties, also referred to as “significant characteristics” or “essence”, are essential attributes of a digital object which affect its appearance, behaviour, quality and usability. They can be grouped into categories such as content, context (metadata), appearance (e.g. layout, colour), behaviour (e.g. interaction, functionality) and structure (e.g. pagination, sections). This is defined within the context of preservation; significant properties must be preserved over time for the digital object to remain accessible and meaningful.

Significant properties have been considered in for a number of digital objects, such as text documents and raster images. However, to date there has been no substantial study specifically into software. In this study, we are considering how this concept might apply to software and develop a basic framework for capturing the significant properties of software.

We recognise that we cannot consider the whole of software - this is a very large topic in itself. But we would like to consider a number of examples within the scientific and mathematical domain. In order to develop this framework, we would like to consider a number of scenarios where software is developed and stored for a significant period of time, such as long term development projects or software libraries and repositories.

Within each scenario, we would like to consider for each software "object": (taken from CASPAR requirements capture process):



  • conceptual purpose of software items (community, domain of interest, algorithms)

  • knowledge/behaviour encoded within the software

  • encodings, programming languages, input/outputs data formats.

  • supporting documentation objects.

  • relationships and dependencies between software items

  • relationships and dependencies to the s/w environment

  • storage mechanisms

and additional information about:

  • production - description of the way in which the software is written and used and maintained, and how it gets to the repository

  • current use:

    • software used to manage the digital encodings

    • software/mechanisms to use/perform the software (emulation, configurations, build scripts, manuals)

For each of these broad headings we include some guidance of the intention and also some questions which are relevant.

Outline Questions


Each repository is characterised at the outset by the following basic features.

  1. Holdings: overview of the type of software held, and a list of software as much as practical.

  2. Software: For a selection of the software in the repository, offering a variety of challenges, provide a description of the digitally encoded information to be preserved, from the bit level to the knowledge it conveys to its user community. We do not at this stage need very detailed descriptions. In addition we need a brief descriptions of

    • any special importance, or special unique quality

    • access restrictions and controls

    • what behaviour the software supports

    • how the required software is located and retrieved

    • what additional environmental knowledge is employed to characterise the software

      • hardware, software, versions, library conditions

    • Software usage process - how is the software meant to be used? Interaction with a (business) process? Software architecture it supports.

  3. Software Producer: A brief description of the group, individual or institution that produced the software.

  4. User Community: A description of the current user community and the characteristics of the designated community for whom this software might be preserved.

  5. Current plans/approaches for:

    • cataloguing s/w

    • maintenance of s/w versions

    • software reuse

    • software preservation


More detailed questions

1 What Performance/Behaviour does your current user(s) expect from this software and what needs preserving?


This is quite an open ended question but it is essential to establish the nature of the information being are attempted to be preserved as this helps to define what needs to be preserved. This definition does not limit the potential information the archive is capable of providing, but rather helps define a minimum level of information to be preserved.

Some possible example of types of software and supported behaviour.



  1. Library routine which has a number of inputs in particular formats, produces a number of outputs in particular formats, implementing a particular algorithm

    • e.g. fast-fourier transform,

    • e.g. data format conversion,

    • e.g. compiler (?)

  2. software package to support particular set of functions and user interactions on a class of data object

    • e.g. text editor, takes a text file in a particular format, allows the user to perform a set of edit actions via some interface, and save object.

    • e.g. eclipse s/w editor and builder (?)

    • e.g. software visualisation package NAG IRIS Explorer ?

  3. software framework for linking and integrating a series of different functions and applications together upon a common data format/storage system.

    • e.g. Starlink

    • e.g. CDAT (BADC) - (?)


Download 0.66 Mb.

Share with your friends:
1   ...   13   14   15   16   17   18   19   20   21




The database is protected by copyright ©ininet.org 2024
send message

    Main page