One often-overlooked aspect of designing a configuration management system is the definition of components. Although you won't know what all of the components of your system are at the beginning, with your knowledge of the system you should still be able to group things pretty well. You should also consider the actors of your CM system when defining components. Don't forget about the product's supporting files, such as licenses, documentation, releases, and so forth.
Consider the following small project named "Kish," as illustrated in Figure 8.4:
kish_adm Administration VOB for labels, branches, triggers, and supporting CM scripts.
kish_process This is a process VOB. UCM likes to use this to store information about the project in the VOB.
kish_doc Documentation VOB. Your technical writers need a place to put their information.
kish_src Most products have some kind of source that gets compiled.
kish_release We prefer to store the releases in a separate VOB from the source. It gives us the opportunity to multi-site the VOBs separately and scrub them differently.
kish_test Most test harnesses become larger than the code base itself. This is great again for multi-site purposes.
Figure 8.4 VOB Layout
These VOBs can be broken down into more VOBs, according to the project size. We will talk about that in the next chapter.