Software Engineering
SDLC, process models, requirements, design, testing, project estimation, software quality.
Why this unit matters
Software Engineering is the unit that distinguishes ISRO CS from GATE CS. GATE CS covers some SE topics superficially, but ISRO CS has a dedicated section because ISRO develops large embedded and mission-critical software systems. Expect 8-10 marks from this unit, split roughly as: process models (2 marks), estimation (2-3 marks), testing (2-3 marks), and quality models (1-2 marks).
ISRO questions on SE are conceptual rather than deeply mathematical, but the estimation questions (COCOMO, function points, cyclomatic complexity) do require numerical computation.
Syllabus map
-
Software process models
- Waterfall: phases, advantages, when to use
- V-model: verification and validation pairing
- Prototyping model: throwaway vs evolutionary prototype
- Incremental and iterative models
- Spiral model: risk-driven, four quadrants
- Agile models: XP (extreme programming), Scrum
- Comparison: strengths, weaknesses, suitability
-
Requirements engineering
- Functional requirements: what the system must do
- Non-functional requirements: quality attributes (performance, reliability, security, maintainability)
- Software Requirements Specification (SRS): IEEE 830 standard
- Requirements elicitation, analysis, specification, validation
-
Software design
- Design principles: abstraction, modularity, encapsulation, information hiding
- Cohesion: functional, sequential, communicational, procedural, temporal, logical, coincidental (high to low)
- Coupling: data, stamp, control, external, common, content (low to high)
- Structured design: data flow diagrams (DFDs), structure charts
- Object-oriented design: UML diagrams (use case, class, sequence, activity)
- Design patterns: creational (Singleton, Factory), structural (Adapter, Decorator), behavioural (Observer, Strategy)
-
Software estimation
- LOC (lines of code): simple but language and style dependent
- Function point analysis: complexity weighting of inputs, outputs, inquiries, internal files, external interfaces; unadjusted FP, value adjustment factor
- COCOMO model: basic, intermediate, detailed
- COCOMO II
-
Software testing
- Testing levels: unit, integration, system, acceptance
- White-box testing: path testing, basis path testing, cyclomatic complexity
- Black-box testing: equivalence partitioning, boundary value analysis, cause-effect graphing
- Regression testing, smoke testing, performance testing
- Test-driven development (TDD)
-
Software quality
- Quality attributes: correctness, reliability, efficiency, maintainability, portability, usability
- McCall's quality model: product operation, product revision, product transition factors
- ISO 9126 / ISO 25010: quality characteristics
- Software reviews: inspections (Fagan), walkthroughs, peer reviews
- Software metrics: defect density, code coverage, MTTF, MTBF
-
Project management
- Work breakdown structure (WBS)
- Scheduling: PERT (probabilistic), CPM (deterministic), critical path
- Risk management: identification, analysis, planning, monitoring
- Configuration management: version control, baselines, change control
Software process models
Waterfall model
Sequential phases: requirements -> design -> implementation -> testing -> deployment -> maintenance. Each phase must be complete before the next starts.
Advantages: simple, well-understood, works for stable requirements. Disadvantages: inflexible, late feedback, unsuitable when requirements are unclear or likely to change.
ISRO trap: the waterfall model is NOT purely sequential in practice. Feedback loops exist (going back to fix issues found in later phases). Pure waterfall with no feedback is a theoretical model.
V-model
The V-model pairs each development phase with a testing phase:
- Requirements <-> Acceptance testing
- System design <-> System testing
- Architecture design <-> Integration testing
- Module design <-> Unit testing
- Coding (bottom of V)
Validation answers "are we building the right product?" (matches user needs). Verification answers "are we building the product right?" (meets specifications).
Spiral model
The spiral model is risk-driven. Each loop of the spiral has four phases:
- Objective determination and risk analysis.
- Alternative evaluation and risk resolution.
- Development and verification.
- Review and planning for the next loop.
Used for large, complex, high-risk projects. Not suitable when risks are low or requirements are stable.
Agile models
Scrum: iterative development in 2-4 week sprints. Key roles: Product Owner (manages backlog), Scrum Master (removes impediments), Development Team. Artifacts: product backlog, sprint backlog, increment. Events: sprint planning, daily standup, sprint review, retrospective.
XP (Extreme Programming): emphasises technical practices. Pair programming, test-driven development, continuous integration, refactoring, simple design, small releases.
Agile values (from the Agile Manifesto): individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
Software design
Cohesion and coupling
Cohesion measures how strongly the elements within a module are related. High cohesion is desirable.
Cohesion types (highest to lowest):
- Functional: all elements contribute to a single well-defined task (ideal).
- Sequential: output of one element is input to the next.
- Communicational: elements operate on the same data.
- Procedural: elements follow a specific order of execution.
- Temporal: elements execute at the same time (e.g., initialisation).
- Logical: elements perform logically similar tasks (e.g., all error handlers).
- Coincidental: no meaningful relationship (worst).
Coupling measures the degree of interdependence between modules. Low coupling is desirable.
Coupling types (lowest to highest):
- Data coupling: modules communicate through parameters (simple data).
- Stamp coupling: modules share a composite data structure.
- Control coupling: one module passes control information to another.
- External coupling: modules depend on external interfaces or formats.
- Common coupling: modules share global data.
- Content coupling: one module directly references internal workings of another (worst).
Software estimation
COCOMO
Basic COCOMO: E = a * (KLOC)^b (person-months), D = c * E^d (development time in months).
Project modes and their constants (Boehm's original COCOMO):
| Mode | a | b | c | d |
|---|---|---|---|---|
| Organic | 2.4 | 1.05 | 2.5 | 0.38 |
| Semi-detached | 3.0 | 1.12 | 2.5 | 0.35 |
| Embedded | 3.6 | 1.20 | 2.5 | 0.32 |
Organic: small team, familiar problem. Semi-detached: mixed experience. Embedded: tight constraints (real-time, embedded systems). ISRO projects are typically embedded.
Intermediate COCOMO: multiplies the basic estimate by a product of 15 cost driver attributes (Effort Adjustment Factor, EAF). Each attribute has a scale (very low to extra high).
Function point analysis
Count five information domains:
- External inputs (EI): data entering the system.
- External outputs (EO): data leaving the system.
- External inquiries (EQ): input/output combinations with no processing.
- Internal logical files (ILF): data maintained within the system.
- External interface files (EIF): data referenced but maintained externally.
Each count is weighted by complexity (simple, average, complex). Sum to get unadjusted function points (UFP). Multiply by value adjustment factor (VAF, between 0.65 and 1.35 based on 14 general system characteristics) to get adjusted FP.
Cyclomatic complexity
V(G) = E - N + 2P, where E = number of edges, N = number of nodes, P = number of connected components (usually 1 for a single function).
Alternatively: V(G) = number of decision nodes (IF, WHILE, FOR, CASE, etc.) + 1.
V(G) = number of independent paths through the program. Basis path testing requires one test case per independent path.
For well-structured code, V(G) <= 10 is recommended.
Software testing
White-box testing
Based on internal structure of the code. Requires knowledge of source code.
Path testing: devise test cases that execute every path in the control flow graph. Expensive for loops (infinite paths); basis path testing (McCabe) chooses a basis set of V(G) linearly independent paths.
Statement coverage: every statement executed at least once. Branch coverage: every branch (true and false) taken at least once. Path coverage: every path executed (often infeasible).
Coverage hierarchy: path > branch > statement (path coverage implies branch coverage which implies statement coverage).
Black-box testing
Based on external specification, not internal code.
Equivalence partitioning: divide input domain into equivalence classes (valid and invalid). Test one representative from each class.
Boundary value analysis: test values at boundaries (minimum, minimum+1, nominal, maximum-1, maximum). Errors cluster at boundaries.
Cause-effect graphing: represents logical relationships between inputs (causes) and outputs (effects). Derives a decision table and then test cases.
Software quality
McCall's quality model
Three perspectives:
- Product operation: correctness, reliability, efficiency, integrity, usability.
- Product revision: maintainability, testability, flexibility.
- Product transition: portability, reusability, interoperability.
ISO 9126 quality characteristics
Functionality, reliability, usability, efficiency, maintainability, portability. Each has sub-characteristics. (Updated in ISO 25010 with quality in use characteristics added.)
Software reviews
Fagan inspection: formal review process with defined roles (moderator, author, reader, reviewer, recorder). Multiple meetings (overview, preparation, inspection meeting, rework, follow-up). Most effective at finding defects early.
Walkthrough: author leads a group through the artifact. Less formal than inspection. Goal is education and defect finding.
Peer review: informal review by colleagues.
Project management
PERT and CPM
PERT: activity duration estimated as a probability distribution. Expected time = (O + 4M + P) / 6, where O = optimistic, M = most likely, P = pessimistic. Variance = ((P - O) / 6)^2. Used for uncertain, research-type projects.
CPM: activity duration is deterministic. Used for projects with known durations (construction, manufacturing). Identifies the critical path (longest path from start to finish). Critical path determines project duration. Activities on the critical path have zero float (slack).
Float (slack) for an activity = Late Start - Early Start = Late Finish - Early Finish.
Network diagrams: Activity on Node (AON) is more common. Activity on Arrow (AOA) requires dummy activities.
ISRO trap: PERT and CPM both produce a critical path. The difference is that PERT accounts for uncertainty in task duration, while CPM treats durations as fixed. ISRO sometimes describes a scenario and asks which model is appropriate.
Worked examples
Example 1: COCOMO estimation
Project: 40 KLOC, organic mode.
E = 2.4 * (40)^1.05 = 2.4 * 40^1.05.
40^1.05: log(40^1.05) = 1.05 * log(40) = 1.05 * 1.602 = 1.682. 10^1.682 = 48.1.
E = 2.4 * 48.1 = 115.4 person-months.
D = 2.5 * (115.4)^0.38.
115.4^0.38: log(115.4^0.38) = 0.38 * log(115.4) = 0.38 * 2.062 = 0.784. 10^0.784 = 6.08.
D = 2.5 * 6.08 = 15.2 months.
Average team size = E / D = 115.4 / 15.2 approx 7.6, so about 8 people.
Example 2: Cyclomatic complexity
Function with the following structure: one IF, one WHILE loop containing one IF, and a SWITCH with three cases.
Decision points: outer IF (1), WHILE condition (1), inner IF (1), SWITCH with 3 cases (3 binary decisions or 2 additional edges from the 3 cases, depending on counting method). For SWITCH with 3 cases: counts as 2 decision points (or treat each case as a separate branch).
Using V(G) = decisions + 1: 1 + 1 + 1 + 2 = 5. V(G) = 6.
(Exact counting depends on the control flow graph drawn. The principle is: each decision point adds one to the count.)
Example 3: Equivalence partitioning
Function: accepts an integer from 1 to 100. Classify and pick test values.
Valid partition: 1 to 100. Test value: 50. Invalid partition 1: less than 1 (e.g., 0 or negative). Test value: 0. Invalid partition 2: greater than 100. Test value: 101.
Boundary values: 1, 2 (min and min+1), 99, 100 (max-1 and max), plus 0 and 101 (just outside boundaries).
Example 4: Critical path analysis
Activities and dependencies:
A (3 days), B (4 days, depends on A), C (2 days, depends on A), D (5 days, depends on B), E (3 days, depends on C and B), F (2 days, depends on D and E).
Paths: A -> B -> D -> F: 3+4+5+2 = 14 days. A -> B -> E -> F: 3+4+3+2 = 12 days. A -> C -> E -> F: 3+2+3+2 = 10 days.
Critical path: A -> B -> D -> F, duration 14 days.
Float for activity C: Late Start of C = Late Start of E - duration of C. Since E can start as late as: Late Finish of F (14) - duration F (2) - duration E (3) = 9. For C to not delay E: C must finish by 9. C earliest finish = Early Start of C + duration of C = 3 + 2 = 5. Float of C = 9 - 3 - 2 = 4 days (or Late Start(C) - Early Start(C) = 7 - 3 = 4).
Example 5: Function point count
System inputs: 3 external inputs (avg complexity), 2 external outputs (complex), 1 external inquiry (simple), 2 internal logical files (avg), 1 external interface file (simple).
Weights (unadjusted FP contribution): EI: 3 * 4 = 12 (avg weight = 4). EO: 2 * 7 = 14 (complex weight = 7). EQ: 1 * 3 = 3 (simple weight = 3). ILF: 2 * 10 = 20 (avg weight = 10). EIF: 1 * 5 = 5 (simple weight = 5).
UFP = 12 + 14 + 3 + 20 + 5 = 54.
If VAF = 1.0 (neutral), adjusted FP = 54.
Quick-revision summary
- Waterfall: sequential, good for stable requirements. V-model pairs dev phases with test phases.
- Spiral: risk-driven, iterative. Best for large, uncertain projects.
- Scrum: sprints (2-4 weeks), Product Owner, Scrum Master, dev team. Daily standup.
- Cohesion (high is good): functional > sequential > communicational > procedural > temporal > logical > coincidental.
- Coupling (low is good): data < stamp < control < external < common < content.
- COCOMO: E = a * (KLOC)^b. Modes: organic, semi-detached, embedded.
- Cyclomatic complexity V(G) = E - N + 2 = decisions + 1. Recommended <= 10.
- White-box: path, statement, branch coverage. Black-box: equivalence partitioning, boundary value analysis.
- PERT: probabilistic, uses (O + 4M + P)/6. CPM: deterministic, identifies critical path.
- Critical path: longest path from start to finish. Activities on it have zero float.
How to study this unit
- Learn the process models as a comparison table: waterfall, V-model, prototyping, spiral, incremental, Scrum, XP. For each: phases, when to use, key strength, key weakness.
- Practise COCOMO calculations for all three modes using a given KLOC. Know the constants and understand that ISRO (embedded) uses the embedded mode constants.
- Draw control flow graphs for 3-4 small code snippets and compute V(G) using both the formula (E-N+2) and the shortcut (decisions+1). Verify they match.
- Work through 2-3 PERT/CPM network problems: compute early start/finish, late start/finish, float, and identify the critical path. These require systematic table computation.
- Understand function point counting at the level of knowing the five information domain categories and their typical complexity weights. ISRO gives the weights in the question if needed.
- Know the quality models (McCall, ISO 9126) by their categories, not by memorised lists. ISRO asks "which quality factor corresponds to the ease of moving software to a new environment?" (portability).
Prefer watching over reading?
Subscribe for free.