Re: Do You Get What You Measure?

Responding to Phlip...

I thought CMM[I] Level 5 specified that all teams were aware of each others' practices, not necessarily obeying them.

The CMM applies to an organizational unit and that is a quite flexible notion. In addition, processes have different levels of abstraction, just like objects. So at the level of, say, a 6-person team one could have a quite detailed suite of processes that everyone on that team practices (e.g., such as those XP dictates). Similarly, a 6-person team down the hall would have a detailed suite of processes that everyone on that team needs to follow. But those two teams might have quite different processes in detail because of differing development environments.

However, at a higher level of abstraction the organization containing both those teams, say a Product Group, would also have a suite of processes defined at a higher level of abstraction. Both teams would follow those processes but their local processes would provide the detail.

What you are referring to is, as AndyW points out, really L3 where infrastructure is provided to ensure different groups can coordinate. For example, if the two teams above are building different subsystems in a larger application, they need to negotiate interfaces between those subsystems and the requirements need to be clearly allocated to those subsystems. To do that one needs a process infrastructure at a higher level (Product Group) than the detailed processes the individual teams use to implement a particular subsystem. CMM L3 defines what the higher level organization needs to do to ensure that coordination takes place properly.

That's because a fundamental thesis of process improvement
is that it is self-correcting and will converge on the optimal process
for the environment regardless of where one starts out.

Assuming there is one optimal process, which equates to the assumption
that there is one and only one "risk profile" for software projects.


And that's why not all teams converge on the same spot.

Right. What is an optimal development environment for one team may not be optimal for another. But within a given environment at a given level of abstraction the processes should be the same for everyone.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Digilent FPGA & Handel-C
    ... > questioning was whether C was a higher level language - NOT that it was ... "lowest level of abstraction", combined with the problem of just what ... C has complex state machine functions in the form of looping combined ... Concurrency, Bus I/O's, reusable design elements/interfaces, etc ... ...
    (comp.arch.fpga)
  • Re: Translation
    ... I don't think the diagrams of UML are a higher level of abstraction than, say, Java. ... So I see diagrams to code as a 1:1 translation without a lot of benefit. ... In that face of all that, how can UML not be at a higher level of abstraction than any OOPL??? ...
    (comp.object)
  • Re: OOA?
    ... This point is semantically correct, but it leaves out the concept of ... An OOA model exists at a ... higher level of abstraction than a 3GL program. ... This is a higher level of platform independence than a 3GL can ...
    (comp.object)
  • Re: Test Driven Development
    ... translation is just programming at a much ... higher level of abstraction where only pure business requirements are ... abstraction, it should Just Work. ... OOA graphical models are /always/ developed as a full team effort ...
    (comp.object)