Software Engineering and Programming
Software Engineering and Programming tests disciplined construction: requirements, design, testing, version control, and maintainable code. Expect questions on lifecycle models, test levels, coupling/cohesion, and defect economics.
Core rules
- Waterfall suits stable, regulated requirements; iterative/Agile suits evolving requirements with short feedback loops.
- Cohesion should be high within a module; coupling should be low between modules.
- Test levels: unit, integration, system, acceptance. Verification asks whether we are building it right; validation asks whether we are building the right thing.
- Black-box techniques include equivalence partitioning and boundary-value analysis; white-box uses statement, branch, and path coverage.
- Cyclomatic complexity M = E − N + 2 for a connected control-flow graph, or decisions + 1.
- Continuous integration runs build and tests on every change; version-control branches isolate work but require merge discipline.
Worked example
A function has a control-flow graph with 9 edges and 8 nodes. M = 9 − 8 + 2 = 3. That means three linearly independent paths; branch coverage needs at least two tests for a simple if/else, but path coverage may need three. If the code has one if without else and one loop, counting decisions + 1 gives the same structural measure but not the same test count as full path coverage.
Boundary example: an input valid for 1–100. Equivalence classes are <1, 1–100, >100. Boundary tests are 0, 1, 2, 99, 100, 101-testing only 50 misses the defects that cluster at edges.
Traps
- Equating statement coverage with branch coverage.
- Treating Agile as no documentation or no design.
- Confusing verification and validation.
- Counting comments as maintainability without measuring complexity.