Software Development and Deployment

John Rooksby, University of St Andrews

Related Papers        PDF


Systems development is more than a technical procedure; it is a form of cooperative work. The development of any non-trivial system involves various kinds of planning and procedures, necessitates forms of distributed coordination work and requires some subtleties amongst workers in the form of awareness of the work of others. These practices are intricate and fine-grained and saturate every level of software engineering from coding, to testing, to documenting, to procurement and marketing.

The related chapter on Requirements and Design focuses specifically on these process activities and how socio-technical analyses can contribute to them.


Software and systems development work has evolved and transformed over the decades. Many of these changes relate to the need to construct, manage and assure increasingly large and complex systems. The changes include:

Our work has been driven by two concerns:

  1. Research in software and systems engineering has mostly focused on technology and has paid little regard to the fact that human, social and organisational issues have a major influence on all aspects of engineering processes.
  2. The focus of the software and systems engineering research community has mostly been on ‘interesting’ systems such as complex, safety-critical systems with requirements for advanced methods of development and validations. However, most systems are more mundane (although they may be complex in different ways) and methods of developing such systems (e.g. the extensive use of ERP systems) have changed radically over the past 20 years. These changes have not been widely acknowledged by the research community.

Our concern has been that while the work of systems development has changed, the academic discipline of software engineering has remained static and can often miss real world problems. There is a gulf between academia and practice, caused not just by the failure of organisations to heed the lessons and insights from software engineering research, but also problems with the relevance of this research to real-world practice.

Organisational Issues

Many of the problems of software development are organisational; they are the problems of coordination, scheduling, decision-making, awareness, and so on. A key difference between systems engineering and socio-technical systems engineering is that the latter takes these into account.

Systems development is normally managed on a project basis. Projects are formatted organisational arrangements within which people and resources can be allocated, coordination tools and procedures deployed, and they provide the context for the organisational accountability of system development, particularly the measurement of progress. Contrivances associated with projects can include phases, specifications and plans. Other contrivances can include allocating roles and organising people into teams, specifying means of cooperation such as regular meetings, sign-off and so on.

Contriving the orderliness of work does not in itself ensure this orderliness or provide remedies for all contingencies. For example, plans are followed dynamically and remade as development progresses. Questions repeatedly arise during the development and testing of systems as to what exactly can be done to satisfy the plan, what parts of the plan are achievable given the time available, and what is missing from the plan.

Cooperative work in systems development and testing is often kept orderly through the use of “ordering devices”. These ordering devices may be information technologies such as versioning systems, wikis, and workflow management systems. They may be paper-based technologies, such as task-cards or sign-off sheets; or, they may be more procedural such as verbalising particular actions or events, working in rotating pairs, holding meetings, or the adoption of a particular coding style.

Managing the ordering devices in software engineering is often perceived as bureaucratic work that does not contribute directly to the system itself. However, this work is always crucial to the successful development of any non-trivial system. It is therefore important to notice and analyse the repertoire of ordering devices used in any particular systems engineering project, the interdependencies between these, and their strengths and fallibilities.

There is also a relationship between organizational structure, organisational priorities and the ways in which systems projects are carried out. This stretches well beyond what kind of method an organisation selects (agile, plan-based, etc.) and into how any particular method is practiced. The ways in which an organisation is structured can significantly impact on the way a project is practiced and, indeed, the architecture of the system itself. This can be in terms of hierarchy and decision-making. It can be in the ways in which collaboration and teamwork are structured. And, it can be around the availability of people and resources.

The priorities of an organisation also significantly affect the ways in which systems engineering is practiced. These often become apparent as deadlines approach, with the need to make a profit, or make software available for pre-scheduled activities overtaking the concerns for producing reliable or fully functional software.


Systems specifications take different forms depending on the design method used and whether the project is being done in-house or by an external supplier. In whatever form they take however, specifications provide a framework within which, and in reference to which, design and testing, and user-designer relations, get worked out in practice.

As with any kind of plan, the development work and the system actually produced differ from what is stipulated in the specification. The actual project work and the finished system are instead a product of putting the specification into practice. This involves working out how the specification translates into, and relates to, the multifarious activities of development work, and the specifics of the emerging system. These activities, decisions and appraisals are often fashioned through intense negotiation between the different parties, in contingent and rapidly changing circumstances, in which the specification is a key feature and resource.

The area of specification is one where socio-technical factors are, perhaps, most evident and so it has been a focus for research in using socio-technical analyses. The chapter on Requirements and Design covers some of this research and its applications.

User-centred design

Systems development should orient to how the system will be used, what functionality is needed, what infrastructure and resources for running the system will be available, and what the usability issues are. Requirements engineering, particularly in user-centred design methods, often seeks to improve the quality of user-relevant information available during the design process.

This is important, but our experience is that user-centred design methods are too idealised. The realities are:

Pervading the user-designer relation in systems development are issues of generalisation. How does one person’s needs and opinions generalise to others? How do the issues in one organisation generalise to the issues in others (as potential customers)? How can a product developed for one niche be generalised for a wider market? Systems engineers, even if they have “users” to hand, will inevitably have to engage in some practical social reasoning about how to satisfice the needs of users.

Software testing

Testing, as with every other aspect of systems development, is saturated with social and organisational issues. We have found that while developers seem comfortable acknowledging the social and organisational issues in, say, requirements engineering, they are still extremely reluctant to acknowledge that similar factors pervade testing.

We have undertaken studies to characterise testing as it is done ‘in the wild’. We have not focused on newsworthy achievements or experiences in testing and have purposefully not discussed safety critical testing. We are certainly making no claims that the examples represent best practice. What we have achieved is a characterisation of run-of-the-mill testing, one that can supply insights into the kind of work that is currently done in many organisations on a mundane basis. This kind of testing is not usually safety critical but is often project or business critical.

We have identified a number of themes:

In the face of real world complexity, testing is a satisficing activity. Systems validation and verification can never ensure the correctness of a real world system. Systems engineers have to find and accept ‘good enough’ solutions, not because less is preferred to more but because there is no choice.


In our studies, we have tried to achieve a characterisation of run-of-the-mill development, one that can supply insights into the kind of work that is currently done in many organisations on a mundane basis. We believe that a better understanding of the everyday work of systems development helps us understand why technologies are and are not used and can inform the design of more usable methods and technologies.

We have deliberately steered away from safety critical systems, focusing on ones that are transformative, ones that are often project or business critical. These are the kinds of systems that are overwhelmingly common, and for which best practices can be distorted by the preoccupation in software engineering with the safety critical. It is common in the literature to use stories of good and bad practice, stories of the kind of work systems engineers should aspire to or avoid at all costs. We have trodden a different path, using examples of the kinds of work that we believe will be recognisable to anyone with experience in real world systems development.

Reference as:
Software development and deployment. Rooksby, J. (2011). In LSCITS Socio-Technical Systems Engineering Handbook. University of St Andrews.