« Dealing with change during software development | Main | Taking the chaos out of concurrent development »

May 21, 2007
Managing large-scale software development This is the ninth in a blog series on the Future of Programming. Last time I talked about the potential problems with Agile (or other) development methodologies that assume all code forms part of a single stream - i.e., that there is always a "current build" for the entire project. Particularly on large projects, which may have many semi-independent sub-projects, this is not realistic. I suggested that the root cause of this assumption lies both in failing to grasp simple configuration management techniques, and in failing to manage continual revision to the development process itself. The former problem is easily rectified - the latter requires more thought. This time I'll say more about the nature of concurrent design processes.

The trick is to recognize the reality of how people work together - and use that as the basis for a structured approach to managing their activities.

Let's take a typical scenario. A design team is in the middle of a large concurrent design project, and an unexpected issue has arisen - sufficiently serious to warrant specific management attention, and potentially impacting several design areas (database, user interface, security, and so on).

Meeting to discuss the problem, team members realize that a new sub-project is required to manage the issue. Initially they have no plan or structure for this new sub-project. The input to the sub-project is itself a problem definition that may require further investigation and development. However, there are a number of significant things that they can say from the start. They may have none of the detailed elements of a process, but they are able to recognize a pattern. They know how collaborative problem solving generally takes place.

The pattern they recognize for collaborative problem solution has specific aspects that allow us to model it, at a high level, as a process:

1. The people involved will perform certain Roles, each with their own goals and responsibilities. There will be a number of participants in the solution process, with skills in different domains - database design, user interface design, security engineering, and so on. For each type of contributor, there may well be distinct phases of activity: problem definition, concept design, detailed design and testing, integration and testing, and so on. Hence, the sub-project is in fact composed of multiple distinct streams of activity, one for each domain. The contributions of all these have to be coordinated.
2. The eventual deliverables will meet certain preconditions. If successful, the output of the sub-project will be a solution, probably consisting of a set of solution components in different domains. The solution components in each domain will include models and tests that demonstrate that the solution solves the defined problem. There may well be interface specifications and other supporting documentation. Among all these objects there will be varied dependency relationships. Hence, the components of the solution both at domain level and overall are an interdependent set that must be protected from further change unless the whole solution is revisited and retested. The set of solution components can be viewed as a transaction - somewhat like a database transaction, although subject to quite different rules in which all sub-project participants commit jointly to the resolution of the issue.
3. The process participants will interact in a way to ensure that their individual contributions combine to produce overall deliverables of the highest possible quality. The components of each domain solution must be made available to an appropriate person for integration into a unified domain solution. Similarly, the domain solutions must be made available to an appropriate person for integration into a unified overall solution. The individual domain solutions and the overall solution must all be validated and certified by an appropriate authority, and this activity must be linked to the aforementioned integration.

With this analysis in mind, we can use a Role Activity Diagram to represent the sub-project as a whole:

TAKE AWAY

You may be reading this because you are responsible for a large-scale software development. And you may be wondering how the diagram above is going to help you. Is it the magic bullet you need? If so, why?

If you do not find the diagram above self-explanatory, this is because it draws on concepts from Human Interaction Management. Before you can understand the diagram, you need to understand the concepts.

In the next instalment of this series, I will explain 3 different perspectives from which the diagram can be viewed:

1. Management
2. Participant
3. Solution

Armed with this understanding we will start to see how even the thorniest - and scariest - problems in large-scale software development can be tamed. Complex problems can be broken down into a set of simple ones, so that management controls can be applied and the required solutions delivered.

If this sounds like what you need, tune in next time - and if you can't wait, you can always get the book :-)

Posted by keithhb in Management • Security • Service-Orientated Architecture |Digg This|Add to del.icio.us

Comments Post a comment

Name:

Email Address:

URL:
Remember Me? YesNo

Comments: (you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code: