My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
CRDSS_Task1_05-3_DebuggingGuildelinesForCRDSS
CWCB
>
Decision Support Systems
>
DayForward
>
CRDSS_Task1_05-3_DebuggingGuildelinesForCRDSS
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
9/25/2011 10:18:52 AM
Creation date
5/30/2008 2:11:51 PM
Metadata
Fields
Template:
Decision Support Systems
Title
CRDSS Task 1.05-3 - Study of System Integration Issues Debugging - Guidelines for CRDSS
Description
A discussion of debuging CRDSS software.
Decision Support - Doc Type
Task Memorandum
Date
5/10/1994
DSS Category
DMI Utilities
DSS
Colorado River
Basin
Colorado Mainstem
Contract/PO #
C153658, C153727, C153752
Grant Type
Non-Reimbursable
Bill Number
SB92-87, HB93-1273, SB94-029, HB95-1155, SB96-153, HB97-008
Prepared By
Riverside Technology inc.
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
4
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
CRDSS <br />TASK MEMORANDUM 1.05-3 <br />Study of System Integration Issues <br />Debugging - Guidelines for CRDSS <br />1.0 ISSUE <br />CRDSS libraries will contain modular code and can be linked to various CRDSS applications. The <br />code in libraries must be thoroughly tested so that developers who depend on the code (but who do <br />not have responsibility for maintaining the code) can assume that the library routines are functioning <br />properly. <br />Complete applications must also be fully tested. However, in such situations, the testing must <br />depend on users for feedback. Although developers will be able to detect and fix some bugs, users <br />invariably are able to find bugs that developers do not see. Additionally, limitations indicated by <br />users may not have been considered a limitation by the developer. <br />The following issues must be addressed in order to debug software: <br />How will source code be debugged from a developer's point of view? <br />? <br />How will programs be debugged from a user's point of view? <br />? <br />How will the overall system be debugged? <br />? <br />How will code improvements be documented? <br />? <br />2.0 DISCUSSION/ANALYSIS <br />A "bug" is a flaw in software that causes unexpected results. Bugs can be severe enough to cause <br />program crashes, or minor enough that the bug is barely noticeable. The latter type is generally more <br />difficult to fix because it takes longer to detect the bug. Bugs can consist of logical errors or <br />implementation errors. Logical errors are errors in an algorithm or method. Implementation errors <br />involve an inappropriate programming implementation for a given procedure (e.g., wrong syntax, <br />wrong sequence of commands). Bugs typically do not manifest themselves at the point of the <br />problem. More often, the results of a bug are detected later in the program execution and must be <br />traced back to the point of error. Bugs are usually detected because data (or results) do not match the <br />results achieved by hand (or visualized by the user). <br />It is inevitable that bugs will be present in code because different authors work on the same program <br />and because "things slip through the cracks." This often occurs because a later author for a routine <br />does not understand what an earlier author has done. Additionally, in complex systems, a change in <br />one part of the system may adversely affect a different part of the system. In order to minimize bugs <br />in the CRDSS software, it is important to follow the guidelines outlined below: <br />1 <br />A275 05.10.94 1.05-3 Malers <br />
The URL can be used to link to this page
Your browser does not support the video tag.