SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Comp. Search
Who's who?
Meetings
FAQ Homepage
Archive
Environment
Administration
New User Info.
Web Info/Tools
Monitoring
Training
Tools & Utils
Programming
C++ Standard
SRT, AFS, CVS
QA and QC
Remedy
Histogramming
Operations
PromptReco
Simulation Production
Online SW
Dataflow
Detector Control
Evt Processing
Run Control
Calibration
Databases
Offline
Workbook
Coding Standards
Simulation
Reconstruction
Prompt Reco.
BaBar Grid
Data Distribution
Beta & BetaTools
Kanga & Root
Analysis Tools
RooFit Toolkit
Data Management
Data Quality
Event display
Event Browser
Code releases
Databases
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

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