The Subcontracting Scenario Concept
We can define typical scenarios to understand the multiple subcontracting strategies based on the Rational process. Each scenario has a remarkable characteristic that predominates in the set, and many other secondary characteristics that result from the first one. A real project case can use more than one scenario to represent its problem.
The main characteristic of a scenario is to define what point, in the development process, the contracting organization wants to reach. In other words, which software models the contracting party wants to produce internally. This subset of models can give it internal communication security, control over the problem, and is probably already part of the developer and manage experience. The immediate implication in terms of RUP is to ask which artifacts the contracting party will it execute and which ones will purchase from third parties. This can be said in a different manner: based on which model (Artifact) does the contracting party want to contract service execution?
But the scenario isn’t characterized solely by the choice of artifacts; it also implies a structure for the subcontracting project. You need to decide if external personnel will have access to the project’s stakeholders, whether the development and test environment will be internal, if homologation will involve internal clients. There are implications resulting from the type of model you choose and want to contract with; the transferred risks can return in the form of other short- or long-term risks. All of these considerations constitute the subcontracting strategy that is implicit in selecting a scenario.
In the scenarios we will describe, the basic assumption is that the contracting organization adopts RUP to its fullest extent. That it applies, internally, the iterative lifecycle model planning and management but wants to subcontract parts of its projects from organizations that don’t necessarily adopt RUP, or perhaps adopt it but customize it for their own needs. The contracted organization must have a reasonably well-defined process, it should be flexible enough to attend to the contracting, execution, auditing, and documentation requirements the contracting party will impose.
There are six scenarios of true interest when analyzing subcontracting:
Scenario 1: Subcontracting Based on a Use Case Model
The contracting party defines the Use Case model and contracts development from there.
Scenario 2: Subcontracting Based on an Analysis Model
The contracting party elaborates the Use Case and Analysis models (Static Class Diagram) and contracts development from there.
Scenario 3: Subcontracting Based on a Design Model
The contracting party elaborates the Use Case, Analysis (optionally), and Design (Static Class Diagram) models, checking the architecture and validating the main project risks and architectural issues. It contracts development from there.
Scenario 4: Programming Subcontracting
The contracting party elaborates the Use Case, Analysis (optionally), and Design models. It remains in charge of developing these models. However, the programming part is outsourced in the “software factor” molds. In this scenario, the code the contracted party generates is integrated and the contracting party performs the homologation tests.
Scenario 5: Test Subcontracting
The contracting party elaborates the Use Case, Analysis (optionally), and Design models. It implements the code, but the tests are outsourced in the “test bureau” molds. In this scenario, the bureau is in charge of planning, administrating, and performing the tests.
Scenario 6: Subcontracting Programming and Tests
The contracting party elaborates the Use Case, Analysis (optionally), Design, and Test models. However, the contracted party is in charge of program implementation and test application. (This is a hybrid mode mixing Scenarios 4 and 5, however, with the difference that the contracting party retains the domain and the knowledge in tests, and only outsources its application).
Hybrid, Trivial, and Canonic Scenarios
The actual subcontracting cases may be considered variations of these six scenarios, hybridized or not, composing a specific subcontracting case. This specific case must be described in the subcontracted party management plan and referenced in the project’s Business Case and Development Case.
There are special, secondary interest cases that may satisfy highly particular conditions. For example, there is the scenario in which a contracting party, because it doesn’t have the necessary knowledge about a certain business domain, orders a Business Analysis model for the contracted party, specialized in the business area. In this case, the contracted party may request the application design model itself from as an initial development for the product in question (product concept). The interest here is nearly academic and does not correspond to most common commercial developments.
The trivial scenario, in which the contracting party requests the entire development from the contracted party, as if it were a client, characterizes precisely the client/stakeholder roles RUP itself deals with, and it is summarized in the client-vendor relationship in which the contracting party is the client. Obviously, this scenario will not be dealt with here.
The basic hypothesis, implicit in the six scenarios, is that the process the contracted party uses may not be RUP, at least in its totality, thus, the need for using the equivalent artifact concept. But would it not be possible to understand the six scenarios in which both sides, contracted and contracting, use the exact same RUP configuration? Yes. There may certainly be a case in which both organizations use the same RUP configuration, exactly out-of-the-box, with no customization. This situation is an exception, as RUP itself teaches and stimulates us to customize the configuration in a process implementation. Even for two organizations that use RUP, the artifact mapping idea is necessary, although in many cases it is facilitated.
When both organizations used the same process framework, the six scenarios that were presented would be treated with the conceptual arsenal that exists in RUP; the management forms, the roles, and exchanged artifact content would be well-defined and the process dynamics would follow the known iterative cycle norms. Nonetheless, we would define, in the subcontracted management plan, each part’s artifacts and responsibilities based on one or more subcontracting scenarios (referred to in the Business Case and Development Case). When this subcontracting situation occurs, with any scenario, we can call it canonic; the process itself is defined, and we only need to solve artifact details.
_________
This post based on a whitepaper from IBM’s Rational software division. “Managing Subcontractors with Rational Unified Process”.