A set of tools and process definitions.
In order of people's impressions, not of importance:
Project design recipes
Data dictionary tools
Design flow graphics aids
(semi-)Automated code generation
Code management
Responsibility definition
Phases of code review
Phases of certification/integration
General interface standards
Requirements definition process
Languages and variants
Coding dictums
Uniform library/utility resources
And why is experience with this methodology particularly relevant for experiments?
To some extent, we jumped into object-oriented programming "naked", without a set methodolgy.
CAP never "decided" to use O-O concepts; the entire approach to handling data was object oriented to begin with. So (other than using C++) a methodology was never "adopted" -- it just emerged.
We have evolved our rules, processes and uniform procedures only where absolutely needed.
There are places where we can now identify absolutely needed structure, that we had not evolved up to now (but should have!)
Why is this (near lack of) methodology
particularly relevant for
experiments?
Because this "seat of the pants" approach toward adopting a methodology is the most natural and likely path a large HEP experiment would take!
Project design recipes
Data dictionary tools
Design flow graphics aids
(semi-)Automated code generation
Code management CVS
Responsibility definition *
Phases of code review *
Phases of certification/integration --
General interface standards (explored CORBA/DSOM)
Requirements definition process *
Languages and variants C++ (gcc)
Coding dictums --
Uniform library/utility resources "libcrd"
gnu utilities
* "valuable lessons"
Observations:
* gcc is ahead of commercial C++ vendors and defines a sensible set of language features.
* CVS in its current implementation is quite adequate for code management. Developers should learn and utilize its capabilities. Shortcuts are not worth the risks.
* We have had little formal code review. This is bad if the reason is that you give all the complex/important coding to the "best" coders, so they have no time to "babysit" the others.
Things we have learned really are necessary:
* A good requirements "methodology" is the discipline to create and debate a "user's guide" before implementation design is far underway.
* Project methodology should include this dictum:
No code gets into the system which is not well-understood by more than one person, or which is known to have design flaws or bad kludges.
* Methodology includes troubleshooting tools.
* Methodolgy should include strategy for assigning/propogating "ownership" responsibility for modules. "Design" includes assignment of development and ownership responsibility.
They . . .
* Do not lead to "re-usable" modules (re-usable across large organizational distances) without a lot of extra work.
* Do lead to modules which are re-usable in the sense that as the project evolves, the module is not going to need a complete overhaul.
* Do not speed up the "normal" creative design-it, code-it, get-it-working process.
* Do help (a lot) when overall complexity of the project was underestimated at
the start --
because good methodologies allow the original design thought to
be brought forward in the actual project, without discarding and
re-designing.
* One folklore is that O-O designed projects might not get done quicker, but have a much sharper approach toward "error-free" state.
Have not seen this in any component of CAP (yet?)
We have dramatically seen this in CANOPER tape interface control system.