Group A — Short Answer Questions (1 Mark Each)

Ans: Software Engineering is, per IEEE 610.12, the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software. It differs from mere programming by using engineering principles, defined processes and measurement to build large, reliable software economically within schedule and budget.

Ans: The Software Development Life Cycle (SDLC) is the structured sequence of phases — requirement analysis, design, coding, testing, deployment and maintenance — through which a software product passes from conception to retirement. It defines the deliverable and the verification criterion of each phase, so that progress is visible and controllable.

Ans: The Waterfall Model is a linear sequential life-cycle model in which each phase must be completed and its output document baselined before the next phase begins, with no overlapping of phases. It is chosen only when requirements are fixed, well understood and unlikely to change, since it produces no working software until late.

Ans: The Spiral Model (Boehm) is a risk-driven, evolutionary meta-model in which the product is developed in a series of spiral cycles, each cycle passing through four quadrants: objective setting, risk analysis and prototyping, engineering/development, and planning of the next cycle. Explicit risk analysis in every cycle makes it suitable for large, expensive, high-risk projects.

Ans: The Prototyping Model builds a quick, partially functional working model of the system so that the customer can evaluate it and refine the requirements through feedback, after which the prototype is either discarded (throwaway) or evolved into the product. It is chosen when the customer cannot state the requirements precisely at the outset.

Ans: Agile is an iterative and incremental development approach that delivers working software in short time-boxed iterations with continuous customer involvement and welcome of late requirement changes. The Agile Manifesto values individuals and interactions, working software, customer collaboration and responding to change over processes and tools, comprehensive documentation, contract negotiation and following a plan.

Ans: A Sprint is a fixed time-box in Scrum (usually 2–4 weeks, never more than one month) at the end of which a “Done”, potentially shippable product increment is delivered. Its scope is frozen once the Sprint begins, and each Sprint ends with a Sprint Review and a Sprint Retrospective.

Ans: The Product Backlog is the single, ordered and continuously evolving list of all known requirements, features, enhancements and fixes for the product. It is owned and prioritised by the Product Owner, and it lives for the entire life of the product.

Ans: The Sprint Backlog is the subset of Product Backlog items selected for the current Sprint together with the task-level plan for delivering them as an increment. It is owned by the Development Team (not the Product Owner) and exists only for the duration of that one Sprint.

Ans: The Software Requirement Specification (SRS) is the formal document that completely states the functional and non-functional requirements agreed between customer and developer, and acts as the contract and the baseline for design, testing and validation. A good SRS is complete, consistent, unambiguous, verifiable, modifiable and traceable — it says what the system must do, whereas the Software Design Document (SDD) says how it will do it.

Ans: A Functional Requirement specifies what the system must do — a particular service, behaviour or input-to-output transformation that the system shall perform. Example: “The ATM shall dispense cash after successfully verifying the customer’s PIN.”

Ans: A Non-Functional Requirement (NFR) specifies a quality attribute or constraint on how well the system performs its functions — performance, reliability, security, usability, portability, maintainability. It generally applies to the system as a whole rather than to one function, and must be stated in a measurable form, e.g. “response time shall be under 2 seconds for 95% of queries”.

Ans: Requirement Elicitation is the first activity of requirement engineering, in which requirements are discovered and gathered from stakeholders, existing systems and documents. Common techniques are interviews, questionnaires, brainstorming, FAST (Facilitated Application Specification Technique), observation, use-case workshops and prototyping.

Ans: A Use Case in UML is a description of a complete sequence of interactions between an actor and the system that yields an observable result of value to that actor. It is drawn as an ellipse in a use-case diagram and may be related to other use cases by «include», «extend» or generalisation.

Ans: A Data Flow Diagram (DFD) is a structured-analysis tool that graphically depicts the flow and transformation of data through a system using four symbols: process (bubble), data flow (arrow), data store (open rectangle) and external entity (square). The Level 0 (context) diagram shows the entire system as a single process with its external entities and no data stores, while the Level 1 DFD explodes that single process into its major sub-processes and data stores.

Ans: Cohesion is an intra-module measure of the degree to which the elements inside a single module belong together and contribute to one single, well-defined task. Its types run from worst to best as: coincidental, logical, temporal, procedural, communicational, sequential and functional cohesion (best).

Ans: Coupling is an inter-module measure of the degree of interdependence between two modules, i.e. the strength of the connection between them. Its types run from best (loosest) to worst as: data coupling (best), stamp, control, external, common and content coupling (worst).

Ans: High cohesion with low coupling is the fundamental goal of modular design: each module performs one well-defined function internally, while interacting with other modules as little as possible and only through simple, well-defined data interfaces. Such a design is easier to understand, test independently, reuse and maintain, because a change in one module produces little ripple effect on the others.

Ans: Modularity is the decomposition of software into separately named and addressable components (modules) that can be designed, coded and tested independently and then integrated to satisfy the requirements. Pressman notes that the effort per module falls as the number of modules grows while the integration effort rises, so there is an optimum number of modules giving minimum total cost.

Ans: Software Architecture is the overall structure of the system — the set of software components, their externally visible properties and the relationships and interactions among them. It represents the earliest and hardest-to-change design decisions; common architectural styles are layered, client–server, pipe-and-filter, repository (data-centred) and MVC.

Ans: Cyclomatic Complexity, proposed by McCabe, is a quantitative measure of the logical complexity of a program, defined as the number of linearly independent paths through its control flow graph. It gives the upper bound on the number of test cases needed for basis-path testing and the lower bound on the number of paths that must be executed for branch coverage; a module with \( V(G) > 10 \) is regarded as too complex and a candidate for redesign.

Ans: For a control flow graph \( G \), McCabe’s formula is \( V(G) = E - N + 2P \), where \( E \) = number of edges, \( N \) = number of nodes and \( P \) = number of connected components (\( P = 1 \) for a single program, giving \( V(G) = E - N + 2 \)). Two equivalent forms are \( V(G) = D + 1 \), where \( D \) is the number of decision (predicate) nodes, and \( V(G) = R \), the total number of regions into which the planar flow graph divides the plane, i.e. the bounded regions plus the one outer unbounded region.

Ans: White-box testing (glass-box or structural testing) derives test cases from knowledge of the internal logic and source code of the module, so as to exercise statements, branches, conditions, independent paths and loops. Basis-path testing uses \( V(G) = E - N + 2 \) to fix the number of independent paths that must be tested, and it is normally performed by developers at the unit level.

Ans: Black-box testing (functional or behavioural testing) derives test cases only from the specified input–output behaviour in the SRS, with no knowledge of the internal code structure. Its standard techniques are equivalence partitioning, boundary value analysis, decision tables, cause–effect graphing and state-transition testing.

Ans: Unit Testing is the testing of the smallest testable component — a single module, function or class — in isolation from the rest of the system. It is predominantly white-box, is carried out by the developer, and uses stubs and drivers to stand in for the modules that the unit calls and is called by.

Ans: Integration Testing tests the interfaces and interactions between modules that have already passed unit testing, so as to expose defects arising from their combination rather than from within a module. Its strategies are big-bang, top-down (needs stubs), bottom-up (needs drivers) and sandwich/hybrid integration.

Ans: System Testing is black-box testing of the complete, fully integrated software in an environment resembling production, validating it against the SRS as a whole. It covers functional behaviour together with non-functional aspects — performance, load, stress, security, recovery and usability — and is normally carried out by an independent test team.

Ans: Acceptance Testing is formal testing carried out by the customer or end user against pre-agreed acceptance criteria to decide whether the delivered system is acceptable. It follows system testing, is entirely black-box and driven by user requirements rather than the SRS alone, and takes the two forms alpha and beta testing.

Ans: Alpha Testing is acceptance testing performed by the customer or potential users at the developer’s site in a controlled environment, with the developer present and recording errors and usage problems as they occur. It always precedes beta testing.

Ans: Beta Testing is a “live” test performed by real end users at their own sites in an uncontrolled environment, with the developer not present. The users report the problems they encounter at intervals, and the developer makes final modifications before general release.

Ans: Equivalence Partitioning is a black-box technique that divides the input domain into classes (partitions) whose members the program is expected to treat identically, so that testing one representative value from each valid and invalid class is as effective as testing every member. It sharply reduces the number of test cases without losing functional coverage.

Ans: Boundary Value Analysis (BVA) is a black-box technique that complements equivalence partitioning by choosing test values at and just around the edges of each partition, since defects cluster at boundaries rather than in the middle of a range. For an input range \( [a,\,b] \) the test values are \( a-1,\ a,\ a+1,\ b-1,\ b,\ b+1 \).

Ans: Regression Testing is the re-execution of a selected subset of previously passed test cases after a modification (bug fix, enhancement or environment change), to confirm that the change has not introduced new defects in the unchanged parts of the software. It differs from retesting, which re-runs only the specific failed test case to verify that one particular reported defect is now fixed.

Ans: Smoke Testing is a shallow-and-wide “build verification” test that exercises only the critical end-to-end functionality of a newly integrated build, in order to decide whether the build is stable enough to be accepted for detailed testing. If the smoke test fails the build is rejected outright and returned to development.

Ans: Sanity Testing is a narrow-and-deep, usually unscripted check made on a relatively stable build to verify that a particular bug fix or newly added function works and that the surrounding area behaves rationally, before committing to full regression testing. It is thus a subset of regression testing, whereas smoke testing is a check on the acceptability of the build itself.

Ans: A Stub is a dummy called (lower-level) module that simulates a subordinate module by returning a canned result, and is required in top-down integration testing. A Driver is a dummy calling (higher-level) module that invokes the module under test with test inputs and displays the results, and is required in bottom-up integration testing.

Ans: COCOMO (Constructive Cost Model), developed by Barry Boehm, is an algorithmic cost-estimation model that predicts effort and schedule from the estimated size of the product in KLOC (thousands of delivered lines of code). Basic COCOMO gives effort \( E = a\,(KLOC)^{b} \) person-months and development time \( D = c\,(E)^{d} \) months, so average staff size \( = E/D \) persons. The coefficients depend on the project mode, chosen by team and product size and by the rigidity of the constraints:

• Organic — small (< 50 KLOC), familiar in-house project, small experienced team, flexible requirements: \( a = 2.4,\ b = 1.05,\ c = 2.5,\ d = 0.38 \).
• Semi-detached — medium (50–300 KLOC), mixed-experience team, medium constraints: \( a = 3.0,\ b = 1.12,\ c = 2.5,\ d = 0.35 \).
• Embedded — large (> 300 KLOC), tight hardware, software and regulatory constraints (e.g. real-time/avionics): \( a = 3.6,\ b = 1.20,\ c = 2.5,\ d = 0.32 \).

Ans: Function Point (FP) analysis is Albrecht’s size metric that measures the functionality delivered to the user independently of the programming language, by counting five function types — External Inputs, External Outputs, External Inquiries, Internal Logical Files and External Interface Files — each weighted as simple, average or complex to give the Unadjusted Function Points. The final size is \( FP = UFP \times VAF \), where \( VAF = 0.65 + 0.01 \sum_{i=1}^{14} F_i \) and each of the 14 general system characteristics \( F_i \) is rated from 0 to 5.

Ans: Software Reliability is the probability of failure-free operation of a program in a specified environment for a specified period of time. For a constant failure rate \( \lambda \) it is given by \( R(t) = e^{-\lambda t} \), and in practice it is measured through MTBF, failure intensity or defect density \( = \dfrac{\text{Number of defects}}{\text{Size (KLOC or FP)}} \).

Ans: Mean Time Between Failures (MTBF) is the average time elapsing between two consecutive failures of a repairable system, and therefore includes both the operating time and the repair time: \( MTBF = MTTF + MTTR \). System availability follows as \( \text{Availability} = \dfrac{MTTF}{MTTF + MTTR} \times 100\% \).

Ans: Mean Time To Failure (MTTF) is the average time for which the system operates correctly, from the instant it is started or restored until the next failure occurs — i.e. the pure up-time component of MTBF. It excludes repair time and is the measure normally used for non-repairable items.

Ans: Mean Time To Repair (MTTR) is the average time taken to detect, diagnose and correct a failure and restore the system to service — i.e. the down-time component of \( MTBF = MTTF + MTTR \). It is a measure of maintainability rather than of reliability.

Ans: Software Quality Assurance (SQA) is the umbrella set of planned and systematic activities — standards and procedures, reviews and inspections, audits, process definition, measurement and reporting — that give management confidence that the product will conform to its requirements. SQA is process-oriented and preventive, whereas quality control (testing) is product-oriented and detective.

Ans: CMMI (Capability Maturity Model Integration) is the SEI’s process-improvement framework that assesses and rates the maturity of an organisation’s software processes. Its five staged maturity levels are 1 Initial, 2 Managed (Repeatable), 3 Defined, 4 Quantitatively Managed and 5 Optimising.

Ans: Software Maintenance is the modification of a software product after delivery to correct faults, to adapt it to a changed environment, or to improve its performance and other attributes (IEEE 1219). It consumes roughly 60–70% of the total life-cycle cost and is classified as corrective, adaptive, perfective and preventive maintenance.

Ans: Corrective Maintenance is the reactive modification carried out to diagnose and remove residual faults (errors) discovered in the software after delivery. It restores the software to its specified behaviour and accounts for roughly 20% of total maintenance effort.

Ans: Adaptive Maintenance is the modification carried out to keep a working software product usable in a changed or changing environment — a new operating system, hardware platform, DBMS or compiler, or a change in statutory and regulatory rules. It neither fixes reported bugs nor adds user-requested features.

Ans: Perfective Maintenance is the modification carried out to add new functionality requested by the user, or to improve the performance, usability or maintainability of software that is already working correctly. It is the largest category, absorbing about 50% of the total maintenance effort.

Ans: Preventive Maintenance is the proactive modification carried out to detect and correct latent faults before they manifest as failures, and to make the software easier to maintain in future — for example re-documentation, code restructuring, refactoring and optimisation. It is not a response to any reported problem.

Ans: Software Re-engineering is the examination and alteration of an existing legacy system so as to reconstitute it in a new, more maintainable form without changing its external functionality. It typically proceeds as inventory analysis → reverse engineering → restructuring and re-documentation → forward engineering.

Ans: Reverse Engineering is the process of analysing an existing program or executable in order to recover its design, data structures and specification at a higher level of abstraction — that is, a design-recovery process. It only extracts information and produces documentation and does not alter the subject system, unlike re-engineering.

Ans: A CASE (Computer-Aided Software Engineering) Tool is automated software that supports one or more software-engineering activities. Upper CASE tools support planning, analysis and design (diagram editors, data dictionaries), lower CASE tools support coding, testing and maintenance (code generators, debuggers, test harnesses), and I-CASE integrates both across the whole life cycle.