|
|
Created: 15 July 1997
Updated: 24 July 1997
BABAR Software Quality Control References
BaBar Reconstruction Design Checklist
BaBar Regression Testing Guidelines
BaBar Remedy Problem Reporting and Tracking
The Role of the Package Coordinator in BaBar
List of BaBar Package Coordinators
BaBar Package Test Request
BaBar Coding Standards
Guidelines for Writing or Modifying BABAR Software
C++ Coding Rules from Ellemtel (Swedish Telecom)
C++ Style Guide from Wildfire Communications
C++ Coding Standard by Todd Hoff
NASA Software Formal Inspections Page
AT&T C++ Code Inspections Guidelines
comp.software.testing Archives
BABAR Software Quality Control Objectives
Manifest Goals
- Compiles on all supported platforms
- Runs without core dumping on all platforms.
- Runs without crashing for any input, valid or invalid, on all supported platforms
- Runs without premature exit on all platforms (asserts no longer needed)
- Program size stabilizes. There are no memory leaks. We may need to plan regular restarts until we know the memory requirements are stable.
- Package does not corrupt the environment and jeopardize other modules.
Intrinsic Goals
- The program produces CORRECT results.
- How to verify this?
- How to verify the Monte Carlo? Can we use beam test data or detector data?
- Program flags inconsistent data but does not exit.
- Program produces the "best" results. Highest track finding efficiency, best resolution, etc.
- Program uses resources efficiently. Important for smaller collaboration member institutions. Small code size, optimized code tested, network access cached.
Documentation
- Documentation exists
- The code is clearly written and well commented.
- Documentation is accessible to the non expert. Primers exist for each subsystem.
- There is an "How to Manual". Cook book instructions, similar to "How to run Beta", Charlie Young's note are needed for all user accessible code.
Real Time Issues
- Reliability. Avoid or work around single component failures. Identify them ahead of time.
- SLAC network reliability both internal and external.
- Identify other critical components?
Costs of Re running
- Identify problems early. Easier to rerun reco code.
- Partial rerun should be possible so there is no need to run 80% of code to fix a 20% failure.
- Costs include financial, but also time and personnel issues.
- Expensive to rerun.
- Expensive to have unnecessary duplication. Tape backups, Data Centers.
- Expensive to have wide distribution of limited use software or data.
Third Party Product Problems
- How do we deal with quality issues for 3rd party products. We are dependent on Geant, vendor compilers, Objectivity etc.
- Identify limitations of third party products.
- If critical resolve the problem.
- If not critical document and work around.
Comments?
John.M.LoSecco.1@nd.edu
|
|