Ans: Software Engineering (IEEE 610.12) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software — i.e., the use of engineering principles to build reliable, economical software on time and within budget.

Ans: A software process model is an abstract representation of the software development life cycle that defines the phases (process activities) and the order in which they are carried out to produce a software product.

Ans: The five generic phases are: (1) Communication, (2) Planning, (3) Modeling (analysis & design), (4) Construction (coding & testing), and (5) Deployment.

Ans: The Waterfall Model is a linear-sequential life-cycle model in which each phase must be completed and baselined before the next begins, with no overlap — best suited when requirements are well understood and stable.

Ans: Iterative model refines a complete system through repeated cycles. Incremental model delivers the system in successive slices (increments), where each increment adds new functionality on top of the previous one.

Ans: The Spiral Model (Boehm) is a risk-driven process model that combines prototyping with controlled, iterative cycles; each loop passes through Planning, Risk Analysis, Engineering, and Customer Evaluation quadrants.

Ans: CBD is a process model that emphasises assembling software from reusable, pre-built, independently-deployable components with well-defined interfaces, reducing development effort and time.

Ans: Formal methods are mathematically-based techniques (notation, semantics, verification) for specifying, developing, and verifying software so that the system can be proven correct using rigorous mathematical proofs.

Ans: Agile is an umbrella of iterative, customer-collaborative software development methods (XP, Scrum, FDD) based on the Agile Manifesto — valuing individuals, working software, customer collaboration, and responding to change.

Ans: XP is an Agile methodology using short development cycles (iterations), pair programming, test-driven development, continuous integration, refactoring, and on-site customer presence to deliver high-quality code.

Ans: A Sprint is the basic unit of development in Scrum — a time-boxed iteration (usually 1–4 weeks) during which a potentially shippable product increment is produced.

Ans: RUP is an iterative software process framework organised around four phases (Inception, Elaboration, Construction, Transition) and six best practices including iterative development and use-case driven design.

Ans: COCOMO (Constructive Cost Model) by Boehm is an algorithmic software cost-estimation model that predicts effort, schedule, and staffing from the estimated size (KLOC) and a mode (Organic, Semi-detached, Embedded).

Ans: Requirements Engineering is the systematic process of eliciting, analysing, negotiating, specifying, validating, and managing the requirements for a software system.

Ans: An SRS is a formal document that completely describes the external behaviour of the system, the non-functional constraints, and the functional requirements; it serves as the contract between customer and developer.

Ans: Functional Requirements describe what the system does (features, functions). Non-Functional Requirements describe how well it does them — performance, security, usability, reliability, maintainability.

Ans: An RTM is a table that maps each requirement to its source, design elements, code modules, and test cases, ensuring every requirement is implemented and tested (forward & backward traceability).

Ans: Software Design is the process of transforming the requirements into a blueprint for construction — defining architecture, components, interfaces, data structures, and algorithms.

Ans: Abstraction, Refinement, Modularity, Software Architecture, Control Hierarchy, Structural Partitioning, Data Structure, Software Procedure, Information Hiding.

Ans: A Design Pattern (Gang-of-Four) is a reusable, proven solution to a recurring design problem — a named template describing how to solve a problem in a particular context (Creational, Structural, Behavioural).

Ans: An architectural style is a named, reusable pattern that defines components, their responsibilities, and the connectors between them (e.g., layered, client–server, pipe-and-filter, microservices).

Ans: Component-level design refines the architectural data-flow into detailed procedural descriptions for each module — specifying data structures, interfaces, and algorithms at the lowest level of abstraction.

Ans: (1) Place the user in control, (2) Reduce the user's memory load, (3) Make the interface consistent.

Ans: Unit testing verifies the smallest testable parts (functions, classes, methods) of the software in isolation, usually performed by the developer using a unit-testing framework (JUnit).

Ans: Functional (Black-Box) testing verifies the software against specifications without knowing internal code. Structural (White-Box) testing verifies the internal logic, branches, and paths of the code.

Ans: Integration testing exercises the interfaces between integrated modules to expose faults in their interaction — using strategies like top-down, bottom-up, or sandwich (regression) integration.

Ans: System testing verifies the complete, integrated software system against its specified requirements on a production-like environment, including functional, performance, security, and recovery tests.

Ans: Debugging is the process of locating, analysing, and removing the cause of a software fault (the symptomatic failure) — typically performed after a failed test execution.

Ans: SQA is the planned, systematic set of activities (audits, reviews, standards, testing) that ensure that software processes and products conform to requirements, standards, and procedures.

Ans: SCM is the discipline of tracking and controlling changes in the software's artefacts (code, docs, models) to maintain integrity and traceability throughout the project life cycle.

Ans: ISO 9000 is a family of internationally recognised quality-management standards that define best practices for a quality assurance system; ISO 9001 certification indicates conformance to these standards.

Ans: The SEI Capability Maturity Model is a 5-level framework (Initial, Repeatable, Defined, Managed, Optimising) that describes the maturity of an organisation's software processes.

Ans: Software maintenance is the modification of a software product after delivery to correct faults, improve performance or other attributes, adapt to a changed environment, or prevent future degradation.

Ans: Reverse engineering is the process of analysing an existing system to identify its components and their interrelationships and to create representations of the system at higher levels of abstraction.

Ans: Software re-engineering is the examination and alteration of an existing system to reconstitute it in a new form, including reverse engineering, restructuring, and forward engineering, without changing its functionality.

Software Process Models Compared

Generic Process Model

The generic process model (Pressman) defines five framework activities that span all software projects, regardless of model choice:

• Communication — Stakeholder collaboration to understand goals and requirements.
• Planning — Define scope, resources, schedule, and risk; produce the Software Project Management Plan.
• Modeling — Analysis & design: create data, functional, behavioural models of the system.
• Construction — Code generation and testing (unit, integration, system).
• Deployment — Delivery to customer, evaluation, feedback, and continued support/maintenance.

Umbrella activities (work across all five) include project tracking, risk management, quality assurance, configuration management, and reviews.

Scrum Framework

Roles: Product Owner (prioritises backlog), Scrum Master (removes impediments), Development Team (cross-functional, self-organising).

Events: Sprint (1–4 weeks), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Backlog Refinement.

Artefacts: Product Backlog, Sprint Backlog, Product Increment (potentially shippable), Burn-down/Burn-up charts.

COCOMO Model

The Constructive Cost Model is applied in three stages:

1. Basic COCOMO — uses size and mode only.
2. Intermediate COCOMO — adds 15 cost drivers (product, hardware, personnel, project).
3. Detailed COCOMO — adds 5 scale factors and phased effort multipliers.

Basic formulas:

\[ E = a \times (KLOC)^b \qquad T_{dev} = c \times (E)^d \]

Example (Organic mode, 32 KLOC): a=2.4, b=1.05, c=2.5, d=0.38

\[ E = 2.4 \times (32)^{1.05} \approx 91.3 \text{ person-months} \]

\[ T_{dev} = 2.5 \times (91.3)^{0.38} \approx 13.9 \text{ months} \]

RUP Phases

• Inception — Define scope, identify stakeholders, draft initial use cases, evaluate feasibility.
• Elaboration — Refine requirements, establish architectural baseline, identify risks, create detailed design.
• Construction — Iterative implementation of components, continuous testing, beta releases.
• Transition — Deployment to users, user training, beta testing, defect fixes, final release.

RUP also prescribes nine core disciplines (six engineering + three supporting) that run in parallel with different intensity across phases.

Requirements Elicitation Techniques

Elicitation gathers information from stakeholders. Common techniques:

• Interviews — One-on-one or group, formal closed-ended / open-ended questions.
• Workshops / JAD Sessions — Joint Application Development with all stakeholders together.
• Questionnaires / Surveys — Useful for a large, geographically-distributed user base.
• Observation (Ethnography) — Watch users perform their work in their natural environment.
• Document Analysis — Review existing forms, reports, manuals to extract business rules.
• Prototyping — Build quick mock-ups to clarify ambiguous requirements.
• Brainstorming / Focus Groups — Generate ideas collaboratively.

SRS Document Structure (IEEE 830)

Each section uses measurable, testable, unambiguous language. The SRS is the baseline for design, coding, testing, and validation.

Functional vs Non-Functional Requirements

Requirement Traceability Matrix (RTM)

An RTM is a 2D table that links every requirement to its origin, design element, implementation code, and test cases. Two directions of traceability exist:

• Forward Traceability — From requirements → design → code → tests. Ensures every requirement is implemented and tested.
• Backward Traceability — From code/tests back to requirement. Ensures every artefact traces to a valid business need.

Importance: Helps evaluate impact of change requests, validates 100% requirement coverage, supports audit, and prevents gold-plating (unwanted features).

Software Design Process

Design is an iterative process that transforms the SRS into a multi-layered model:

1. Architectural Design — Identify subsystems, their responsibilities, and interactions.
2. Data Design — Define data structures, file formats, database schemas.
3. Interface Design — Define external (user) and internal (module) interfaces.
4. Component-Level Design — Refine each module's algorithm and procedural detail.

The Design Model is the totality of all artefacts produced — DFDs, ER diagrams, UML diagrams (class, sequence, state, activity), architectural diagrams, and detailed module specs.

Common Architectural Styles

• Layered (N-Tier): Presentation, Business, Data layers — classic enterprise pattern.
• Client–Server: Thin/thick clients communicate with a centralised server.
• Pipe-and-Filter: Data flows through transformation stages (e.g., Unix pipelines, compilers).
• Model-View-Controller (MVC): Separates data, presentation, and input handling.
• Repository (Blackboard): Shared data store + independent processing components (AI systems).
• Event-Driven: Components communicate via events on a bus (e.g., Kafka).
• Microservices: Small, independent services communicating via lightweight APIs.
• Service-Oriented (SOA): Coarse-grained reusable services with formal contracts.

Architectural Mapping with DFD

Data-flow style architectures are mapped directly from the DFD:

1. Identify the type of data flow (transform flow / transaction flow).
2. Isolate the input, transform centre, and output boundaries on the DFD.
3. Perform First-Level Factorisation — create a single "module factory" for each input/output region.
4. Perform Second-Level Factorisation — break each input/output branch into sub-modules.
5. Refine using design heuristics (e.g., factoring).

For transaction flows, identify the transaction centre (the process that determines type) and map each path as a separate branch.

Three Golden Rules of UI Design

(Shneiderman's Golden Rules)

1. Place the user in control — Allow undo/redo, shortcuts, defaults, meaningful feedback, exit gracefully.
2. Reduce the user's memory load — Recognise rather than recall, use metaphors, defaults, short menus, consistent layouts.
3. Make the interface consistent — Uniform fonts, colours, terminologies, predictable behaviour, platform conventions.

Other principles: feedback, visibility, error prevention, aesthetic integrity, user diversity, help & documentation.

Testing Taxonomy

Tests can also be classified by purpose (smoke, regression, sanity, retest) and by development phase (verification, validation).

Unit & Integration Testing

Unit Testing: Tests individual functions/classes in isolation. Uses drivers/stubs for incomplete modules. Usually done by developers using JUnit / pytest frameworks.

Integration Testing Strategies:

• Top-Down: Test main first; stubs for lower levels. Easy to demonstrate early.
• Bottom-Up: Test lower levels first; drivers for higher levels. Easy to drive.
• Sandwich (Hybrid): Combines both — top & bottom meet in the middle.
• Big-Bang: Integrate everything at once; risky, hard to debug.

V-Model of Testing

The V-Model maps each development phase to its corresponding testing phase — showing that test preparation happens in parallel with development, not only after coding.

Debugging Approaches

• Brute Force: Add print statements, run with traces, examine core dumps — labour-intensive, often last resort.
• Backtracking: Start at the symptom and trace backwards through the code to the cause — works well for small programs.
• Cause Elimination: Use binary search / hypothesis-testing — identify possible causes by eliminating one variable at a time (most systematic).
• Program Slicing: Compute the set of statements (the slice) that affect the value of a variable of interest.
• Interactive Debuggers: Step-through, breakpoints, watch variables — most popular modern approach.

SEI CMM Levels

• L1 Initial: Process is ad-hoc, chaotic; success depends on individual effort.
• L2 Repeatable: Basic project management; cost, schedule tracked.
• L3 Defined: Processes are standardised across the organisation and documented.
• L4 Managed: Detailed metrics & statistical control over processes.
• L5 Optimising: Continuous process improvement through innovation.

Software Reliability & Reviews

Software Reliability is the probability that the software performs its intended function without failure under specified conditions for a specified period.

Metrics: MTTF (Mean Time To Failure), MTTR, MTBF, Availability = MTTF/MTBF.

Formal Technical Reviews (FTRs) are structured meetings by peers to identify defects in early artefacts:

• Walkthroughs — author-led, informal.
• Inspections — most formal; uses roles (moderator, reader, recorder, reviewer).
• Code Reviews — peer review for code quality and standards compliance.

SCM Activities

• Configuration Identification: Naming & organising configuration items (code, docs, libraries).
• Version Control: Track changes, branching, merging (Git, SVN).
• Baseline Management: Freeze formally approved versions.
• Change Control: Formal CCB review of proposed changes.
• Configuration Audits: Verify conformance to baseline and standards.
• Release Management: Package, version, distribute.

Maintenance Process Models

• Quick-Fix Model: Ad-hoc bug fixes — works only for very small systems.
• Iterative Enhancement Model: Iteratively add features; reflects real maintenance work.
• Reuse-Oriented Model: Emphasises reusing existing components & frameworks.
• IEEE Maintenance Model: Formal steps — Identify, Classify, Analyse, Design, Implement, Regression Test, Acceptance.

Maintenance types: Corrective (bugs), Adaptive (environment), Perfective (new features), Preventive (future-proofing).

COCOMO-II for Maintenance

COCOMO-II maintenance estimation uses an Annual Change Traffic metric:

\[ AT = \frac{Added + Modified}{Original\;size} \]

\[ AD = AT \times AAF \qquad\; E_{maintenance} = 2.4 \times (AD)^{1.05} \]

Where AAF (Adaptation Adjustment Factor) accounts for differences in software quality, hardware, and personnel.

This helps managers budget annual maintenance effort given the percentage of code being changed each year.

Reverse Engineering

The process of analysing a legacy system to recover its design, data, and behavioural models, producing higher-level abstractions from existing source.

Steps:

1. Information extraction: Parse source, extract static and dynamic information.
2. Database reverse engineering: Recover ER schema, table relations.
3. Recover design abstractions (UML): Reconstruct class, sequence, state diagrams.

Goals: Recovery of lost design, legacy migration, security audit, understanding competitors' code, identifying reusable assets.

Software Re-engineering Process

• Inventory Analysis: Prioritise legacy components by business value & technical risk.
• Document Restructuring: Regenerate up-to-date docs from existing code.
• Reverse Engineering: Recover design & data models.
• Code & Data Restructuring: Refactor without changing external behaviour.
• Forward Engineering: Generate modern implementation from refactored design.

Agile Manifesto & 12 Principles

Manifesto Values:

• Individuals & interactions over processes & tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

12 Principles (selected): early & continuous delivery, welcome changing requirements, business & developers daily collaboration, sustainable development, attention to technical excellence & good design, simplicity, self-organising teams, regular reflection & adaptation.

Master Answer: Comparing Process Models

Part (a) Comparison Diagram

Part (b) Comparison & When to Use

When to use:

• Waterfall: Payroll system with fixed regulations; defence project with strict milestones.
• Spiral: Medical device software where risk analysis is critical and prototypes must be evaluated.
• Agile: Mobile startup app where user feedback rapidly shapes features.

Master Answer: SDLC & Agile Scrum

Part (a) SDLC Phases

• Requirement Analysis: Gather & document user needs.
• System Design: Architectural & detailed design.
• Implementation (Coding): Translate design into source code.
• Testing: Unit, integration, system, acceptance.
• Deployment: Release to production.
• Maintenance: Corrective, adaptive, perfective, preventive.

Part (b) Agile Scrum Workflow

Roles: Product Owner, Scrum Master, Development Team.

Events: Sprint, Planning, Daily Scrum, Review, Retrospective, Backlog Refinement.

Artefacts: Product Backlog, Sprint Backlog, Increment, Burn-down chart.

Master Answer: SRS Document

Part (a) SRS Structure (IEEE 830)

Part (b) Types of Requirements

Master Answer: Software Testing Levels

Part (a) Testing Levels

• Unit: Individual functions/classes.
• Integration: Interface defects between modules.
• System: Compliance with full requirements.
• Acceptance: User-driven alpha/beta testing.

Part (b) Black-Box vs White-Box

Part (c) Test Case Design — Discount Coupon Field

Field accepts strings of length 5 to 12 alphanumeric chars.

Master Answer: UI Design & Web Architectures

Part (a) UI Design Principles

Shneiderman's three Golden Rules — user control, reduce memory load, consistency — drive interface design. Additional principles (Nielsen): visibility of system status, match between system & real world, user control & freedom, error prevention, recognition over recall, flexibility, aesthetic & minimalist design, help users recover from errors, help & documentation.

Web App Design Process

Part (b) MVC vs Client-Server vs Microservices

MVC is a pattern; client-server is a deployment model; microservices is an architectural style for distributed independently-scaled services.

Master Answer: Waterfall & Waterfall vs Agile

Part (a) Waterfall Model Phases

• Each phase produces a deliverable that becomes the input to the next.
• Backtracking (returning to a previous phase) is rare and costly — captured as a maintenance activity.
• Suitable only when requirements are stable and clearly understood.

Part (b) Waterfall vs Agile

Master Answer: SRS Quality & Traceability

Part (a) FURPS+ Characteristics

• F — Functional: Features, capabilities.
• U — Usability: Aesthetics, help, documentation.
• R — Reliability: Availability, MTBF, recoverability.
• P — Performance: Response time, throughput, accuracy.
• S — Supportability: Configurability, localisation, install.
• + : Design constraints, implementation, interface, physical.

Part (b) Requirement Traceability

Forward traceability: requirement → test (verifies every requirement is implemented).

Backward traceability: test → requirement (verifies every test serves a valid requirement).

Master Answer: SEI CMM Levels & CMM/CMMI

Part (a) Five Maturity Levels

Part (b) CMM vs CMMI

Master Answer: COCOMO Calculation

Part (a) Basic COCOMO Calculation

Given: Size = 20 KLOC, Mode = Organic. Constants: a=2.4, b=1.05, c=2.5, d=0.38.

1. Effort (E):
   \(E = a \times (KLOC)^b\)
   \(E = 2.4 \times (20)^{1.05}\)
   \(20^{1.05} \approx 23.21\)
   \(E \approx 2.4 \times 23.21 = \mathbf{55.7 \; Person-Months}\)
2. Development Time (Tdev):
   \(T_{dev} = c \times (E)^d\)
   \(T_{dev} = 2.5 \times (55.7)^{0.38}\)
   \(55.7^{0.38} \approx 4.78\)
   \(T_{dev} \approx 2.5 \times 4.78 = \mathbf{11.95 \; Months}\)
3. Average Staffing (SS):
   \(SS = E / T_{dev} = 55.7 / 11.95 \approx \mathbf{4.66 \approx 5 \; persons}\)

Part (b) COCOMO Modes

Master Answer: Function Point Calculation

Part (a) Calculation

Step 2 — Value Adjustment Factor (VAF):

\[ VAF = 0.65 + (0.01 \times \Sigma F_i) = 0.65 + 0.40 = \mathbf{1.05} \]

Step 3 — Final Function Points:

\[ FP = UFP \times VAF = 165 \times 1.05 = \mathbf{173.25 \; FP} \]

Part (b) About VAF & Fi

The 14 General System Characteristics (Fi), each rated 0–5, measure: Data communications, Distributed processing, Performance, Heavily used configuration, Transaction rate, Online data entry, End-user efficiency, Online update, Complex processing, Reusability, Installation ease, Operational ease, Multiple sites, Facilitation of change. VAF adjusts UFP for project complexity.

Master Answer: Maintenance & Re-engineering

Part (a) Maintenance Types

• Corrective: Fix discovered defects.
• Adaptive: Adapt to changes in environment (hardware, OS, regulations).
• Perfective: New features, performance, usability improvements.
• Preventive: Restructure code to prevent future failures.

Maintenance Process (IEEE)

Part (b) Re-engineering Lifecycle

• Reverse Engineering: Analyse to recover design & data models.
• Restructuring: Refactor code/data without changing behaviour.
• Forward Engineering: Generate new system from refactored design.

Master Answer: Design Patterns & Component Design

Part (a) GoF Pattern Categories

Part (b) Patterns with Java

Singleton:

public class DBConnection {
    private static final DBConnection INSTANCE = new DBConnection();
    private DBConnection() {}
    public static DBConnection getInstance() { return INSTANCE; }
}

Factory:

interface Shape { void draw(); }
class Circle implements Shape { public void draw() { System.out.println("Circle"); } }
class Square implements Shape { public void draw() { System.out.println("Square"); } }
class ShapeFactory {
    public static Shape create(String type) {
        return switch (type) {
            case "C" -> new Circle();
            case "S" -> new Square();
            default -> throw new IllegalArgumentException();
        };
    }
}

Observer:

interface Observer { void update(String msg); }
class NewsChannel implements Observer {
    public void update(String msg) { System.out.println("Breaking: " + msg); }
}
class Publisher {
    private final List<Observer> obs = new ArrayList<>();
    public void subscribe(Observer o) { obs.add(o); }
    public void publish(String msg) { for (Observer o : obs) o.update(msg); }
}

Part (c) Component-Level Design

Refines the architectural DFD into procedural specifications for each module — pseudocode, I/O formats, data structures, algorithms. Purpose: a translation-ready blueprint, easier integration, reduced defect density, and unambiguous interface contracts.