Saturn Technopark » Saturn quality aspects

Advantages

Saturn quality aspects

Saturn takes every care to ensure that the software we build satisfies your requirements. The only way to ensure this is to perform quality assurance throughout the software lifecycle. We typically involve a lead quality engineer in the early phases of a project to participate in requirements elicitation and analysis, to ensure that our quality assurance team understands the business objectives and the detailed requirements. This understanding enables the team to develop a comprehensive quality assurance plan for the project that includes the following aspects:

Understandable

Are variable names descriptive of the physical or functional property represented? Do uniquely recognisable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?

Complete

Does the program contain all referenced subprograms not available in the usual systems library? Are all parameters required by the program available? Are all inputs required by the program available?

Concise

Is all code reachable? Is any code redundant? How many statements within loops could be placed outside the loop, thus reducing computation time? Are branch decisions too complex?

Portable

Does the program depend upon system or library routines unique to a particular installation? Have machine-dependent statements been flagged and commented? Has dependency on internal bit representation of alphanumeric or special characters been avoided? The measurement of effort required to transfer the program from one hardware/software system environment to another.

Consistent

Is one variable name used to represent different physical entities in the program? Does the program contain only one representation for physical or mathematical constants? Are functionally similar arithmetic expressions similarly constructed? Is a consistent scheme for indentation used?

Maintainable

Has some memory capacity been reserved for future expansion? Is the design cohesive, i.e., each module has recognisable functionality? Does the software allow for a change in data structures (object-oriented designs are more likely to allow for this)? If a functionally-based design (rather than object-oriented), is a change likely to require restructuring the main-program, or just a module?

Testable

Are complex structures employed in the code? Does the detailed design contain clear pseudo-code? Is the pseudo-code at a higher level of abstraction than the code? If tasking is used in concurrent designs, are schemes available for providing adequate test cases?

Usable

Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?

Reliable

Are loop indexes range tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided?

Structured

Is a block-structured programming language used? Are modules limited in size? Have the rules for transfer of control between modules been established and followed?

Efficient

Have functions been optimized for speed? Have repeatedly used blocks of code been formed into sub-routines? Checked for any memory leak, overflow?

Secure

Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are appropriate security mechanisms in place? Are those security mechanisms implemented correctly? Can the software withstand attacks that must be expected in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms? Does the architecture limit the impact of yet unknown errors?