Determine what the system needs to do for the organization (requirements gathering). Often this means asking questions such as... • What do we need this system for? • What will the system do for the organization? • How are we going to make this system? • Who is doing what, when, and how?
Analyze any existing system to see what it is doing for the organization and how well that system is doing its job. The feasibility of the project is also considered, and the group has to ask questions such as... • Can this system be created with the resources (and budget) we have available? • Will this system significantly improve the organization? • Does the old system even need to be replaced? Analyzes end-user information needs. Software, hardware
Involves the actual creation and design of a system. It will include screen layouts, process diagrams, pseudocode, flow chart and other documentation.
To ensure the reliability Changes and enhancements process
The process of going from source code files to an executable referred as build process. There are 4 steps involve in building your program: • Editing • Compiling • Linking • Running
TOOL STEP PRODUCTEditor Edit Source code files (.cpp)Compiler Compile Object program (.obj)Linker Link Executable object (.exe) Run Result/Output
Start Edit Your Source Source Program Compile or Assemble Your Source Yes Errors? Object Program No Link Libraries and Other Object Programs Executable Execute Object No Results OK? Yes Donewww.calpoly.edu
Compilation • the compiler translate C++ instruction in the source code file into machine language instructions. • this process will produce an object file but doesnt create anything the user can actually run. • eg: if you compile (but dont link) three separate files, you will have three object files created as output, each with the name <filename>.obj. each of these files contains a translation of your source code file into a machine language file -- but you cant run them yet! you need to turn them into executables your operating system can use and thats when the linker comes in.
The creation of a single executable file from multiple object files. A linker is typically used to generate an executable or library by combining parts of object files.
Compile time error Run time error Logical error
Syntax errors • Errors that prevent your program from running. • Also called design-time error. • Caused by mistakes that you make when typing code such as incorrect grammar, vocabulary, or spelling. • These are usually easy to find and correct. • Common compile errors: missing semicolon extra parenthesis keyword typo error
Errors that occur while your program runs. Occur when your program attempts an operation that is impossible to carry out. Errors not caught at entry but which involve an incorrect statement or bad data. The code appear has no syntax errors, but it will not execute. More difficult to correct than syntax errors You can fix most run-time errors by rewriting the faulty code, and then recompiling and rerunning it. common run time errors including: undefined functions (commonly, main itself). during compilation, if the compiler could not find the definition for a particular function, it would just assume that the function was defined in another file. if this isnt the case, theres no way the compiler would know since it doesnt look at the contents of more than one file at a time. linker, on the other hand, may look at multiple files and try to find references for the functions that werent mentioned. dividing by zero and out of memory.
Errors that prevent your program from doing what you intended it to do. Your code may compile and run without error, but produce a result that you did not expect. For example: • char name • int month = 11 These are the hardest to find because it is not always clear where they originate.
During the stages of compilation, linking, and running, error messages may occur that require the programmer to make corrections to the program source (debugging). Debugging is a black art. Some things to go over, though, so they’ll be concrete in our brains: • relation to testing • why debugging is hard • process • techniques • avoiding bugs
Testing and debugging go together like peas in a pod: Testing finds errors; debugging repairs them. Together these form the “testing/debugging cycle”: we test, then debug, then repeat.
There may be no obvious relationship between the external manifestation(s) of an error and its internal cause(s). Symptom and cause may be in remote parts of the program. Changes (new features, bug fixes) in program may mask (or modify) bugs. Symptom may be due to human mistake or misunderstanding that is difficult to trace. Bug may be triggered by rare or difficult to reproduce input sequence, program timing (threads) or other external causes. Bug may depend on other software/system state, things others did to your systems weeks/months ago.
Execution tracing • running the program • print • trace utilities Interface checking • check procedure parameter number/type (if not enforced by compiler) and value • defensive programming: check inputs/results from other modules Skipping code: comment out suspect code, then check if error remains.
Coding style: use clear, consistent style and useful naming standards. Document everything, from architecture and interface specification documents to comments on code lines. Hold code reviews. Program defensively. Use/implement exception handling liberally; think constantly about anomalous conditions. Be suspicious of cut/paste. Consider using an integrated development environment (IDE) with dynamic syntax checking.