Software Development

show understanding of the design, coding and testing stages in the program development cycle
show understanding of how to write, translate, test and run a high-level language program
describe features found in a typical Integrated Development Environment (IDE):
- for coding, including context-sensitive prompts
- for initial error detection, including dynamic syntax checks
- for presentation, including prettyprint, expand and collapse code blocks
- for debugging, including: single stepping, breakpoints, variables/expressions report window

Objectives

Stage	What is it doing
Problem Solving	Define problem. Divide the problem into sub-problem (top-down, stepwise refinement)
Design	Define Data structure, variables. Algorithm design
Coding	Transfer the algorithm to programming language
Translation	Often syntax error can be found from here. (except interpreter language)
Testing and debug	Execute the program, test it according to the pre-defined goal (test plan, test data).

Note: The cycle mentioned in this chapter is concerning a programmer's job, which is often a part of a bigger project

IDE stands for Integrated Development Environment, it provides essential tools for a programmer to work with. e.g. IDLE in Python, REPL.it
Features:
- Text Editor:
  - Prettyprinting - color coded text
  - Context-sensitive prompts - like hint or help on the code you are typing
  - Dynamic syntax checks - some obivous syntax error is highlighted without compiling
  - Expanding and collapsing code blocks
- Debugger:
  - Step-by-step execution, breakpoints
  - Variable investigator - List all variables and their run-time value

show understanding of ways of exposing faults in programs and ways of avoiding faults
locate and identify the different types of errors:
- syntax errors
- logic errors
- run-time errors
correct identified errors
Show understanding of the methods of testing
available and select appropriate data for a given
method

Corrective maintenance
- Fixing the logic or run-time error found in a program
- Sometimes those error are very hard to be found
- e.g. a bug in the Windows security system may be hidden and only disclose by hackers after 10+ years, when Microsoft release the security patch that is a kind of "Corrective Maintenance"
Adaptive maintenance
- Amending a program to enhance functionality or in response to specification changes
Perfective maintenance
- Improve performance, maintainability or other attributes in the software

Use "dummy" module to simulate the behavior of a sub system
To help testing the higher level components, without the need to have sub system implemented
Commonly used in User Interface (UI) Test
- e.g. Recall what we have done in the Wordle Template:
  https://replit.com/@andytsuiacm/Wordle-template#main.py
- The read_words_list() function is created but no implementation there, only returning some expected data type. Such that the rest of the program can be run without breaking
https://www.tutorialspoint.com/software_testing_dictionary/stub.htm

Testing the code without knowing how the program works (e.g. no access to source code, or design documents)
Comparing expected results with actual results when a program is run
Imagine if you are going to buy a second hand smartphone:
- You will test if it is working properly
- You will have a list of items that you want to test, e.g.:
  - Can the camera take photo
  - Any "dead" pixel on the screen
  - Install some software etc.
- Your decision to buy or not (apart from cosmetic) depends on the test results, but;
- If it failed, you don't know what is the problem, you only know it didn't pass

Testing every path through the program code
For example, if your program has 5 condition branches, you need to design your test data to cover all 5 branches, in other word, make sure every line of code will be run
In contrast to black box, you understand how the program you are testing internally, since your test plan should address all possible paths, you are able to know if there's problem of the code, and possibly correct the problem

Usually white box works on modules, or sometimes we called unit-testing.
We can use dry-running, trace table, IDE debugger to test and correct bugs (all are white box)
Black box works on a larger system, where different modules are integrated together; or with modules / data from a third-party
All testing require a carefully designed test plan, addressing to the design specification, test data, includes:
- Extreme/Normal/Abnormal cases

Understanding, investigating the problem
Define clearly the problem
Create requirements specification
- Top-down approach: stepwise refinement, breakdown big problem into smaller components
- Bottom-up approach: Start with sub-problem and build up the system