Objectives
Even if contracts may have to be enforced by law, their primary rationale is to frame agreements and support collaboration.
Along that perspective the use of models may bring significant benefits regarding:
- What is at stake, what is to be provided.
- When resources are to be made available and outcomes delivered.
- Who should be responsible, who should contribute.
- How participants should collaborate.
What
To be of any use, contracts must help to clarify expectations and commitments. When shared ownership and continuous delivery can be achieved (see agile principles), expectations and commitments can be set on flat level and managed directly between customer and provider. But projects involving different organizational entities, with concerns and agenda of their own, cannot be managed on a day-to-day basis because decisions are set in different contexts and time scales. In that case explicit objectives and milestones are to be introduced, and contracts defined as to manage consistency all along project life cycle. And that is best achieved through transparency and layered traceability provided by models.
The benefits of matching models and contracts can be found in both directions: on one hand models are built along clear lines of responsibility, on the other hand they provide a sound basis to contract validation.
Matching models and contracts can also be seen as a generalization of Test-driven development (TDD) to the whole development process:
- First, it brings about Design by contract as a supporting context.
- Then, if regression is to be avoided, contracts must be organized depending on their scope, nature and stakeholders.
- Finally tests and contracts must be set within model driven development. For that purpose it is necessary to translate the test-driven principles to modeling.
Finally, since contracts are about deliverables and prices, some common ground must be defined between them, and that can only be achieved with functional metrics computed from models.
When: Loops and Milestones
As convincingly argued by agile approaches, projects are best-managed when customers and providers can collaborate directly, managing scope and time within continuous development loops. Yet, since that’s not always possible, a good compromise should be to combine iterative development with milestones set along clear rationales, e.g:
- Dependencies between specific applications managed by organizational entities whose direct collaboration cannot be achieved.
- Non functional constraints, to be supported by technical architectures.
- Cross functional requirements, to be supported by functional architectures.
Models are to provide explicit and unambiguous descriptions of milestones to be used as invariants for safe iterative development.
Who: From Models to Tasks
Manufacturing processes, built from material flows and engineering constraints, have demonstrated the benefits of flow-based approaches both for in-house production and outsourcing. Yet, despite dealing with symbolic artifacts free of material frictions and impediments, software engineering hasn’t followed suit, with phased projects and work units still based upon customized versions of the same catch-all activities instead of defined from the flows of deliverables.
- Flow-based: work breakdown starts with targeted deliverables and builds processes bottom-up, depending upon constraints on development flows.
- Activity-based: work breakdown starts with one-fits-all organization, follows top-down with predefined activities, which are then entrusted with production objectives.
Set within a model driven engineering framework, work units could be defined directly in terms of models and development flows. That would befit a contract driven paradigm as functional metrics could be used to asses the tasks both for charge and value added.
How: Collaboration and Non-zero Sum Game
Agile or otherwise, engineering projects call for collaboration and their success is heavily affected by the framework governing the relationships between participants. Taking a cue from non-zero sum games, the corner-stone of collaboration should be to establish a playground where one’s benefits don’t have to come from others’ losses.
That can be achieved if customers and providers apply alternate strategies: first (a), customers estimate the expected benefits of a new application and providers the feasibility of solutions; then (b), customers specify their needs and providers assess their costs, finally (c), both agree on price and time. For customers, success is measured by the return on investment (ROI), which depends on cost, quality, and timely delivery. For providers success is to be measured by costs and customer satisfaction. Hence, while stakes are clearly conflicting on costs, there is room for collaboration on quality and timing, and that will bring benefits to both parties.
Where Models Matter
As demonstrated by Game theory, success in non-zero sum games stems from timely and trustworthy information; since engineering projects usually come with intrinsic uncertainties, players must be constantly and fully aware of their respective knowledge, expectations and commitments. That can be best achieved by lean models focusing solely on unambiguous and necessary descriptions.
- Non ambiguous: just like programs can be designed as to be testable, models should be built as to be open to refutation. Paralleling TDD’s “fail fast” principle, requirements should avoid generalizations in favor of conflicting assertions with clear-cut alternative options.
- Necessary: based on requirements organized by contracts, models should be sequenced as terraced fields. Paralleling the “You ain’t gonna need it” (YAGNI) with a “now” qualification, each terrace should focus on homogeneous outcomes with models pared down to necessary and sufficient artifacts.
Whereas those principles are meant to be applied to specific contents, contracts should primarily be mapped to models layers and set to coincide with quality checks.
Finally, if timely and trustworthy information is a necessary condition for cooperation, it is not a sufficient one, as players may be tempted to defect (aka cheat) if they think they can get over with it. Leaving out ethical considerations and invasive regulations, the best policy should be to make a convincing case for due diligence as participants should:
-
Due Diligence ?
- Say what they know, mean what they say, say what they mean.
- Look at outcomes and deliverables, and check their validity.
- Listen to what others have to say, and take their concerns into account.
Whereas those conditions are more readily met with agile development models, they should also apply when phased projects cannot be avoided.