6.8 Calculation Errors

 < Day Day Up > 



An infinite number of conditions can cause calculation errors. The programmer logic may have been in error or his or her formula for the calculation may be coded incorrectly. Rounding or truncation errors can significantly alter desired results. A good design process should incorporate pseudocode for any and all calculated results to show how these formulas are intended to be implemented or used in production. Code reviews would check to see that they are indeed implemented as designed. Test cases would execute all boundary conditions against the code and verify the implementation is as rock solid as it can be before turning it over to production for general use.

6.8.1 Initial- and Later-State Errors

When a program executes subroutines and uses variables, these variables must be initialized with a default value. If this is not done specifically by the developer, it is anyone’s guess as to what the value of that variable will be when first called. Remember, all of these types of errors are a result of programmers not doing the job correctly. For instance, let’s assume that in the previous example there has been no variable initialization when a routine calls for a variable to increment. The program processes 50 records, incrementing the value of the variable each time the routine is executed. When the value is output at the end of processing, it should be equal to 50; however, the uninitialized variable had a value of 122 (or some other random number) and the output shown to the user is 172. This describes what constitutes an initial-state error.

To demonstrate later-state errors, consider the same situation, but instead of passing the expected value of 50 to another module to use for processing, the value of 172 is passed along. These errors are a bit harder to detect because the output from the called module is where the user thinks the error occurred. Programmers assigned to debug this problem have to trace through the execution path and follow the changing state of the variable until it is discovered to be a problem in the calling module, not the called one. The result of this is that a great deal of time and effort go into discovering a problem that was avoidable. If the user reports this from a production system, project team credibility would once again take a hit. As a program manager, you must ensure that these types of situations are prevented by facilitating adequate, in-depth discussion in the design phase.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net