|
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:
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?
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?
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?
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.
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?
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?
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?
Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?
Are loop indexes range tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided?
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?
Have functions been optimized for speed? Have repeatedly used blocks of code been formed into sub-routines? Checked for any memory leak, overflow?
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?