The eight tasks in an artefact lifecycle

A bridge, building, or piece of software may exist for many years. Or, as often happens in the case of new software, be scrapped before it is put into use. My mate Wayne, a professional software developer for over 12 years, has worked on several projects which were canned before they were completed. In a world of ever changing requirements and circumstances, ‘it’s not unusual’ as Tom Jones would say. Software development can take months, even years of effort, so scrapping the results is a waste. To counteract this, we have libraries for software reuse, design patterns and templates to avoid reinventing the wheel.

But why just reuse the product template or pattern? Why not template the tasks the artefact underwent during its lifecycle? By extending the theory of function, structure, and behaviour, there are eight tasks in an artefact lifecycle.

Design formulation or design

An artefact’s life begins when a requirement is identified. What is the artefact for? What is its function? Once this is decided, its proposed function (F0, as shown in the top left hand corner of the image above) is translated into design descriptions which represent its expected behaviour (B0) through the task of design formulation. Engineers often use standards and design codes, as they don’t want an artefact producing unexpected behaviour.

Synthesis

The task of synthesis takes expected behaviour (B0) and transforms it into the structure (St0) of the proposed artefact. Structural descriptions often contain topological and geometrical descriptions, as well as material properties and environmental and user issues, which embody the desired actions of the artefact (what an artefact does).

Analysis

Once a structure (St0) is in place, the next step is analysis. In structural engineering, analysis is often performed by finite elements software. In software development, analysis is performed by verification, testing, debugging, and sometimes reverse engineering, as well as profiling a prototype to get an understanding of how it is actually behaving (Bt0). This behaviour might be quite different to expected behaviour (B0).

The comparison of the two behaviours – expected and actual – often, leads to many iterations of formulation-synthesis-analysis-comparison in order to get it right before the construction begins.

Construction

Using structural descriptions (St0), the construction task creates a physical structure (Stn) – the artefact: building, bridge or software. As the process of software development is more fluid, it can, at this phase, have additional functionality added. Models such as Boehm’s spiral model assess the risk of ad-hoc problem solving.

Monitoring

Monitoring software can be done using verification and validation techniques. Or, by usability testing: call in a set of users and see how the software behaves as they interact with it. In physical artefacts such as bridges and buildings, there are a great range of techniques from the destructive carroting, where bits of concrete are removed and analysed – rather like a medical biopsy, to non-destructive techniques such as fibre optic sensors which are placed on the structure and measure local deformations which are analysed to see how the artefact is behaving.

Users may be employing the artefact in a way that it was not originally intended, or concentrating on an aspect which was added as an afterthought – such as SMS texting on mobile phones. Or, the artefact might not be behaving as well as expected when compared to the expected behaviour and some intervention is needed. Problems and solutions are identified during monitoring.

Intervention

The task of intervention takes the existing structure (Stn) and create a ‘new’ structure (Stn+1) by adding or restricting functionality. With bridges, this is normally due to safety considerations, e.g., load restrictions are placed on bridges. In software, changes in the GUI could highlight previously neglected functions because they are difficult to find.

Intervention is really a secondary construction phase – tweaking – which might need new design descriptions and documentation for future use.

Retrofit/modification/repair

Sometimes, an artefact stops behaviour as desired. Retrofits, repairs and modifications are needed to restore the artefact. This may involve rethinking an artefact’s function and synthesising new actual behaviours into new structures. With software, this is often the beginning of the end. As debugging takes places, and people come and go, chances are more bugs are introduced.

Dismantling/deconstruction

When the cost of maintaining software is greater than writing a replacement, then it is wise to scrap it. With bridges and buildings, as soon as safety becomes an issue, replacements are needed. Some parts can be recycled, other scrapped. However, much can be learnt from reverse engineering the ideas of artefacts.

The scrapped artefact can lead to new ideas about the function of a replacement. The designer starts again at function (F0) and tries to formulate design descriptions which describe expected behaviour (B0) and so it begins over again.

Related links
http://www.ruthstalkerfirth.com/pdf/CC02.pdf (academic paper)