Re: Configuration Control of Information Jonathan S. Shapiro (
Mon, 17 Apr 2000 22:58:48 -0400

I'm really really glad that Valerio sent his requirements note, because he's just proven my case for why a scripting language is desired.

Two things are simultaneously true about his proposed policy:

  1. It is exactly perfect.
  2. It is completely broken.

What am I talking about?

There are two (related but) seperate goals that are conflated in his note. One concerns control of configurations. This is about establishing "consistent cuts" of a work whose development is underway. The other goal concerns what we might call "work flow" or "work process" or "qualification procedures" or a bunch of other names I can think of.

The particular process that Valerio advocates is a good one for some purposes. I've known companies that followed it. For some it has worked very well. For others it would be truly truly terrible.

Work flow processes need to match the needs of the particular project and organization, and often need to evolve with the project.

If DCMS has a universal scripting language, then we can view DCMS as a programming environment for building workflow solutions. We could implement Valerio's requirements for some project. We could implement the Common Criteria two-party validation requirements for another. We could implement one set of requirements for "production" branches and a more liberal set for working developer branches. It's actually useful to be able to check things in on a development branch that don't compile!

My point is that policy is something you build on top of a good CM system. The CM system needs to support the mechanisms needed for appropriate policies. It should probably arrive with some carefully designed policies you can use "out of the box." It should be possible to set up a particular policy for a project and know that it will be enforced by DCMS.

All that being said, DCMS definitely should *not* impose a particular work flow policy unilaterally across all projects. The only policies that DCMS should enforce are those that concern correctness of the underlying semantics.

So I propose that we should restate Valerio's message in the form: "Here is a policy I want to be able to enforce in my workplace. DCMS needs to provide the tools that let me implement that policy." Then I agree completely.

From: "Valerio Bellizzomi" <> To: <>
Sent: Monday, April 17, 2000 7:09 PM
Subject: Configuration Control of Information

> Hello,
> in the following lines I will describe what kind of work spaces
> work areas, etc.) should be present in a useful CMS:
> * Engineering Workspace
> - Holds all information that is under development or being changed, that
> has not been approved for program use or release;
> - The information may be changed by the individual responsible for the
> product as the approving agent;
> - The content is controlled by the individual responsible for the
> information;
> - Workspace is owned by the engineer doing the work.
> * CM Workspace
> - Stages of documentation and software re-creating (compiling) and
> releases;
> - Holds tools and files used by the project, or needed to build or
> control project information and/or deliverables:
> - Project plans, procedures, and reports;
> - Schedules, budgets, and CM records;
> - Audit trails, records, and lessons-learned information essential for
> certification, approval, or acceptance.
> - Workspace is owned by CM, with read-only privileges to all other
> organizations.
> * Controlled Project Area
> - Holds all information or documentation that has been accepted for
> release inside the program but has not yet been accepted by the customer
> owner of the information at a higher-level life cycle for inclusion in a
> baseline;
> - Includes information approved for internal release through passing of
> quality gate;
> - Requires that the program establish a process for CM of evolving
> information that is shared within the project by different organizations;
> - This information cannot be updated unless the change is authorized by
> an established project board;
> - Project area is owned by CM, with read-only privileges to all other
> organizations.
> * Test Area
> - Holds all test documentation and versions of software released for
> from CM;
> - Test scenarios, data, and results;
> - Test configurations;
> - Test cases;
> - Software configurations under test and configuration documentation;
> - Special test data, records, and audit trails.
> - Test area is owned by the test manager.
> * Customer-Controlled Workspace
> - Holds all customer-approved baselined and approved information:
> - Functional
> - Allocated
> - Product
> - Records and reports
> - Other approved or delivered information
> - This area cannot be updated unless the change is authorized by the
> customer;
> - Workspace is owned by the customer.
> val.