BE Computer Engineering (Pokhara University) Software Engineering (PU, CMP 348) Question Paper 2079 Nepal

(a) Waterfall Model and Incremental Model

Waterfall Model

The Waterfall model is a linear, sequential process in which each phase must be completed and its output (a document) approved before the next phase begins. There is no overlap; the output of one phase flows down like a waterfall into the next.

Phases (diagram, top to bottom):

Requirements Analysis
        |
        v
  System Design
        |
        v
  Implementation (Coding)
        |
        v
     Testing
        |
        v
   Deployment
        |
        v
   Maintenance

Characteristics: simple, well-documented, easy to manage; but inflexible to change, no working software until late, and unsuitable when requirements are unclear.

Incremental (Iterative) Model

The Incremental model divides the system into small, manageable increments. Each increment goes through requirements, design, code and test, and delivers a working partial product. Successive increments add functionality until the full system is built.

Increment 1:  Req -> Design -> Code -> Test -> Deliver (core)
Increment 2:  Req -> Design -> Code -> Test -> Deliver (+ features)
Increment 3:  Req -> Design -> Code -> Test -> Deliver (complete)

Characteristics: early partial delivery, easier to accommodate change, earlier feedback and lower risk; but needs good architecture up front and clear definition of the full system.

(b) Recommended Model: Spiral Model

For a large, safety-critical air-traffic monitoring system with unstable requirements and high technical risk per phase, the Spiral model (Boehm) is recommended because it is explicitly risk-driven and supports iterative refinement of requirements.

The spiral is divided into four quadrants, traversed once per loop:

1. Determine objectives, alternatives and constraints — fix the goals, constraints and alternative solutions for this iteration.
2. Identify and resolve risks — evaluate alternatives, identify risks (e.g. safety, performance) and reduce them through prototyping, simulation and analysis.
3. Develop and verify the next-level product — design, code, and test the deliverable for this cycle.
4. Plan the next phase — review progress with stakeholders and plan the next loop.

Justification:

• Unstable requirements are accommodated because each loop re-evaluates and refines requirements.
• The explicit risk analysis quadrant and prototyping directly address the significant technical risk per phase — critical for a safety-critical system.
• Continuous customer involvement and verification at each cycle suit a safety-critical domain where validation is essential.

Hence the Spiral model is preferred over the rigid Waterfall (which cannot handle unstable requirements) or pure Incremental (which lacks systematic risk management).

(a) Requirement Engineering Process

Requirement Engineering (RE) is the systematic process of discovering, analysing, documenting, validating and managing the requirements of a system. Its main activities are:

1. Elicitation — gather requirements from stakeholders (students, librarians, admin).
2. Analysis & Negotiation — resolve conflicts and prioritise.
3. Specification — document requirements in an SRS.
4. Validation — check requirements are correct, complete and consistent.
5. Management — control changes to requirements over time.

Functional vs Non-functional Requirements

• Functional requirements state what the system does — the services and behaviour.
• Non-functional requirements state quality constraints — how well the system performs (performance, security, usability).

Functional requirements (Library system):

1. The system shall allow a student to search the catalogue and reserve a book.
2. The system shall allow a librarian to issue and return books and compute fines.
3. The system shall allow an administrator to add/remove members and book records.

Non-functional requirements:

1. Performance — a catalogue search shall return results within 2 seconds.
2. Security — access shall be role-based with authenticated login.
3. Availability — the system shall be available 99.5% of working hours.

(b) Use-Case Diagram and Issue Book Description

Use-case diagram (described in words): A system boundary box labelled Library Management System. Three actors stand outside: Student, Librarian, Administrator.

• Student → Search Catalogue, Reserve Book, View Account.
• Librarian → Issue Book, Return Book, Calculate Fine.
• Administrator → Manage Members, Manage Book Records, Generate Reports.
• Login is an <<include>> use case shared by all actors.

   Student ---- (Search Catalogue)
          \---- (Reserve Book)
   Librarian -- (Issue Book) --include--> (Login)
          \---- (Return Book) \---- (Calculate Fine)
   Administrator -- (Manage Members)
          \---- (Manage Book Records) ---- (Generate Reports)

Structured Use-Case Description: Issue Book

Main flow:

1. Librarian selects Issue Book.
2. Librarian enters member ID and book ID.
3. System validates the member and checks book availability.
4. System checks the member has not exceeded the borrowing limit and has no pending fine.
5. System records the loan, sets the due date, and decrements available copies.
6. System displays a confirmation with the due date.

Alternate flows:

• A1 – Invalid member: at step 3, if the member ID is invalid, the system shows an error and aborts.
• A2 – Book unavailable: at step 3, if no copy is available, the system offers to reserve the book.
• A3 – Limit/fine exceeded: at step 4, if the limit is reached or a fine is pending, the system refuses and prompts to clear it first.

(a) Layered (n-tier) vs Client–Server Architecture

Layered (n-tier) Architectural Style

The system is organised into horizontal layers, each providing services to the layer above and using services of the layer below. A typical 3-tier stack is Presentation → Business Logic → Data Access (→ Database).

Advantages: clear separation of concerns; high maintainability and reusability; a layer can be changed without affecting others as long as interfaces are stable; supports portability.

Disadvantages: performance overhead from passing requests through layers; can be rigid; not every request maps cleanly onto layers (layer bridging).

Client–Server Architectural Style

Functionality is divided between clients that request services and one or more servers that provide them, communicating over a network.

Advantages: centralised data and control; easy to add clients (scalability); centralised security and backup; resource sharing.

Disadvantages: server is a single point of failure and potential bottleneck; network dependency; can be costly to manage.

(b) Architecture for a Web-based E-commerce Application

Proposed architecture: 3-tier MVC web architecture.

[ Browser / Client ]
        | HTTP/HTTPS
        v
[ Web/Presentation Tier ]  <-- View (HTML/CSS/JS) + Controller (request handling)
        |
        v
[ Application/Business Tier ] <-- Model (business logic: cart, orders, payments)
        |
        v
[ Data Tier ]  <-- Database (products, users, orders) + Payment Gateway API

Major components: Web/UI layer, Authentication module, Product Catalogue service, Shopping Cart, Order/Checkout service, Payment Gateway integration, and the Database.

How MVC improves maintainability:

• Model holds data and business rules (products, orders); View renders the UI; Controller handles user input and coordinates Model and View.
• This separation of concerns lets the UI change without touching business logic and vice versa.
• It enables parallel development (designers on Views, developers on Models), easier testing of the Model in isolation, and reuse of the same Model across multiple Views (web and mobile). The result is lower coupling and a more maintainable, extensible system.

(a) Basic COCOMO — Organic Mode

Given: size $S = 33.3$ KLOC, organic coefficients $a=2.4,\ b=1.05,\ c=2.5,\ d=0.38$.

Effort

$$E = a \times S^{\,b} = 2.4 \times (33.3)^{1.05}$$

Compute $33.3^{1.05}$: $\ln 33.3 = 3.5057$, so $1.05 \times 3.5057 = 3.6810$, and $e^{3.6810} \approx 39.69$.

$$E = 2.4 \times 39.69 \approx 95.3 \text{ person-months}$$

Development Time

$$T = c \times E^{\,d} = 2.5 \times (95.3)^{0.38}$$

Compute $95.3^{0.38}$: $\ln 95.3 = 4.5570$, so $0.38 \times 4.5570 = 1.7317$, and $e^{1.7317} \approx 5.65$.

$$T = 2.5 \times 5.65 \approx 14.1 \text{ months}$$

Average Staffing

$$N = \frac{E}{T} = \frac{95.3}{14.1} \approx 6.8 \approx 7 \text{ persons}$$

Results: Effort $\approx 95.3$ person-months, Development time $\approx 14.1$ months, Average staff $\approx 7$ persons.

(b) Size-oriented vs Function-oriented Estimation; COCOMO Limitations

Size-oriented vs Function Point

• Size-oriented estimation measures size in Lines of Code (LOC/KLOC) and derives productivity metrics (e.g. LOC per person-month). It is simple but language-dependent and hard to estimate before coding.
• Function-oriented (Function Point) estimation measures size by functionality delivered — counting external inputs, outputs, inquiries, internal logical files and external interface files, adjusted by complexity factors. It is language-independent and can be applied early from the specification, but is more subjective to count.

Two Limitations of COCOMO

1. It depends on a reliable estimate of size (LOC), which is itself very hard to predict accurately early in the project, so errors propagate into the effort estimate.
2. Basic COCOMO ignores many cost drivers (team capability, tool use, reliability requirements, etc.) and is calibrated on historical projects, so it may not fit modern or organisation-specific projects without re-calibration.

(a) Black-box vs White-box Testing

(b) Control Flow Graph, Cyclomatic Complexity, Independent Paths

Control Flow Graph (described):

        (1) if (a > b)?
        /            \
  (2) x=a-b      (3) x=b-a
        \            /
        (4) while (x>0)?
         |  \
         |   \ (false) -> (6) end
   (true)|
        (5) x=x-1  --back to (4)

Nodes: 1 = if-decision, 2 = then, 3 = else, 4 = while-decision, 5 = loop body, 6 = exit. Edges: 1→2, 1→3, 2→4, 3→4, 4→5, 5→4, 4→6.

Cyclomatic Complexity: Using $V(G) = E - N + 2$ with $E = 7$ edges and $N = 6$ nodes:

$$V(G) = 7 - 6 + 2 = 3$$

Equivalently, $V(G) = \text{number of predicate nodes} + 1 = 2 + 1 = 3$ (decisions at nodes 1 and 4).

Independent paths (3):

1. 1 → 2 → 4 → 6 (a > b, loop not entered)
2. 1 → 3 → 4 → 6 (a ≤ b, loop not entered)
3. 1 → 2 → 4 → 5 → 4 → 6 (loop body executed)

(a) Software Configuration Management (SCM) and Baseline

Software Configuration Management (SCM) is the discipline of identifying, organising and controlling changes to the work products (configuration items) of a software project throughout its life cycle. Its goal is to maintain integrity and traceability so that changes are systematic and the state of the product is always known.

A baseline is a formally reviewed and agreed-upon version of a configuration item (e.g. an approved SRS or a released build) that thereafter serves as the basis for further work and can only be changed through the formal change control process.

(b) Change Control Process

The change control process manages modifications to configuration items so that changes are evaluated and approved before being implemented:

1. Change request is submitted describing the proposed modification.
2. Evaluation / impact analysis — assess the technical and cost/schedule impact and risk.
3. Review by the Change Control Board (CCB) — the CCB is a group of stakeholders that reviews the request and approves or rejects it, balancing benefit against impact.
4. Implementation — if approved, the item is checked out, modified, reviewed and tested.
5. Check-in and new baseline — the changed item is checked back in and a new baseline / version is recorded.
6. Closure — the change request is closed and stakeholders are notified.

The CCB's role is to ensure that only justified, properly evaluated changes are made, preventing uncontrolled (ad-hoc) modifications.

(a) SQA vs SQC

• Software Quality Assurance (SQA) is a process-oriented, preventive set of activities that defines and audits the processes and standards used to build software, ensuring quality is built in (e.g. defining standards, process audits, reviews). It asks "are we doing the right process?"
• Software Quality Control (SQC) is a product-oriented, detective set of activities that examines the actual work products to find defects (e.g. testing, inspections of the product). It asks "is the product correct?"

In short: SQA prevents defects by improving the process; SQC detects defects in the product.

(b) Five Maturity Levels of CMMI

1. Initial — processes are ad-hoc, unpredictable and reactive; success depends on individuals.
2. Managed — projects are planned, measured and controlled at the project level (basic project management).
3. Defined — processes are documented, standardised and tailored as organisation-wide standard processes.
4. Quantitatively Managed — processes are measured and controlled using statistical/quantitative techniques.
5. Optimizing — focus on continuous process improvement through incremental and innovative changes.

(a) Coupling and Cohesion

• Coupling is the degree of interdependence between modules — how strongly one module relies on others. It is an inter-module measure.
• Cohesion is the degree to which the elements within a single module belong together and contribute to one well-defined task. It is an intra-module measure.

Why low coupling and high cohesion are desirable:

• Low coupling means modules are largely independent, so a change in one module has little ripple effect on others — improving maintainability, testability and reusability.
• High cohesion means each module does one well-defined job, making it easier to understand, test, reuse and modify.
• Together they produce modular, robust and maintainable designs.

(b) Two Types of Cohesion (with examples)

1. Functional cohesion (highest/best): all elements of the module work together to perform exactly one task. Example: a calculateSquareRoot(x) function that does nothing but compute and return the square root.
2. Logical cohesion (weak): the module groups elements that are logically related but perform different functions selected by a flag/parameter. Example: a single handleInput(type) routine that reads from keyboard, file, or network depending on a type argument.

(Other valid examples: sequential cohesion — output of one element is input to the next; coincidental cohesion (worst) — elements are grouped arbitrarily with no meaningful relationship.)

(a) Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a formal document that completely describes the functional and non-functional requirements, external interfaces and constraints of the software to be built. It serves as the agreement between the customer and the development team and as the basis for design, testing and validation.

Four characteristics of a good SRS:

1. Correct — every requirement stated is one the software must meet.
2. Complete — all significant requirements, responses and constraints are included.
3. Unambiguous — every requirement has only one interpretation.
4. Consistent — no requirement conflicts with another.

(Other valid characteristics: verifiable, modifiable, traceable, ranked for importance.)

(b) Three Requirements Elicitation Techniques

1. Interviews — structured or unstructured discussions with stakeholders to gather their needs and expectations directly.
2. Questionnaires/Surveys — distributing written questions to many stakeholders to collect requirements quickly over a large group.
3. Prototyping — building a quick, throw-away or evolutionary prototype so users can react to a tangible model, helping clarify unclear requirements. (Other valid: observation/ethnography, brainstorming, document/use-case analysis, JAD workshops.)

(a) Risk Management and its Process

Risk management is the systematic process of identifying, analysing and controlling risks — potential future events that could harm the project's cost, schedule or quality — so as to minimise their impact.

Steps of the risk management process:

1. Risk identification — discover possible risks (technical, project, business).
2. Risk analysis & assessment — estimate each risk's probability and impact, and prioritise them (e.g. risk exposure = probability × impact).
3. Risk planning (mitigation) — devise avoidance, transfer or contingency strategies for high-priority risks.
4. Risk monitoring & control — continuously track risks, watch for triggers, and update plans as the project proceeds.

(b) Gantt Chart vs PERT Chart

In short, a Gantt chart is best for scheduling and tracking while a PERT chart is best for analysing dependencies and the critical path.

Levels of Testing

1. Unit Testing — tests the smallest testable components (functions, classes, modules) in isolation. Purpose: verify that each unit behaves correctly on its own; usually done by developers using stubs/drivers.
2. Integration Testing — combines individual units and tests them together. Purpose: detect defects in the interfaces and interactions between modules.
3. System Testing — tests the complete, integrated system against the specified requirements in an environment resembling production. Purpose: validate functional and non-functional behaviour of the whole system.
4. Acceptance Testing — performed by or for the customer/end user. Purpose: confirm the system meets business needs and is acceptable for delivery (includes alpha/beta and UAT).

Top-down vs Bottom-up Integration Testing

• Top-down integration: integration starts from the top (main control) module and proceeds downward, integrating subordinate modules step by step. Missing lower modules are replaced by stubs. Advantage: major control logic is tested early.
• Bottom-up integration: integration starts from the lowest-level modules, which are combined into clusters and tested upward toward the main module. Missing higher modules are replaced by drivers. Advantage: low-level utility modules are validated early.

In top-down testing we need stubs (placeholders for called modules), whereas in bottom-up testing we need drivers (placeholders for calling modules).

(a) Four Core Values of the Agile Manifesto

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

(While there is value in the items on the right, Agile values the items on the left more.)

(b) The Scrum Framework

Scrum is an iterative, incremental Agile framework that delivers software in fixed-length iterations called sprints.

Roles:

• Product Owner — owns and prioritises the Product Backlog, representing the customer/business value.
• Scrum Master — facilitates the process, removes impediments, and coaches the team on Scrum.
• Development Team — a self-organising, cross-functional team that builds the increment.

Artifacts:

• Product Backlog — the ordered list of all desired features/requirements.
• Sprint Backlog — the subset of backlog items selected for the current sprint plus the plan to deliver them.
• Increment — the potentially shippable, working product produced at the end of each sprint.

Sprint: a time-boxed iteration (typically 2–4 weeks) during which a usable, potentially releasable increment is created. Its purpose is to deliver working software at a steady cadence with predictable, inspectable progress. Each sprint includes sprint planning, the daily scrum (stand-up), the sprint review, and the sprint retrospective.