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.
Regarding your Q1 and Q2: I suppose that IBM will have to improve read permissions so that they can be assigned just as other permissions. Actually, it is totally incomprehensible to me, why IBM chose to not have “real” read access permissions – and why thus IBM chose to limit DNG’s capabilities so drastically.
A) For may users “need to know” will be non-negotiable.
B) I’m unnecessarily limited if I have to setup my projects based on my today answer to your Q1 (“Do you have a NEED to make some of the data completely inaccessible to some users”). Ok, let’s assume I set it up accordingly. There is a very real chance, that this answer might change over time. Why should I then have to rebuild my project-setup? Even more so as – just as you stated – so much other things only work in and depend on the project scope (like e.g. “reuse”/hard-linked artefacts and team areas).
The issue of need-to-know read access is typically industry dependent, and many organizations exist quite comfortably without those restrictions. For those with the restrictions, my experience is that the boundaries are usually quite clear at an early stage. It is a workaround to base Project Area boundaries on this restriction, but, I think, not an intolerable one. If the multiple PAs are put into a Global Configuration then basic ‘link to’ and ‘link from’ relationships are possible with full OSLC support.
When looking at version and variant management, we are likely to be considering the use of components. Components behave similarly to Project Areas in many ways, reuse and linking being two examples. A good workaround, supported by defined practices, will make many limitations far less significant than they first appear. Understanding these limitations, and the genuine project needs is the first step towards exploiting the best features of a tool.
In some cases, DOORS Next Generation may not be the right tool for the task. DOORS 9.x is still in active development and a good alternative in some environments. It does offer fine grained access controls and if that is your number one priority then it may be a better option.