Audited Dependencies

Genericity is a tradeoff. A generic structure should scale well, and thus allow to focus to wide or fine granularity, but it will be simple, maybe crude.

Physical dependencies, the kind which can be audited (recorded automatically), have been met in the context of build management. Yet, this is not a restriction, and on the other hand, build dependencies are only seldom audited --much more often declared.

Dependencies can hardly be declared at a fine granularity, for reasons of maintainability. Such declarations will involve modules. Audited dependencies on the contrary should be trimmed as fine as possible.

Auditing dependencies will make emerge new information. Who uses what, and in what context, what else do they use, etc. It allows for bottom-up communications, and focusing on facts more than on intentions or assumptions.

-- MarcGirod - 28 Jan 2003

Question: What actually is audited dependency?

From the above it is suggested that audited means recorded automatically. Also dependency occurs in many different forms, for example

Build dependency - Part of the system needs another part to build successfully
Run-time dependency - Part of the system needs a particular run-time environment
Functional dependency - Some features are only successful if other features behave in a particular way
Logical dependency - Parts of the system "belong" to the same architectural unit.
Schedule dependency - Parts of the system need to be developed before other parts.

Each of these dependencies may be completely orthogonal to other dependencies. Putting dependent parts in the same directory may be very reasonable from one perspective (e.g. logical decomposition as for an architecture) and ridiculous from another (e.g. build dependency).

Yet, each of the dependencies may be auditable, i.e. objectively verifiable. For example, the directory structure may express one type of dependency while a branch structure expresses another type of dependency. It is quite common to organise requirements, source code and baselines very differently.

-- FrankSchophuizen - 19 Feb 2003

Are you sure that all are practically auditable? I don't think so. Out of the various kinds of "dependencies" you proposed, I think that only the first two are actually suitable to be recorded automatically in an objective and generic way. All the others imply some kind of interpretation and will not result in simple directed graphs. They are thus of little interest from an SCM point of view.

In fact build and run-time dependencies are both special cases of the more general concept of auditable/audited dependency. Specifying other types of suitable durations for some recording, you would define other dependencies, maybe orthogonal.

-- MarcGirod - 02 Mar 2003