How big is a project?

How big is a project… or more specifically, how big should a DOORS Next Generation project be. Where do we draw the project boundaries in DNG. The answer, of course, is ‘it depends’, the trick is to know on what it depends.

At one extreme, you run a single project and have everything in there. At the other extreme, each ‘document’ sits in its own project. Neither of these extremes is ever likely to be useful, but there are reasons for leaning in one direction or another.

As a starting point, I would suggest considering a real world project, the scope that has a project manager, to be suitable for consideration for a DNG project. This is the same starting point that I always set for DOORS Classic, and, just as with DOORS Classic, there will be very good reasons for sometimes extending the scope, and sometimes reducing it. We start with this position because it makes sense from a language point of view, and an organizational point of view.

What does a Project Area give us? The type system is defined for the project area (attributes, artifact types and more). This means that within a PA the type system is consistent. Custom link types are also defined within the PA and can be used within that PA. Users join a PA and can see everything in there, although edit access can be controlled through the use of Team Areas. Artifacts can be reused within a Project Area. There is an overhead associated with setting up and managing each Project Area.

Why would we not want everything in a single Project Area? Read access is the most obvious starting point. The roles within a PA controlling who can change the type system and other administrative responsibilities are set for the whole PA. Having one single project leads to a potentially unmanageable pile of data, making navigation more difficult.

The process of deciding on project boundaries starts with the right questions. I have given a laundry list of items above that affect that decision, but now let’s go through some meaningful questions.

Q1. Do you have a NEED to make some of the data completely inaccessible to some users? If the answer is yes to this one, then you are best to look at separate project areas based on the read access requirements.

Q2. How much do you trust your users? Can you trust team leads for one area who need some administrative privileges to not change (accidentally or deliberately) settings in another part of the project? If you users are well trained and you do not have a company culture of scapegoating then you can tend toward the larger project scope. This is also a consideration if you are collaborating across organizational boundaries.

Q3. Are you going to rely on just one or two users to do all the administrative tasks? If this is the case, then you are again tending to larger project scope to make their lives easier.

Q4. Do your real world projects have natural divisions in them, where there is very little traceability between subdivisions? These narrow channels in the mesh of traceability make great Project Area boundaries. They are usually associated with a change of team as well. Consider every artifact as a physical index card, and every traceability as a piece of elastic joining two index cards. The task here is to cut through as few elastic strands as possible, without separating the logical, hierarchical collections of index cards. Any links that do go across Project Area boundaries will have to be of the inbuilt types, not of custom types. A good candidate for a separate project is a set of standards that will be referenced from multiple projects. By using Global Configurations and Streams for the different versions of standards, this can be maintained separately from the development projects.

Q5. What other tools are in your environment? Do the project boundaries in any of those tools push you to a solution in DNG by the nature of the integration.

Q6. Are you reusing requirements? Reuse of requirements, where the same artifact is used in multiple places can only be achieved within a project. In many cases linking is more appropriate than reuse, so be sure you do actually need to reuse.

Q7. How big is your project going to be?  Sluggish performance can be mitigated to some extent by better hardware; more memory and faster disks. The best current guidance is that Projects shouldn’t be more than about 500k artifacts, and modules not more than 10k artifacts. Bear in mind that this is not a hard limit, and performance will be better with smaller projects and better on more capable hardware.

Q8. How disciplined can you be about naming conventions? Bear in mind that when you create a baseline, you are baselining the Project Area, or at least your stream in the Project Area if you are working in a Configuration Managed PA. Naming conventions help you to make sense of the purpose of an individual baseline, but for a very large PA this can become unwieldy. Similarly when working with configurations, a solid naming convention is important, and a larger scope will inevitably lead to more opportunity for confusion.

Q9. Do you have any sort of variant or version management to handle? This is where things get really tricky and you probably need to go down the route of Configuration Management. This is a big topic, and has become a little bigger still with the introduction of Components in 6.0.3. The choices here will almost certainly affect the choice of project boundary. The use of Components is a large topic in its own right, and is one that I intend to cover in the future.

Some things will push you towards a larger Project Area, and some towards a smaller Project Area. Every organization will have a different balance of priorities, so there is no one, simple, answer. Above are some of the factors to consider; there will be others. The biggest factors are likely to be user management, and administration overhead. The niceties of things like managing reviews, having consistent glossaries and mapping 1:1 to real world projects will be secondary in the practical decision making process.