ISTAR and the contractual approach

• Authors: M. Dowson
• Venue: ICSE '87 Proceedings of the 9th international conference on Software Engineering
• Year: 1987

ISTAR is a production-quality project support environment that was first released commercially during 1986. ISTAR is language and method independent, supports distributed projects, is portable and includes a rich and open ended tool set; its architecture and tools are described more fully elsewhere (see [DOWSON87a]). This description concentrates on the underlying approach to software development built in to ISTAR and its relationship to various views of the software process.ISTAR is organized to support a powerful and general approach to software development, the contractual approach. The essence of the contractual approach is that it views every task in a software project as having the nature of a contract; that is, a well defined package of work that can be performed independently by a contractor for a client. Contract specifications, of course, can include acceptance tests for contract deliverables, schedules, requirements s to standards which must be adhered to, obligations to make periodic reports and so on. But the key point is that the contractor is free to decide how to fulfill the contract specification. In general, this freedom includes the ability to let subcontracts to perform all or part of the work, and so on recursively.Support for this approach is built into the structure of ISTAR which creates independent contract databases for the execution of each contract. In addition, ISTAR provides contractual operations for assigning contracts, amending or cancelling them when necessary, accepting their deliverables and communicating formal reports between them. Using ISTAR to support a project, then, results in the creation of a dynamic hierarchy of contracts (and their contract databases) which corresponds to the organization of the project. It is important to note that the hierarchy is organizational, and that its structure is determined by more or less autonomous decsions by contractors (project staff) at various levels. Another way of saying this is that the contractual approach does not prescribe a particular software process — but is capable of providing effective support for a wide variety of processes. For example, the 'root' contract in a project hierarchy (the initial contract for the project as a whole) could let subcontracts for successive phases of the work such as 'specification', 'design', 'code', 'integrate', 'test', following a simple waterfall model of development. Alternatively, the first level subcontracts could follow a functional division and each be for the complete development of a part of the system. Of course, the contractual approach does constrain the process to be hierarchical, and insists that everyone in a project knows what they are supposed to be doing and for whom. But this reflects the observation that most effective processes have these minimum properties.In either case, the specifications of the initial ontracts might or might not include transitive obligations to organize subhierarchies in the same way, or even prescribe or forbid further subcontracting. Thus, the degree of autonomy that can be exercised by project staff is, quite properly, under managerial control, with ISTAR providing flexible mechanisms to support it. In practice, the degree of autonomy allowed is likely to vary throughout the contract hierarchy; the overall project manager will grant his group managers considerable freedom to organize their assigned work, while junior programmers will get clear instructions on how to proceed from their team leaders. As usual, the power of the approach is exposed when examining what happens when things go wrong rather than what happens when they go right. When a contractor cannot complete an assigned task within its schedule, or with the available resources, or at all, some sort of 'iteration' ([DOWNSON87b]) is required. At this stage it is worth noting that the contractual operations, and the contractually required reports that they help provide, are not intended to replace the normal informal or semi-formal (eg project meeting) within-project communication mechanisms, but to supplement them with formal communication paths that are guaranteed to correspond to the formal organization of the project. Contractors will thus get formal notification of subcontract problems (either via one of the reports required in the subcontract specification or by the absence of a scheduled deliverable), but corrective action may well be triggered by prior information acquired by less formal routes.What does the contractor do? There are two options: Deal with the problem. Providing that it can be done while remaining within the constraints of the contract specification, the contractor is free to re-organize the contract work as much as necessary. This might be as simple as finding some additional resources to staff one new subcontract (the problematic subcontract will have to have its specification modified, of course), or as extensive as cancelling all the existing subcontracts, effectively deleting the complete sub-hierarchy, re-planning the work and issuing a new set of subcontracts. Pass the problem up the hierarchy. The client (that is, the contractor at the next level in the hierarchy) will now have the same two options available to resolve the problem. As usual, the power of the approach is exposed when examining what happens when things go wrong rather than what happens when they go right. When a contractor cannot complete an assigned task within its schedule, or with the available resources, or at all, some sort of 'iteration' ([DOWNSON87b]) is required. At this stage it is worth noting that the contractual operations, and the contractually required reports that they help provide, are not intended to replace the normal informal or semi-formal (eg project meeting) within-project communication mechanisms, but to supplement them with formal communication paths that are guaranteed to correspond to the formal organization of the project. Contractors will thus get formal notification of subcontract problems (either via one of the reports required in the subcontract specification or by the absence of a scheduled deliverable), but corrective action may well be triggered by prior information acquired by less formal routes.What does the contractor do? There are two options: Deal with the problem. Providing that it can be done while remaining within the constraints of the contract specification, the contractor is free to re-organize the contract work as much as necessary. This might be as simple as finding some additional resources to staff one new subcontract (the problematic subcontract will have to have its specification modified, of course), or as extensive as cancelling all the existing subcontracts, effectively deleting the complete sub-hierarchy, re-planning the work and issuing a new set of subcontracts. Pass the problem up the hierarchy. The client (that is, the contractor at the next level in the hierarchy) will now have the same two options available to resolve the problem. ISTAR goes further than many environments by retaining a permanent record of all contractual operations executed in the course of a project. Although these operations are essentially local, the record of them constitutes an implicit description of the process followed. This is a step in the right direction. Future environments will need to make these descriptions explicit so that they can be used as a basis for progressively improving the software process.