optional · CSS study notes
P-I.V. Software Engineering
https://www.tutorialspoint.com/software_engineering/index.htm CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. Index for Software Engineering — one dedicated page per outline item from the source textbook's Chapter 5 table of contents, in the exact order they appear (28 headings, including all 2016/2017 past-paper-flagged items).
Full Topic List (in TOC order)
Archived (superseded — content now split across the granular pages above)
✅ Self-Test Questions (with Answers)
Q1. Distinguish the Waterfall, Spiral, and Agile process models by their approach to changing requirements.
Ans: Waterfall freezes requirements at the start; each phase must finish before the next begins, so a change late in the project is expensive and usually requires going back through every phase — it suits small projects with stable, well-understood requirements. Spiral expects change but manages it through risk analysis: each loop (objectives → risk analysis → engineering → evaluation) re-examines requirements with the customer, so changes are absorbed at the start of the next spiral; it suits large, high-risk projects. Agile welcomes change at any point, even late in development: requirements live in a prioritised backlog, working software is delivered in short iterations (1–4 weeks) and the customer re-prioritises each sprint — it suits projects where requirements are volatile or unclear.
Q2. Differentiate functional from non-functional requirements with one example each.
Ans: Functional requirements state what the system must do — specific features, services and behaviour: "The system shall allow a user to reset a forgotten password through an emailed link." Non-functional requirements state how well it must do it, constraining quality attributes: "Every page shall load within 2 seconds for 95% of requests under a load of 5,000 concurrent users." NFRs cover performance, security, usability, reliability, portability and legal compliance; they are often emergent properties of the whole system, and violating one can make a system unusable even when every functional requirement is met.
Q3. Name and briefly describe the four types of software maintenance.
Ans: (1) Corrective — fixing defects found after delivery; (2) Adaptive — adjusting the software to a changed environment (new OS version, new hardware, changed law or external API); (3) Perfective — improving performance or adding user-requested enhancements (the largest share, typically around 50%); (4) Preventive — work done to avoid future problems: refactoring, restructuring, updating documentation and reducing technical debt. Maintenance usually consumes 60–80% of a system's total lifecycle cost.
Q4. What is the key difference between black-box and white-box testing?
Ans: Black-box (functional) testing treats the program as an opaque box: tests are derived from the specification only, without knowledge of the code — techniques include equivalence partitioning, boundary value analysis, decision tables and state transition testing. White-box (structural/glass-box) testing uses knowledge of the internal code structure to design tests, aiming at coverage criteria — statement, branch/decision, condition and path coverage, plus basis-path testing using cyclomatic complexity. Black-box finds missing functions and wrong behaviour; white-box finds untested logic, dead code and hidden paths. (Grey-box combines both.)
Q5. How does Software Quality Assurance differ from software testing?
Ans: SQA is process-oriented and preventive: it defines and audits the standards, procedures, reviews, training and metrics that make defects less likely in the first place, and it covers the whole lifecycle (it is a managerial, umbrella activity). Testing is product-oriented and detective: it executes the software to find defects that are already there, and it is one activity within the wider quality framework. Related term: Quality Control (QC) is the product-oriented verification activity (reviews, inspections, testing) that checks the built product against requirements — so SQA ⊃ QC ⊃ testing.
Q6. Distinguish the Evolutionary and Incremental models — what does each actually deliver at the end of a cycle?
Ans: The Incremental model divides the known, agreed requirements into increments and delivers a working, production-usable piece of the final system at the end of each increment — increment 1 might be "registration and login", increment 2 "payments". The core architecture is planned upfront, and the increments add up to the complete system. The Evolutionary (prototyping/iterative) model starts with incomplete requirements and delivers a prototype or refined version of the whole system at the end of each cycle, which the customer evaluates so that requirements can be discovered and refined; early deliverables may be throwaway or need substantial rework. In short: incremental delivers part of the finished product; evolutionary delivers a rougher version of the whole product.
Q7. List the five phases of RAD, and explain how JAD typically feeds into it.
Ans: RAD phases: (1) Business modelling — what information drives the business process; (2) Data modelling — refining that information into data objects and relationships; (3) Process modelling — how data objects are added, modified, deleted and retrieved; (4) Application generation — building with reusable components, fourth-generation tools and code generators; (5) Testing and turnover — testing mostly new components, since reused ones are already proven. RAD relies on timeboxing (typically 60–90 days) and parallel teams. JAD (Joint Application Development) feeds in during the first three phases: it brings users, managers and developers into structured workshops (with a facilitator, scribe and defined agenda) to elicit and agree requirements and screen designs quickly — compressing weeks of interviews into days, which is what makes RAD's short timeboxes feasible.
Q8. Name the five named software paradigms and explain why they're distinct from process models.
Ans: The paradigms in this syllabus's framing are: (1) Software Development Paradigm (requirements gathering, design, programming); (2) Software Design Paradigm (design, maintenance, programming); (3) Programming Paradigm (coding, testing, integration); and within programming, the classic paradigms of (4) imperative/procedural and (5) object-oriented — with functional and logic programming as further paradigms. A paradigm is a way of thinking about and structuring software (a conceptual approach to how problems are represented and solved), whereas a process model (Waterfall, Spiral, Agile) is a management framework defining the order, timing and deliverables of activities. One project can use an object-oriented paradigm inside an Agile process model — the two answer different questions: how do we think about the software versus how do we organise the work.
Q9. Contrast function-oriented and object-oriented design strategies on how each treats data and functions.
Ans: Function-oriented (top-down/structured) design separates the two: the system is decomposed into a hierarchy of functions/modules that act on shared or passed data structures, documented with DFDs, structure charts and data dictionaries. Data is often global or widely shared, so a change to a data structure ripples through many functions. Object-oriented design binds data and the functions that operate on it together inside objects, which hide their state behind an interface (encapsulation) and communicate by messages; it uses class, sequence and state diagrams. This gives better information hiding, reuse through inheritance and polymorphism, and localised change — which is why OOD dominates for large, evolving systems, while function-oriented design remains useful for small, computation-centred programs.
Q10. Distinguish process documentation from product documentation, and system documentation from user documentation.
Ans: Process documentation records how the development is carried out and managed — plans, schedules, standards, meeting minutes, change requests, review reports; much of it becomes obsolete once the project ends. Product documentation describes the delivered software itself and lives as long as the product. Product documentation splits into: system documentation, written for developers and maintainers (requirements specification, architecture and design documents, source-code comments, test plans and validation reports), and user documentation, written for end users and operators (functional description, installation guide, introductory/tutorial manual, reference manual and system administrator's guide).
Q11. What does software re-engineering change, and what does it deliberately leave unchanged, versus evolution?
Ans: Re-engineering changes the implementation — it restructures or rewrites legacy code, migrates languages, platforms or databases, improves modularity and regenerates documentation — while deliberately preserving the system's functionality and behaviour; users should see the same system, only more maintainable. Its activities are inventory analysis, document restructuring, reverse engineering, code and data restructuring, and forward engineering. Software evolution, by contrast, changes what the system does: adding features and adapting to new requirements over its lifetime (described by Lehman's laws, notably continuing change and increasing complexity). In short: re-engineering improves the how without altering the what; evolution alters the what.
Q12. What does requirements sign-off protect against, and where does it sit relative to validation and design?
Ans: Sign-off is the formal step in which the client and stakeholders review and approve the documented requirements (the SRS), making it the agreed baseline. It protects against scope creep (informal additions after work starts), disputes over what was actually agreed, and wasted rework against unfinalised requirements; afterwards, changes must go through formal change control rather than informal requests. In sequence, it is the culmination of validation — it happens after validation has confirmed the requirements meet stakeholder needs and before design begins — and from that moment requirements shift from negotiable to being the fixed reference against which verification and acceptance are measured.