Software Engineering

Why this unit matters

Software Engineering carries consistent weight in UGC NET CS. Questions here are largely conceptual, definitions, comparisons, and formula-based calculations, which means a well-prepared student can score full marks without memorising code. The unit rewards clear mental models: if you understand why COCOMO exists, its formula becomes easy to recall; if you understand why coupling should be low, every design question becomes straightforward.

Syllabus map

Area	Key topics
Process Models	Generic model, prescriptive, agile (XP, Scrum, DSDM, FDD, Crystal, ASD), component-based, aspect-oriented, formal methods, web engineering
Requirements	Functional vs non-functional, elicitation, use cases, SRS, analysis and modelling, reviews
Design	Abstraction, architecture, patterns, modularity, information hiding, cohesion, coupling, OO design, UI design, component design
Quality	McCall's factors, ISO 9126, QA vs QC, RMMM, reliability
Estimation	LOC, function points, cost/effort models, COCOMO I and II, scheduling, Gantt / PERT
Testing	V&V, unit/integration/system, white-box, black-box, basis path, alpha/beta, regression, stress, performance
SCM	Change control, version control, reuse, re-engineering, reverse engineering

Process models

Generic process model

Every software process has five framework activities: Communication, Planning, Modelling, Construction, and Deployment. These appear regardless of which specific process model you use.

Prescriptive models

Waterfall, strictly sequential; each phase finishes before the next starts. Suitable when requirements are stable and well-understood. Weakness: change is expensive late in the cycle.

Incremental, delivers a partial product in increments; each increment adds functionality. Risks are spread; early increments can validate requirements.

Evolutionary, requirements change; two variants: Prototyping (throw away exploratory prototype once requirements stabilise) and Spiral (risk-driven, four quadrants: planning, risk analysis, engineering, evaluation).

RAD, 60, 90 day cycles. Works when requirements are well-known and the project can be modularised for parallel development teams.

Agile methods

Agile values working software over comprehensive documentation and customer collaboration over contract negotiation.

Method	Signature idea
XP (Extreme Programming)	Pair programming, TDD, continuous integration, small releases
Scrum	Sprint (2, 4 weeks), Product Backlog, Daily Scrum, Sprint Review
DSDM	MoSCoW prioritisation (Must / Should / Could / Won't)
FDD (Feature-Driven Dev)	Develop by feature; feature = client-valued function in < 2 weeks
Crystal	Family of methods; colour-coded by team size and criticality
ASD	Three phases: Speculation, Collaboration, Learning

Aspect-oriented and formal methods

Component-based development (CBD) reuses existing components. The process: component qualification, adaptation, composition, update.

Aspect-oriented separates cross-cutting concerns (logging, security) from business logic using aspects.

Formal methods use mathematical notation (Z, VDM, B) to specify and verify software. High cost, highest reliability; used in safety-critical systems.

Requirements engineering

Functional vs non-functional requirements

Functional requirements describe what the system does ("The system shall allow a user to search by ISBN"). Non-functional requirements describe how well it does it: performance, security, reliability, portability, maintainability.

Elicitation techniques

Interviews, questionnaires, observation (ethnography), prototyping, brainstorming, JAD (Joint Application Development) sessions.

Use cases

A use case captures an interaction between an actor and the system to achieve a goal. Elements: actor, use case name, precondition, main flow, alternate flows, postcondition.

Relationships between use cases: include (one use case always invokes another, mandatory), extend (one use case optionally extends another, conditional), generalisation (a child use case inherits and optionally overrides a parent).

Use case diagrams in UML show actors, use cases, and their relationships at a glance. They are a communication tool between developers and stakeholders, not a design artifact.

SRS document

IEEE 830 standard. Must be: complete, consistent, correct, unambiguous, modifiable, traceable, ranked for importance/stability.

Design

Core principles

Abstraction, represent at a high level, hide detail. Two kinds: procedural (sequence of instructions) and data (collection + operations).

Modularity, partition software into individually named, addressable components. Module size should balance integration overhead against comprehension cost.

Information hiding, each module hides a design decision from others (Parnas). Changes to a hidden decision affect only that module.

Separation of concerns, handle one concern per module. Related to information hiding but broader.

Cohesion and coupling

Cohesion (within a module), from weakest to strongest: Coincidental, Logical, Temporal, Procedural, Communicational, Sequential, Functional. Functional cohesion is the goal.

Coupling (between modules), from strongest (worst) to weakest (best): Content, Common, External, Control, Stamp, Data. Data coupling is the goal: modules communicate only through parameters.

A quick mnemonic for cohesion: "Can Larry Trump Persuade Computer Scientists Freely?", Coincidental, Logical, Temporal, Procedural, Communicational, Sequential, Functional.

Architectural patterns

Layered, each layer provides services to the layer above. Example: OSI model. Repository, all subsystems share a central data store. Client-server, clear service provider / requester separation. Pipe-and-filter, data flows through a sequence of transformations (Unix pipes). MVC, Model (data), View (presentation), Controller (logic). Reduces coupling between UI and business logic.

OO design

Key concepts: encapsulation, inheritance, polymorphism, dynamic binding. Design should maximise cohesion within classes and minimise coupling across classes.

Quality

McCall's quality factors (1977)

Three views: Product operation (correctness, reliability, efficiency, integrity, usability), Product revision (maintainability, flexibility, testability), Product transition (portability, reusability, interoperability).

ISO 9126 (now ISO 25010)

Six characteristics: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability. Each has sub-characteristics.

QA vs QC

Quality Assurance (QA), process-oriented; ensures the development process is followed correctly; preventive. Quality Control (QC), product-oriented; examines the product to find defects; corrective.

Risk management (RMMM)

RMMM = Risk Mitigation, Monitoring, Management.

Risk = Probability x Impact. Steps: identify risks, analyse (likelihood and impact), plan mitigation, monitor.

Software reliability

Reliability = probability the software runs without failure for a specified time under specified conditions. MTTF (Mean Time to Failure), MTTR (Mean Time to Repair), MTBF = MTTF + MTTR, Availability = MTTF / MTBF.

Estimation and scheduling

LOC and Function Points

LOC (Lines of Code), simple but language-dependent and hard to estimate before code is written.

Function Point (FP), language-independent. Count five information domain values: external inputs (EI), external outputs (EO), external inquiries (EQ), internal logical files (ILF), external interface files (EIF). Each weighted by complexity (simple/average/complex). Then apply a Value Adjustment Factor (VAF).

FP = UFP x [0.65 + 0.01 x sum of complexity adjustment values]

where UFP = unadjusted function points.

COCOMO

COCOMO I (Boehm, 1981) has three modes:

Mode	Effort (PM)	Duration (months)
Organic	2.4 x KLOC^1.05	2.5 x PM^0.38
Semi-detached	3.0 x KLOC^1.12	2.5 x PM^0.35
Embedded	3.6 x KLOC^1.20	2.5 x PM^0.32

Organic: small teams, familiar problem. Embedded: stringent hardware/software constraints.

COCOMO II uses function points and includes three sub-models: Application Composition, Early Design, Post-Architecture.

Project scheduling

Gantt chart, bar chart showing tasks against time. Good for tracking but does not show dependencies well. PERT / CPM, network diagram with task dependencies. Critical path = longest path; any delay on it delays the project. Slack / float on non-critical paths can absorb delays.

Testing

V&V

Verification, are we building the product right? (Reviews, inspections, walkthroughs, done against the specification.) Validation, are we building the right product? (Testing against user needs.)

Error / fault / failure terminology

Error, human mistake (typo, wrong logic in mind). Fault (defect, bug), consequence of an error in the artifact (wrong statement in code). Failure, observable incorrect behaviour when the fault is executed.

White-box testing

Tests internal structure. Techniques:

Basis path testing, draw the control flow graph (CFG); compute cyclomatic complexity V(G) = E, N + 2P (E = edges, N = nodes, P = connected components; usually P=1 so V(G) = E, N + 2). V(G) gives the number of independent paths = number of test cases needed for full statement/branch coverage.

Condition testing, ensures each Boolean sub-expression is evaluated to both true and false. Loop testing, exercises loops at: 0 iterations, 1 iteration, typical, max-1, max, max+1.

Black-box testing

Tests external behaviour without knowledge of internals.

Equivalence partitioning, divide input domain into classes that should behave identically; test one value from each class. Boundary value analysis, test at and just beyond boundaries of equivalence classes.

Integration strategies

Big bang, integrate all at once; hard to isolate faults. Top-down, integrate top-level modules first, use stubs for lower levels. Bottom-up, integrate lower levels first, use drivers for upper levels. Sandwich / hybrid, mix of top-down and bottom-up.

Other test types

Alpha testing, conducted by users at the developer's site. Beta testing, conducted by users at their own sites. Regression testing, re-run a subset of tests after a change to detect unintended side effects. Stress testing, test beyond normal operational capacity to find the breaking point. Performance testing, validate response times and throughput under defined loads.

SCM (Software Configuration Management)

Configuration item (CI), any product that is placed under configuration control: source code, test data, documentation.

Baseline, a CI (or set of CIs) formally reviewed and agreed upon; serves as the basis for further development and can only be changed through formal change control.

Change control, formal process: change request -> impact analysis -> change control board (CCB) approval -> implementation -> audit. A CCB typically includes representatives from development, testing, project management, and the customer.

Audit, two kinds: functional configuration audit (verifies that the product performs as specified) and physical configuration audit (verifies that the product matches the approved design documentation).

Version control, track and manage changes to software artifacts. Key concept: delta storage (store differences between versions). Tools: Git, SVN, ClearCase.

Software reuse, use existing components rather than building from scratch. Types: black-box (use as-is), white-box (modify source), glass-box (understand internals without modifying).

Re-engineering, examine and alter an existing system to reconstitute it in a new form. Includes restructuring, translation, reverse engineering followed by forward engineering.

Reverse engineering, analyse a system to create representations at a higher abstraction level; extracts design from code (not modifying the system).

Worked examples

Example 1: Computing cyclomatic complexity

A function has the CFG: 6 nodes, 7 edges, 1 connected component.

V(G) = E, N + 2P = 7, 6 + 2(1) = 3

So you need 3 independent test cases to achieve basis path coverage.

Example 2: Function point calculation

Suppose a system has: 4 EI (average), 3 EO (complex), 2 EQ (simple), 2 ILF (average), 1 EIF (simple). Using standard weights:

EI avg = 4, EO complex = 7, EQ simple = 3, ILF avg = 10, EIF simple = 5

UFP = (4×4) + (3×7) + (2×3) + (2×10) + (1×5) = 16 + 21 + 6 + 20 + 5 = 68

If VAF = 1.0 (neutral), FP = 68.

Example 3: COCOMO effort estimate

A 50 KLOC organic project: Effort = 2.4 x 50^1.05.

50^1.05 ≈ 55.7 (because ln(50) x 1.05 = 3.912 x 1.05 = 4.108, e^4.108 ≈ 60.8; close enough for exam, the exam usually gives pre-computed values or asks for the formula).

Effort ≈ 2.4 x 60.8 ≈ 146 person-months.

Example 4: Coupling identification

Module A reads a global variable G and modifies it; Module B also reads G.

This is common coupling (shared global data), second worst. Refactor by passing G as a parameter, reducing to data coupling.

Example 5: Risk exposure

A risk has probability 0.3 and cost impact Rs 5,00,000.

Risk exposure = 0.3 x 5,00,000 = Rs 1,50,000.

This value helps prioritise which risks to mitigate first.

Quick-revision summary

Process models: waterfall -> incremental -> spiral -> agile. Agile = Scrum, XP, FDD, DSDM, Crystal, ASD., Requirements: functional (what) vs non-functional (how well). SRS must be correct, complete, consistent, unambiguous., Cohesion: Functional (best) to Coincidental (worst). Coupling: Data (best) to Content (worst)., McCall = Product operation + Product revision + Product transition. ISO 9126 = 6 characteristics., QA = process, QC = product. Risk = Probability x Impact., COCOMO: E = a x KLOC^b, D = c x E^d. Three modes: organic, semi-detached, embedded., V(G) = E, N + 2 (for one component). V&V: verification = process, validation = product., Alpha = at developer site, Beta = at user site. Regression = re-test after changes., SCM: CI -> baseline -> change control -> version control.

How to study this unit

Draw the cohesion/coupling scale on one card. For every design question, place each option on the scale and pick the best.
Memorise COCOMO formulae as a table, three modes, two formulae each. The exponent is the key differentiator.
Practice function point calculations with 2, 3 examples until you can do them in under 3 minutes.
For testing questions, always read whether the question asks about white-box or black-box; the techniques are entirely different.
Do at least 10 previous-year NET questions on process models, Scrum roles and XP practices are favourite targets.
Build a one-page "quality comparison sheet": McCall factors vs ISO 9126 characteristics, side by side.