Software Quality Assurance - the context

Some comments on Quality Assurance in a Physics Context

Get the full text of this note [pdf, 3 pages]

Standard Quality Assurance methods are designed for INDUSTRIAL use, and as such may appear to be too rigid for many physicists. Our aim is to use those ideas and methods which have been successfully used in industry, and which can be applied to a large physics collaboration, avoiding methods which will squander essential resources of independence, versatility and commitment.

Our vision is that, although some of the QA suggestions will be onerous, and seem to be of limited value in the short term (which is the main concern of people developing private or prototype code), that clear cut procedures, based on the a number of well defined steps, and monitored by a reviews will have important long term benefits Furthermore, the use of various software tools should be made available to support such procedures.

Differences between Industrial and Physics software development
	Industry	Physics
Size of a team : Larger teams cannot rely on informal communication.	At least 5	typically between 1 and 3
Who are the USERS? : In industry it is essential to ensure that the developers have understood the requirements of the users. In contrast, physicists often know their subject matter well, and do not see the need to formally describe requirements	The users are paying clients	Developers are also users.
Motivation of the developers : Developers in industry NEED a formal structure to understand what is expected of them, and when it must be ready.	Developers are part of a large formal structure, and are less personally engaged in the success of the software.	Developers are highly motivated by the results of the software.
Testing Procedures : Formal and complete tests can only be designed if formal requirements have been defined.	Formal testing procedures are defined to ensure that the clients requirements have been met. The client NEEDS to see the results of these tests.	Physicists use intuition and checks of program output, which are known as "Physics Validation"
Management : Where there is no hierarchical management, no one can formally check that goals have been achieved.	Managers need to determine that members of the team are performing adequately	Physicists take individual responsibility for their work, and may not see the overall success of the collaboration as their primary goal.

Procedures for use by large physics collaboration for s/w quality assurance

It is clear that it is neither possible nor desirable to convert our current social structure from the one where we work either as individuals or in very small teams where each the individual has sole responsibility for all aspects of software development to one where we work in a large, rigidly organized teams slavishly following some How-To book of rules.

Peer Reviews	Real benefit can be obtained from peer review, if the reviews are held in a constructive spirit, and are implemented in a lightweight manner (see reviews) The very fact that material is to be reviewed often means that more care is taken immediately, rather than put off to some indefinite time in the future
Documentation improves maintainability	Our software will be used by many people and over a long period of time. We cannot rely on the memory of individual physicists. Working methods which improve maintainability are essential. The nature of OO code is such that comprehensibility improves enormously with a moderate amount of documentation (UML sequence and class diagrams in particular).
Testing procedures	Our software is complex, and developed by a large geographically scattered team. Each part of it needs some testing mechanism which can check that no ill effects have been introduced by a change in another part of the software. These tests need to be performed automatically.