Software Quality

Here are some of the things I look for when I am grading your programs. This list is unordered and may grow; if it does I will let you know.

Here is a list of quality factors:¹

Correctness

The extent to which a program satisfies its specifications and fulfills the customer's objectives.

Reliability

The extent to which a program can be expected to perform its intended functions.

Efficiency

The amount of resources used to complete a function. Order n-squared sorts and linear searches are satisfactory (see the catalog page 48), but Computer Science majors should know and do better.

Integrity

The extent to which unauthorized access can be controlled.

Usability

The effort required to learn operated, prepare input and interpret out of a program.

Maintainability

The effort needed to locate and repair errors.

Modifiability

The effort required to modify aprogram. Changes in specifications should have impact the executable part of the program as little as possible.

Testability

The effort required to empirically evaluate that the program performs its intended function.

Portability

Write in standard language which as few in-house kludges as possible. Local adaptations should be annotated and activated by compiler switches.

Please have at the front of your code an index or table of contents to the program. This only needs to be a simple list of the declaration order.

A complete synopsis: this should have at least two components, the general attack on the problem, and then the specific method used in the program. Objects and other data structures should be described here, with a rationale for the choice.

Relationship to conceptual solution: use of MEANINGFUL constants and objects, variables, enumeration types, etc. Generally, this means that the only numeric constants that will appear in your programs are 0 and 1. However, the following sort of literal interpretation of this provision will be shot:

#define SIXTY_FOUR 64

The point is that the use of such a value must have indicated by some constraint in the solution, and that the symbolic name of the value should reflect that constraint; i.e.

#define MEMORY_SIZE 64

And now memory size can be easily modified.

I may require executions with data sets that I construct. If your program fails with my data, you may create your own data sets to demonstrate the working parts of your program, but executions with my data sets are always required, when assigned. You may not copy the data sets to your own account; final execution will need to give evidence that the data sets from my accounts were used.
Keep related items together in a structure or object.

Readability of program and output.

Procedure stubs for unfinished sections of code are a good idea.

Goto's are not allowed, except by EXPLICIT permission of the instructor.

Side effects, i.e. local assignment to global variables, are NEVER permitted.

No global references are permitted, except to constants and types; a procedure should only access its parameters and locals as variables.

Variable scope should be limited as much as possible.

Header files may not contain executable code, no, not even inlines!

No friend methods, ever. [15 March 2001]

rev March 16, 2001file ~kbg/Teaching/guidelines.{tex$\mid$dvi$\mid$ps}