Analysis of architectures for defect tracking integration

The replication architecture achieves this by replicating defect-related data from Perforce's database to the defect tracker's database and vice versa. The data to be replicated includes Perforce jobs (corresponding to defect tracking issues) at the very least, and may also include users, groups, and permissions (2.56.1), changelists and fixes (2.5.1), and a proposed job/filespec relation (2.43.1).

Fields are added to the replicated relations to elp the replication daemon do the right thing. Fields are added to the jobs relation (a) to indicate if the job is to be replicated and if so, to which defect tracker (2.97.1); (b) to indicate to which defect tracking issue the job corresponds to.

The replication daemon distinguishes changes made by users of either system, and changes made by the replication daemon in replicating an entity (otherwise the replication daemon may replicate its own changes). There may therefore be extra fields added to the jobs relation to indicate whether each job has been replicated or not. (The same remarks apply to the users, groups, permissions and job/filespec relations but probably not to the changelist and fixes relations since these are replicated in one direction only).

Race conditions mean that the databases may become inconsistent. The replication daemon quickly detects each inconsistency and takes appropriate action [GDR 2000-05-08, 3.2.4].

Estimating the rate of inconsistencies

To estimate how much inconsistency there will be, and therefore how often an administrator may be required to make an intervention, I will build a model of defect resolution activity that predicts frequency of inconsistency as a function of database size and load.

An inconsistency arises when an entity is changed simultaneously in both the defect tracker and in Perforce, where "simultaneously" means "within the latency of the replication daemon". For example, a manager might reassign a task while simultaneously the original developer successfully makes a change which should not have been permitted.

Suppose there are d active defect records in the system, that there are u users of the integrated system (suppose that half use Perforce, half use the defect tracker) and each user makes c changes each working day, distributed uniformly across the active defects and throughout 8 working hours. Let the latency of the replication daemon be l seconds. Then there are 28800/l latency periods in the 8 working hours (since 8 hours is 28800 seconds).

Hence there are 28800d/l combinations of latency period with defect record, and in cu/2 of them someone is making a change in that record at that time in the defect tracker. So the chance of each change in Perforce hitting one of those combinations is cul/57600d and the expected number of inconsistencies created in a day is

Here are some predictions made by this simple model:

Scenarios a to c represent a medium sized organization with 10 people involved in defect resolution, each making 10 changes per day to 100 active defects. In scenario a, the replication daemon polls the servers every 5 minutes for new changes to replicate, so the latency is 300 seconds. In scenario b, the replication daemon is triggered by the servers whenever a change happens, and completes the replication in 5 seconds, and in scenario c, the replication daemon completes the replication in 1 second.

Scenarios d to f represent a large organization with 100 people involved in defect resolution, each making 40 changes per day to 1000 active defects. The latencies are as described above for scenarios a to c.

It is clear that inconsistency will be a serious problem for large organizations if replication has a high latency.

The activity in the system is likely to be clustered at certain times, for example when a manager starts working on the defect tracking system and asks everyone to "bring things up to date" and "where is such and such?". Or if there are scheduled builds and everyone races to submit their changes in time for the build. This factor may make the rate of inconsistencies higher than the model suggests.

On the other hand, people do not work in the random fashion suggested by the model. Any sort of workflow discipline means that only one person is working on a defect at a time. It is only the manager who is outside the workflow who can create inconsistencies. This factor may make the rate of inconsistencies lower than the model suggests.

So I need to work out the common scenarios by which inconsistencies are introduced and make a more detailed model that incorporates these scenarios.

It appears from the simple calculations above that it will not be acceptable for the replication daemon to poll the servers. To make the latency small (and hence make the rate of inconsistencies small) the servers trigger the replication daemon. One consequence of this is that the Perforce server has triggers that run whenever any defect-related data changes. This is why triggers are included in the consideration of requirements 21, 76 and 77.

The predictions of the model suggest that the replication daemon needs performance tuning when it is installed. The documentation covers this.

Using with tracker-client architecture

The replication architecture is used in parallel with the tracker-client architecture (2.39.1).

Consider the case where a developer using the defect tracker's interface simultaneously submits a change and completes a task. From the point of view of the defect tracker this is two operations: submit the change (using the Perforce client API) and complete the task (using its own API and eventually its own database). The defect tracker waits for the submit operation to complete before it can close the task. But there is a race condition: the replication daemon may replicate the closing of the task to the defect tracker's database before the defect tracker's client can close the task. So the client probably gets a "cannot close task: task already closed" error message. This is both annoying for the user and can lead to incorrect database state since there was probably extra information related to the closed task that was available to the defect tracker's client but not to Perforce or the replication daemon that consequently is not in the defect tracker's database.

However, there is no problem if the defect tracker omits to close the task via the submit operation. In this case the replication daemon replicates the association between the changelist and the task, but the task remains open for the defect tracker's client to close.

So we need to instruct developers of tracker-client integrations not to close tasks via the Perforce client interface if they plan to close them using the defect tracker's interface.

Bringing things up to date

If one server or the other is down, the replication architecture allows defect resolution activity to continue on the other server. If the network connection is down, the replication architecture allows defect resolution to continue in parallel in both systems. In these circumstances the replication daemon fails to replicate the changes (there may be some way to set a policy option for whether it should silently fail or alert someone?). But when the other server (or the connection) comes back up, the replication daemon takes all the changes that have taken place, replicates them and notes inconsistencies for an administrator to fix.

The single-database architecture achieves this by storing each defect-related entity only once, in the defect tracker's database.

The defect tracker makes queries and changes only to its own database. This means that it does not use a two-phase commit protocol to ensure consistency.

Perforce makes transactions that affect both databases, so uses a two-phase commit protocol to make sure that the databases remain consistent. This has the consequence that transactions in Perforce which affect defect-tracking data (and this includes every submit) may be slow, because Perforce locks the affected data in both databases (one possibly across a network connection) before it can start its transaction. There is also the risk of deadlock if (for example) the network connection to the defect tracker's database goes down while Perforce has some records locked.

If the defect tracker's database does not provide transaction support or record locking then it will not be possible for Perforce to do two-phase locking and thus maintain consistency when the defect tracker is updating its database simultaneously with Perforce.

This need for Perforce to implement a two-phase commit protocol to ensure consistency means that effort will be required to implement it (2.76.2).

The single-database architecture is used in parallel with the tracker-client architecture (2.39.2). A similar consequence to that for the replication architecture follows: we instruct developers of tracker-client integrations not to close tasks via the Perforce client interface if they plan to close them using the defect tracker's interface. (The reason is slightly different: in this case there is no race condition to worry about because Perforce always updates the defect tracker's database).

Note that in the single-database architecture, defect resolution using Perforce cannot continue if the defect tracking database (or the network connection between them) is down.

The union architecture achieves this by storing each defect-related entity only once.

The database unifier provides distributed transactions as part of its unified view of the two databases, so that the databases remain consistent. By this I mean that it offers transaction support for the combined databases - when a change affects both databases it either happens in both or doesn't happen at all. And other systems accessing data in either database while the transaction is being prepared see a consistent state, not a half-complete change. This means doing two-phase locking on the resources in both databases (with the same consequences as for the single-database architecture if the defect tracking database does not support transactions).

In the absence of transaction support in the defect tracker's database, the database unifier could attempt to enforce consistency by serializing all transactions, but this will result in a performance impact (how much?). It also won't work when there are other systems accessing the defect-tracking data in the database (unless these other systems also use the database unifier, but that is beyond the scope of this project).

The union architecture is used in parallel with the tracker-client architecture (to meet requirement 39). A similar consequence to that for the single-database architecture follows: we instruct developers of tracker-client integrations not to close tasks via the Perforce client interface if they plan to close them using the defect tracker's interface.

Note that in the union architecture, defect resolution using either Perforce or the defect tracking system cannot continue if the other system (or the network connection between them) is down.

The tracker-client architecture cannot by itself keep the databases consistent, since changes to defect-tracking entities made through Perforce's interface do not cause corresponding changes in the defect tracker's database. Recall that there is a requirement that developers can use the Perforce interface (2.41.4). For example, a developer might check in work that completes a task, but this does not record anywhere that the task is completed, so the database is inconsistent until the developer goes to the defect tracker's interface and marks the task as completed.

The tracker-client architecture will be used in parallel with whichever other architecture is chosen. See the discussion for the other architectures (2.1.1, 2.1.2, 2.1.3) for the consequences.

The fixes relation in Perforce associates a change with a job. So to discover why a particular file is the way it is using the Perforce interface, a user finds the changelists that contributed to the file, queries the fixes relation to discover the jobs which caused the changes to be made, and looks at the job descriptions to discover the defect or customer requirement that motivated the changes.

In order for this to be reliable, developers need to work in a disciplined fashion - they need to record the reason for each change. The integration makes it easy for developers to work in this disciplined way.

A field is added to the fixes relation to record the nature of the association between the job and the change (for example, the change solves the defect, or contributes to the solution, or is a regression test for the defect, or backs out an incorrect solution, and so on). The field takes user defined values.

In the replication architecture, SCM data is replicated into the defect tracker's database, and defect tracking data is replicated into Perforce's database. This means that queries involving both systems can be made by making ordinary SQL queries of the defect tracker's database. The Perforce client provides interfaces for making these queries of Perforce's database.

If queries combining defect tracking and SCM data are to be made by making SQL queries of the defect tracker's database, it will be necessary to replicate all relevant relations from Perforce to the defect tracker's database. This includes the changes and fixes relations, and the proposed relation between jobs and filespecs. (Note that as long as it is possible to create tables in the defect tracker's database, it should be easy to replicate changes and fixes, since they only get added to, never updated.)

Note that because there is a delay after making a change to one database before the change is replicated to the other database, a query made of one database suring this period of delay will get an incorrect answer. There may therefore be a need to prevent further changes to the database and wait for existing changes to be replicate before making a query. (Alternatively, there is some way of telling whether the result of a query was consistent, that is, did not fall into the period of delay before replication of some change.)

In the tracker-client architecture, the tracker client can query the Perforce server, and combine the data returned with data from its own database. However, this is much more complex than making SQL queries of a single database and this complexity is probably prohibitive (one can imagine that the easiest way to do this is for the developer of queries to replicate the changes and fixes relations into the defect tracker's database and then make SQL queries of that database, but this is just what the replication architecture does (2.5.1).

It should also be noted that the state of the product sources are not consistent with the information in the defect tracking system (2.1.4) so queries of both systems will produce wrong answers.

The tracker-client architecture already works out of the box with TeamTrack and Perforce. TeamTrack supports the Microsoft Common Source Code Control API [Shaw 2000-06-05], and Perforce supports the SCC API [Perforce TN 34].

Note that Microsoft's SCC API is not an open standard [Bannister], so using it exclusively violates our requirement 23.

To support the attach and detach operations in an integrated way, Perforce supports a relation between jobs and files or filespecs (2.39).

The other operations should be straightforward to support, since Perforce supports the Microsoft SCC API which is used by DevTrack to integrate with Visual SourceSafe.

The tracker-client architecture may work out of the box in Remedy, because according to [Remedy 4.5 FAQ], Remedy supports the Microsoft Common Source Code Control API: "Remedy has built an interface to the SCC API so we can talk to these tools and allow Remedy application developers to save their applications with version numbers and check in and check out code."

Perforce supports the SCC API [Perforce TN 34]. However whether Perforce really works together with Remedy needs to be checked.

Note that Microsoft's SCC API is not an open standard [Bannister], so using it exclusively violates our requirement 23.

Bugzilla uses a Perl interface to talk to MySQL using MySQL's own network protocol. The database unifier understands MySQL's protocol in order to intercept it.

The replication daemon is the only part of the replication architecture which interfaces to the defect tracking system. It does so through the defect tracking vendor's database interface module [GDR 2000-05-08, figure 2]. The replication daemon should consist of a "vendor-independent replication module", which talks to the Perforce server, but which also uses the "replication interface" to talk to the "vendor-specific replication module" which talks to the defect tracking vendor's database interface module. Only the vendor-specific replication module is rewritten for each integration.

The developer of the integration learns enough about the integration kit and the tools it uses that they understand how the integration works and how to proceed. Estimated effort: 1 week. They also learn about the defect tracking system (since the requirement is that any third party can carry out the integration, not just people who are experienced with the defect tracker). Estimated effort: 2 weeks. (This learning will of course be interleaved with the steps outlined below.)

The developer decides how the relevant entities in Perforce's database (jobs, changelists, fixes, the proposed jobs/files relation) correspond to entities in the defect tracker's database. Estimated effort: 1 week.

For each corresponding entity, the developer determines which fields in one database map to which fields in the other, and writes code to transform the data in each corresponding field. I estimate 1 day per entity to write the conversion code and 3 days per entity to test it. So 16 days for this step.

The vendor-independent replication module should notice and handle inconsistencies (by using the vendor-specific replication module to transform the corresponding entities, and then comparing the results). So no effort here.

The developer of the integration also provides some way for the replication daemon to discover when the defect tracker's database changes. There are four ways of doing this:

1. Database triggers in the defect tracker's database server. A trigger is written for each entity that may change. The trigger code uses COM (on Windows) or some protocol running over TCP/IP (otherwise) to talk to the replication daemon. Assuming that the database supports triggers that can make these external calls, and we supply the replication daemon with a module that allows it to respond to these triggers, I estimate 1 day per entity to write and 3 days to test each trigger, for 16 days effort.

2. The replication daemon polls the defect tracker's database for changes. Estimated effort: 1 week to write, 3 weeks to test.

3. The defect tracker's client notifies the replication daemon of changes. This will possibly involve adding notification code to every write to the database. The most effective way to do this is to add this code to the defect tracker's interface module. Estimated effort: 16 weeks.

4. The defect tracker's client replicates changes itself, using the Perforce client API. This solution does not belong to the replication architecture, but to the variation of the tracker-client architecture [GDR 2000-05-08, 3.1.2].

Total effort required: from about 10 weeks to about 23 weeks.

The developer learns about the integration kit and the defect tracker, as for the replication architecture. Estimated effort: 3 week.

A similar module to the one described for the replication architecture is required for the single-database architecture. This component is part of the Perforce server [GDR 2000-05-08, figure 5].

Since it is not possible to give third parties access to the Perforce server code, the Perforce server is rewritten so that it can be configured to use an open interface (the "Perforce server defect tracking database interface") by which it accesses and stores job-related data (see 2.76 for estimation of effort for this). This interface connects to a defect-tracker-specific module (the "Perforce server defect tracking database module") as outlined for the replication architecture. Such a module could be supplied as a shared library that is named when the Perforce server is started, or as a server that the Perforce server talks to across the network.

The effort required to rewrite this module for a new defect tracker is the same as required for the replication architecture: 1 week to design the correspondence between entities and 16 days to implement and test.

Note that the module as described runs on the same machine as the Perforce server, which may be on a Unix system while the defect tracker's interface module offers a COM interface which is only callable from a Windows system (is this true?). In this case we move the module to a Windows system and have the Perforce server talk to it across the network for each read and write. However, this is delivered as part of the kit and is be rewritten for each vendor.

Total effort required: about 7 weeks.

I am assuming here that the database unifier intercepts the actual back-end database protocol used by the defect tracker (for example, ODBC, or SQL over TCP/IP, or some database-specific protocol such as MySQL's database protocol) rather than intercepting calls to the defect tracker's interface module. (The architecture proposal [GDR 2000-05-08, 3.3] is not clear about this.) If the unifier intercepts calls to the defect tracker's interface module it is hard to see how any significant reuse can be got out of this architecture, since a lot of the unifier is rewritten for each defect tracker.

Note that if all entities are stored in the defect tracker's database then there seems to be no point in considering the union architecture since it boils down to a complicated way to implement the single-database architecture. So some entities must be stored in Perforce's database for it to be worth considering this architecture at all (the fixes relation might be a natural candidate).

The developer learns about the integration kit and the defect tracker, as for the replication architecture. Estimated effort: 3 week.

I imagine the database unifier to be implemented using something like the following components:

1. A fairly abstract internal model of how to represent database queries and database objects.

2. A catalog detailing which entities live in which database and how the two views of them correspond.

3. An entity mapper that can convert entities and fields from the two external formats to the internal format and vice versa.

4. A front-end to the Perforce server which can convert Perforce entities to and from entities in the internal model.

5. A back-end to the Perforce database which can convert entities in the internal model to and from Perforce entities.

6. A front-end that understands the defect tracker's database protocol and which can convert database queries into the internal model and can convert results in the internal model into database replies. For example, this may involve a SQL parser.

7. A back-end that understands the defect tracker's database protocol and which can convert queries in the internal model into database queries and can convert database replies into results in the internal model.

8. Interfaces that cleanly separate the parts of the unifier that are private to Perforce from those that are public and configurable.

Components 1, 4, 5 and 8 are independent of the defect tracking system and can be supplied as part of the kit.

Components 2 and 3 are rewritten for each new defect tracking system. To write component 2, the developer analyses the entities and decide in which database they belong. This is substantially harder than deciding how entities correspond in the replication architecture, so I estimate 2 weeks. Component 3 is similar to the entity mapper for the replication architecture: estimated effort is 16 days.

Components 6 and 7 have to be rewritten for each database protocol. So this won't have to be done for each defect tracking system (for example, many defect tracking systems use ODBC to talk to the database), but it will have to be done for many. In the simplest case, much of the work for another defect tracking system may be re-used (for example, an SQL parser may already be available). Estimated effort: 16 weeks. There may however be no appropriate code available for re-use, so the database interface may have to be written from scratch. Estimated effort: 32 weeks. In the worst case, the defect tracker does not even have a protocol for accessing its database (for example, there may be no database server as in the case of using dbm as the back end). In this case the defect tracker is rewritten to use a database protocol, which the database unifier will then map back to the dbm calls. This may take another 16 weeks.

Total effort required: from about 8 weeks to about 56 weeks.

The time taken depends on how many features of the Perforce client are implemented. The simplest set of features that make sense is probably: browse the repository ("p4 files" and "p4 dirs"); add a file to the repository ("p4 add" + "p4 submit"); check out files for editing ("p4 edit") and check in files ("p4 submit"). I estimate 4 weeks to specify, write and test each of these features, for 16 weeks effort.

Note that this implementation involves changes to the defect tracking client interface, so is done by the defect tracking vendor (except in the case of open source defect tracking systems like Bugzilla, but there is an issue of who will support any changes we make).

This is straightforward. The replication daemon divides into a number of components with well-defined interfaces between them (2.21.1). The components and their interfaces can be easily documented.

The Perforce API is documented (2.22.4).

This can be done. The single-database architecture divides into a number of components with well-defined interfaces between them (2.21.2). The components and their interfaces can be easily documented.

The single-database architecture relies on an interface internal to the Perforce server. This public interface will restrict Perforce's freedom to make server changes in the future.

The Perforce API is documented (2.22.4).

The database unifier is very complex, and has a lot of database technology in it (2.21.3). Documenting the design will take a lot of effort.

The union architecture relies on an interface internal to the Perforce server (2.22.2).

The Perforce API is documented (2.22.4).

The replication architecture can be built with readily available and portable tools (2.24.1) so it should be straightforward to port.

Since the replication daemon accesses the defect tracking system's APIs (which may be platform-specific) the daemon runs on the same platform as the defect tracking system.

The replication architecture exposes one interface to third and fourth parties: the replication interface (between the vendor-specific replication module and the vendor-independent replication module. This interface specifies a set of entities that may be replicated and a set of events that may be responded to (for example, changes in the database). These specifications are flexible enough to allow Perforce to change the entities available for replication and change the events available for response.

The replication architecture commits Perforce to maintaining certain fields of entities (especially jobs, changelists, fixes) with particular meanings. However, it can add new fields to these entities if it wants to - not all fields are replicated.

The single-database architecture exposes one interface to third and fourth parties: the Perforce defect tracking database interface. This interface specifies a set of entities that Perforce may want to access and store from a foreign database. Perforce may want to change this set of entities, so the interface provides a way for this set of entities to change. So that the integration does not break when the set of entities changes, the Perforce defect tracking database module is able to say "no, I can't access or store that entity for you". In that case Perforce accesses ands store the entity in its own database as in the non-integrated case.

If Perforce changes the entity definitions of the entities stored in the defect tracker's database then the integration will break (since the database schema is now wrong). It therefore provides an update kit to update the schema for each defect tracking database each time it changes the definition of the entities.

The tracker-client architecture exposes the standard Perforce client interface. This commits Perforce to supporting a large set of operations on the server.

I don't know if this interface is flexible enough to support the addition of new fields to entities without breaking existing clients.

Note that Perforce is probably already committed to breaking this interface as little as possible because of the large number of installed Perforce clients that would need to be replaced.

See 2.44.1.

The defect tracking vendor provides an interface to Perforce changlists and the fixes relation.

We can use pending changelists, associated with jobs through the fixes relation, to indicate why files are checked out.

We can record the nature of this association in the "fixes" relation (2.49.1).

We can record the association between the files and the task in order to branch or merge them. This implies a new relation in the Perforce database between jobs and files or filespecs (2.43.1).

The Perforce API is extended to allow this relation to be queried and changed, and Perforce support it.

Alternatively, we provide separate utilities to branch and mere the files associated with a task. This is less satisfactory, because the utilities have to be ported to each platform where the Perforce client runs.

See 2.53.1.

The defect tracking vendors add interfaces to the relation between tasks and files allowing branching and merging.

See 2.55.1.

The defect tracking vendors add an interface to the relation between tasks and files. The interface records, queries and updates the nature of the association.

All the permissions requirements can be met in the replication architecture by replicating users, groups and permissions between the defect tracking system and Perforce. The idea is to apply some kind of (configurable?) policy to defect tracking system permissions or assigned users or whatever to get Perforce permissions covering files.

Note that Perforce doesn't have permissions covering jobs, so a crafty developer may be able to get around any restrictions by editing the permissions on some associated job (or just creating an appropriate job giving him the permissions he wants). This could be solved by changing Perforce so that its permissions cover jobs as well as files.

The replication daemon masquerades as the appropriate user when making changes or additions to the Perforce database and the defect tracking database. Both systems provides public interfaces allowing the daemon to masquerade as a particular user.

The Perforce server stores its users and groups in the defect tracking database. When a user tries to do something to a file, the Perforce server reads any relevant defect records and applies some kind of policy to determine if the user is successful. This implies another public interface in the Perforce server which it can use to get at the policy. This makes the integration less adaptable and supportable.

The Perforce server masquerades as the appropriate user when making changes or additions to the defect tracking database. The defect tracking system provides a public interface allowing Perforce to masquerade as a particular user.

The replication architecture requires the following from Chris:

1. Changes to the Perforce schema (Job/Filespec relation, addition to the fixes relation of a field indicating the meaning of the fix). Estimated effort: unknown, possibly 4 weeks?

2. Changes to the Perforce client API and to the various Perforce clients to support these schema changes. In particular, the procedures for opening files should allow the open files to be associated with one or more jobs (perhaps via pending changelists?) and the submit procedure should be changed so that it does not close open jobs by default, but rather allows the developer to specify the relation between the changelist and each job (contributed/fixed/backed out/other user-defined meanings). Estimated effort: unknown, possibly 4 weeks?

3. Triggers on Perforce operations that change the Perforce database. Estimated effort: unknown, possibly 4 weeks? (Many people have asked for pre- and post- triggers on all Perforce operations, so even though the defect tracking integration does not require so many triggers, it would be a good idea (and perhaps not significantly more work) to add them all.)

We are assuming here that Chris is the only developer at Perforce who can do this work. It may be the case that he can delegate items 2 and 3 (since they don't affect Perforce's database implementation) and review the work, but we are not depending on that.

Total estimated effort: about 12 weeks.

The single-database architecture requires the following from Chris:

1. See 2.76.1. 4 weeks.

2. See 2.76.1. 4 weeks.

3. See 2.76.1. 4 weeks.

4. Definition of an interface by which the Perforce server can access its job and fixes-related data when that data is stored in third-party databases (2.21.2). Estimated effort: unknown, possibly 4 weeks.

5. Rewriting the server so that it can be configured to use this interface instead of its usual database back end. Note the need for a two-phase commit protocol to prevent inconsistency between the two databases. Estimated effort: unknown, possibly 8 weeks.

We are assuming here that Chris is the only developer at Perforce who can do this work (2.76.1).

Total estimated effort: about 24 weeks.

The union architecture requires the following from Chris:

1. See 2.76.1. 4 weeks.

2. See 2.76.1. 4 weeks.

3. See 2.76.1. 4 weeks.

4. Definition of an interface by which the Perforce server can access some or all job- and fix-related data via the database unifier (2.21.3). Estimated effort: unknown, possibly 4 weeks.

5. Rewriting the server so that it can be configured to use this interface instead of its usual database back end. Estimated effort: unknown, possibly 8 weeks.

6. Definition of an interface by which the database unifier can access the Perforce database (2.21.3). Estimated effort: unknown, possibly 2 weeks.

7. Rewriting the server so that the database is accessible via this interface. Estimated effort: unknown, possibly 4 weeks.

We are assuming here that Chris is the only developer at Perforce who can do this work (2.76.1).

Total estimated effort: about 30 weeks.

I deduce from this requirement, together with requirement 78 and the schedule [RB 2000-02-02, 9], that the total effort for the project from Gareth and Richard is no more than 48 weeks and should be no more than 32 weeks.

Architecture definition and review, planning, communication with participants in alpha and beta programmes and management, tracking and oversight will take about 28 weeks of effort, as estimated in [RB 2000-02-02, 9].

In addition, the replication architecture requires the following components:

1. Definition of changes to the Perforce schema (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

2. Definition of changes to the Perforce client API and improvements to API documentation (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

3. Definition of trigger events and protocol (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks

4. Definition of interface between vendor-independent and vendor-specific replication modules. Estimated effort: 2 weeks.

5. Definition of interface and protocol between defect tracker's database triggers and replication daemon. Estimated effort: 4 weeks.

6. Development and test of vendor-independent replication module. Estimated effort: 8 weeks.

7. Extending the integration to work with two defect tracking systems. Estimated effort: 18 weeks to 44 weeks (2.21.1; note that we don't have to learn about the integration project, but we have to learn about the defect tracker).

Total estimated effort: from about 66 to about 92 weeks.

Requirements for effort and estimation of general project effort are as for the replication architecture.

In addition, the single-database architecture requires the following components:

1. Definition of changes to the Perforce schema (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

2. Definition of changes to the Perforce client API and improvements to API documentation (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

3. Definition of an interface by which the Perforce server can access its job and fixes-related data when that data is stored in third-party databases (2.21.2. 2.76.2). The implementation will probably be by Perforce but should be reviewed. Estimated effort: 2 weeks.

4. Implementing and testing vendor-independent parts of Perforce server defect tracking database interface. Estimated effort: 8 weeks.

5. Extending the integration to work with two defect tracking systems. Estimated effort: 12 weeks (2.21.2 and the note for the replication architecture).

Total estimated effort: about 52 weeks.

Requirements for effort and estimation of general project effort are as for the replication architecture.

In addition, the union architecture requires the following components:

1. Definition of changes to the Perforce schema (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

2. Definition of changes to the Perforce client API and improvements to API documentation (implementation probably by Perforce but should be reviewed). Estimated effort; 2 weeks.

3. Definition of an interface by which the Perforce server can access its job and fixes-related data via the database unifier (2.21.3, 2.76.3) (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

4. Definition of an interface by which the defect tracking vendor independent parts of the database unifier can talk to the defect tracking vendor specific parts of the database unifier. Estimated effort: 2 weeks.

5. Design, implementation and test of database unifier. Estimated effort: unknown, probably at least 16 weeks, perhaps as much as 32 weeks.

6. Extending the integration to work with two defect tracking systems. Estimated effort: 40 weeks to 110 weeks (2.21.3). The minimum effort for this stage is more than that implied by 2.21.3 because the first integration will necessarily be a difficult case involving interfacing with a new database protocol; the second integration may be easier.

Total estimated effort: 92 to 178 weeks.

Requirements for effort are as for the replication architecture. The general project effort will be lower than estimated if the tracker-client architecture is the only architecture implemented. Say half the estimated costs for the replication architecture, that is, 14 weeks.

The tracker-client architecture requires the following components:

1. Definition of changes to the Perforce schema (implementation probably by Perforce but should be reviewed). Estimated effort: 2 weeks.

2. Definition of changes to the Perforce client API and improvements to API documentation . The implementation will probably be by Perforce but should be reviewed. Estimated effort: 2 weeks.

3. Extending the integration to defect tracking systems is done by the defect tracking vendor (2.21.4) but we could do the integration for an open source defect tracking system like Bugzilla. Estimated effort: 16 weeks.

Total estimated effort: 34 weeks if tracker-client architecture implemented for Bugzilla.