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

(a) Waterfall Model and Spiral Model (8)

Waterfall Model

The Waterfall model is a linear, sequential process where each phase must be completed before the next begins, and the output of one phase flows like a waterfall into the next. Its phases are:

1. Requirements analysis and definition – capture and document all requirements in an SRS.
2. System and software design – establish overall architecture and detailed design.
3. Implementation and unit testing – code modules and test them individually.
4. Integration and system testing – combine units and test the complete system.
5. Operation and maintenance – deploy, then fix defects and add enhancements.

Characteristics: simple, well-documented, but rigid — it assumes requirements are fully known up front and provides no working software until late, so changes are expensive.

Spiral Model

The Spiral model (Boehm) is a risk-driven, iterative model that combines prototyping with the systematic aspects of the waterfall. Development proceeds in repeated loops (spirals); each loop is divided into four quadrants:

1. Determine objectives, alternatives, and constraints.
2. Identify and resolve risks – evaluate alternatives, build prototypes, perform analysis.
3. Develop and verify the next-level product (design, code, test).
4. Plan the next iteration and obtain stakeholder review/commitment.

Each spiral produces an increasingly complete version of the system. The defining feature is explicit risk analysis at every iteration.

(b) Recommended model for the project (6)

For a large, safety-critical project with poorly understood requirements and high risk of failure, the Spiral model is recommended.

• Risk handling: The Spiral model performs explicit risk identification and resolution in every loop, which is essential for safety-critical systems where the cost of failure is severe.
• Evolving requirements: Because requirements are not fully understood, prototyping within each spiral lets users and developers refine and validate requirements incrementally, rather than committing to them up front as the Waterfall demands.
• Early feedback: Stakeholders review the product at the end of each iteration, allowing course-correction before large sums are committed.
• Why not Waterfall: The Waterfall model is rigid, assumes stable, fully-known requirements, and defers integration/testing to the end — making it unsuitable when requirements are unclear and failure risk is high.

Conclusion: The Spiral model's iterative, risk-managed approach directly addresses both the requirement uncertainty and the high failure risk of this project.

(a) Requirement Engineering activities for the Hospital Management System (6)

The requirement engineering process consists of the following major activities:

1. Feasibility study – Assess whether the HMS (registration, appointments, billing, pharmacy) is technically, economically and operationally viable for the hospital.
2. Requirements elicitation and analysis – Gather needs from stakeholders (doctors, receptionists, patients, pharmacists, administrators) through interviews and observation; e.g., how appointments are booked, how bills are generated, how stock is tracked. Analyse and resolve conflicts.
3. Requirements specification – Document the agreed requirements in a formal SRS (e.g., "the system shall schedule appointments and avoid double-booking a doctor").
4. Requirements validation – Check that the documented requirements are complete, consistent, and truly reflect stakeholder needs through reviews and prototyping.
5. Requirements management – Control and trace changes to requirements throughout the project lifecycle.

(b) Functional vs Non-functional Requirements (4)

Functional examples (HMS):

• The system shall register a new patient and generate a unique patient ID.
• The system shall schedule a doctor appointment and prevent double-booking.

Non-functional examples (HMS):

• The system shall generate a patient bill within 3 seconds (performance).
• Patient medical records shall be accessible only to authorised staff (security).

(c) Use-case diagram for Appointment Scheduling (4)

Description of the diagram: A rectangle labelled "Appointment Scheduling System" contains the use-case ovals; actors are stick figures placed outside, connected by association lines.

        +-------------------- Appointment Scheduling System --------------------+
        |                                                                       |
        |   ( Book Appointment )      ( Cancel Appointment )                     |
Patient-|----                                                                   |
  (o)   |    \______ ( View Available Slots )                                   |
        |                                                                       |
        |   ( Confirm/Reschedule Appointment )                                  |
Doctor--|------------------                                                     |
  (o)   |                  \____ ( View Appointment Schedule )                  |
        |                                                                       |
        +-----------------------------------------------------------------------+

• Actors (2): Patient, Doctor (optionally Receptionist).
• Use cases (4+): Book Appointment, Cancel Appointment, View Available Slots, Confirm/Reschedule Appointment, View Appointment Schedule.
• Patient associates with Book/Cancel/View Slots; Doctor associates with Confirm/Reschedule and View Schedule.

(a) Basic COCOMO computation (7)

For semi-detached projects the Basic COCOMO formulas are:

$$\text{Effort } E = a \times (\text{KLOC})^{b} \quad\text{person-months}$$ $$\text{Development time } T_{dev} = c \times (E)^{d} \quad\text{months}$$

Given $a = 3.0,\; b = 1.12,\; c = 2.5,\; d = 0.35$ and $\text{KLOC} = 33.3$.

Effort:

$$E = 3.0 \times (33.3)^{1.12} = 3.0 \times 50.715 \approx \mathbf{152.15 \text{ person-months}}$$

Development time:

$$T_{dev} = 2.5 \times (152.15)^{0.35} = 2.5 \times 5.805 \approx \mathbf{14.51 \text{ months}}$$

Average staffing (bonus):

$$N = \frac{E}{T_{dev}} = \frac{152.15}{14.51} \approx 10.5 \text{ persons}$$

Result: Effort ≈ 152 person-months, Development time ≈ 14.5 months, requiring about 10–11 people.

(b) Limitations of COCOMO and the Intermediate model (5)

Limitations of Basic COCOMO:

• It estimates effort only from program size (KLOC) and the project class, ignoring other influential factors.
• It does not account for the quality of personnel, tools, hardware constraints, reliability requirements, or product complexity.
• Accurate KLOC is hard to estimate early in a project, so estimates can be unreliable.
• It gives a single rough figure and tends to be inaccurate for many real projects.

How Intermediate COCOMO improves it: Intermediate COCOMO refines the estimate by multiplying the nominal effort by an Effort Adjustment Factor (EAF) derived from 15 cost drivers grouped into product, hardware, personnel, and project attributes (e.g., required reliability, database size, analyst capability, use of software tools).

$$E = a \times (\text{KLOC})^{b} \times EAF$$

Each cost driver is rated (very low → extra high) and contributes a multiplier; their product gives the EAF. This makes estimates more accurate and project-specific than Basic COCOMO by capturing factors other than raw size.

(a) Three architectural styles (9)

1. Layered (Abstract Machine) Architecture

The system is organised into a stack of layers, each providing services to the layer above and using services of the layer below. Communication is restricted to adjacent layers, which gives strong separation of concerns and portability.

+-------------------------------+
|  Presentation / UI layer      |
+-------------------------------+
|  Application / Business logic |
+-------------------------------+
|  Data access layer            |
+-------------------------------+
|  Database / OS layer          |
+-------------------------------+

Use: enterprise and OSI network systems. Pro: maintainable, replaceable layers. Con: performance overhead from passing through layers.

2. Client-Server Architecture

Functionality is split between servers that provide services and clients that request them over a network. Multiple clients share one or more servers.

  [Client 1] \
  [Client 2] --->  ( Network )  ---> [ Server: DB / Application ]
  [Client 3] /

Use: web applications, email, banking. Pro: centralised data, scalable. Con: server is a bottleneck / single point of failure.

3. Repository (Data-centred) Architecture

All sub-systems share data through a central data store (repository); components do not communicate directly but read from and write to the repository.

      [ Tool A ]    [ Tool B ]
           \          /
            v        v
         +---------------+
         |  Central      |
         |  Repository   |
         |  (shared data)|
         +---------------+
            ^        ^
           /          \
      [ Tool C ]    [ Tool D ]

Use: IDEs, CASE tools, DBMS-backed systems. Pro: central, consistent data; easy to add components. Con: repository is a single point of failure and can be a performance bottleneck.

(Pipe-and-Filter alternative: data flows through a sequence of independent filters connected by pipes, each transforming its input — e.g. a Unix command pipeline or a compiler.)

(b) Client-Server: one advantage and one disadvantage (3)

• Advantage: Data and management are centralised on the server, giving consistent, secure, shared access and making it easy to add new clients (good scalability).
• Disadvantage: The server is a single point of failure / performance bottleneck; if it goes down or is overloaded, all clients are affected, and network dependence adds latency.

(a) Software Requirements Specification (SRS) (4)

An SRS is a formal document that completely describes the functional and non-functional requirements of a software system. It acts as the agreed contract between the customer and the development team and serves as the basis for design, development, testing, and validation.

Four characteristics of a good SRS:

1. Complete – covers all functional and non-functional requirements and responses to all inputs.
2. Consistent – contains no conflicting or contradictory requirements.
3. Unambiguous – every requirement has exactly one interpretation.
4. Verifiable / Traceable – each requirement can be tested, and can be traced to its origin and to design/test artefacts. (Also acceptable: correct, modifiable, ranked by importance.)

(b) Two requirement elicitation techniques (4)

1. Interviews – The analyst talks directly with stakeholders. Closed interviews use predefined questions; open interviews explore issues freely. Useful for understanding goals, expectations, and existing problems, but answers may be biased or incomplete.
2. Prototyping – A quick, partial working model of the system is built and shown to users so they can react to something concrete. This is especially valuable when requirements are unclear, helping uncover hidden and changing requirements. (Other acceptable techniques: brainstorming, questionnaires/surveys, observation/ethnography, use-case workshops, JAD sessions.)

(a) Black-box vs White-box testing (4)

(b) Basis path testing and cyclomatic complexity (4)

The condition if ((a > 0) AND (b < 10)) evaluates two simple predicates joined by AND. Each simple condition is treated as a separate decision node in the control-flow graph (CFG).

Cyclomatic complexity (number of independent paths):

$$V(G) = P + 1$$

where $P$ = number of predicate (decision) nodes. Here the two atomic conditions a > 0 and b < 10 are two predicates, so:

$$V(G) = 2 + 1 = \mathbf{3}$$

Thus 3 linearly independent paths must be exercised. Deriving test cases (basis paths):

1. a > 0 is false → AND short-circuits, body skipped. (e.g. a = -1, b = 5)
2. a > 0 true, b < 10 false → body skipped. (e.g. a = 2, b = 15)
3. a > 0 true, b < 10 true → body executed. (e.g. a = 2, b = 5)

These three test cases cover all independent paths and guarantee every branch of the compound condition is exercised. (If the compound condition is treated as a single decision, $V(G) = 1 + 1 = 2$ with one true and one false path — state your assumption.)

(a) Coupling and Cohesion (4)

• Coupling is the degree of interdependence between modules — how strongly one module relies on others. It ranges from loose (data coupling) to tight (content coupling).
• Cohesion is the degree to which the elements within a single module belong together and contribute to a single, well-defined task. It ranges from low (coincidental) to high (functional cohesion).

Why low coupling and high cohesion are desirable:

• Low coupling means modules are independent, so a change in one module has little impact on others — this improves maintainability, reusability, and testability.
• High cohesion means each module does one focused job, making it easier to understand, test, and reuse.

Together they produce a modular, robust, and maintainable design.

(b) DFD vs Structure Chart (4)

Example (Library System):

• A DFD would show: Member → Issue Book process ← Book Store, with the issued-book record flowing to a Loan data store — i.e., the movement of data.
• A Structure Chart for the same system would show a top "Library Management" module calling sub-modules Issue Book, Return Book, Search Catalogue, with parameters (e.g., book-id, member-id) passed between them — i.e., the call hierarchy.

In short, a DFD models data movement, whereas a structure chart models module organisation and control.

(a) Software Configuration Management and Baselines (4)

Software Configuration Management (SCM) is the discipline of systematically controlling and tracking changes to software artefacts (configuration items such as code, documents, designs, and test plans) throughout the software lifecycle. Its main activities are configuration identification, change control, version control, configuration status accounting, and configuration audit. SCM ensures the integrity and traceability of the product as it evolves.

Role of a baseline: A baseline is a formally reviewed and agreed-upon version of a configuration item (or set of items) that serves as a stable reference point for further development. Once a baseline is established, it can be changed only through the formal change-control process. Baselines (e.g., requirements baseline, design baseline, product baseline) provide control, allow safe parallel work, and let the team measure and manage change against a known reference.

(b) Change Control Process (4)

The change control process manages modifications to configuration items in a disciplined way:

1. Change request submission – a developer or user files a Change Request (CR) describing the proposed change and its reason.
2. Evaluation / impact analysis – the Change Control Board (CCB) assesses the technical merit, cost, schedule, and impact on other items.
3. Decision – the CCB approves or rejects the request; the decision is recorded.
4. Implementation – if approved, the relevant item is checked out, modified, reviewed, and tested.
5. Verification and check-in – the change is verified, the item is checked back in under version control, and a new baseline/version is created.
6. Status accounting – the change and its status are recorded and reported to all stakeholders.

This controlled flow ensures changes are deliberate, traceable, and do not compromise system integrity.

(a) Quality Assurance vs Quality Control (4)

In short, QA builds quality into the process so defects are avoided, while QC checks the finished product to find defects already present.

(b) CMM and its five maturity levels (4)

The Capability Maturity Model (CMM) is a framework (developed by the SEI) that describes the maturity of an organisation's software processes and provides a path for continuous process improvement. Higher maturity correlates with greater predictability, quality, and productivity.

Five maturity levels:

1. Initial – Process is ad-hoc and chaotic; success depends on individual effort. Unpredictable.
2. Repeatable (Managed) – Basic project management (cost, schedule, requirements tracking) is in place; successes can be repeated on similar projects.
3. Defined – Processes are documented, standardised, and integrated into an organisation-wide standard process.
4. Managed (Quantitatively Managed) – Process and product quality are measured quantitatively and controlled using metrics.
5. Optimizing – Continuous process improvement through quantitative feedback and innovative technologies; defects are proactively prevented.

(a) Prototyping model (4)

The prototyping model builds a quick, partial, working version (prototype) of the system early, which is shown to users to obtain feedback. Based on the feedback the prototype is refined iteratively until the requirements are clear, after which the final system is developed (the prototype may be evolved or thrown away).

Typical steps: gather initial requirements → build quick prototype → user evaluation → refine → finalise requirements/build product.

Two situations where it is most appropriate:

1. When the requirements are not clear / not fully understood and the customer cannot state them precisely at the outset.
2. When the system has significant user interaction (UI-heavy) and early user feedback on look-and-feel is valuable, or when exploring a new/risky technology.

(b) Requirement validation (4)

Requirement validation is the process of checking that the documented requirements truly reflect the customer's needs and that they are complete, consistent, unambiguous, realistic, and verifiable — confirming that the right system is being specified before design begins. It catches requirement errors early, when they are cheapest to fix.

Two techniques:

1. Requirements reviews / inspections – a team systematically examines the SRS against a checklist to find errors, omissions, and conflicts.
2. Prototyping – an executable model is shown to users so they can confirm the requirements behave as expected. (Other valid techniques: test-case generation, requirements/model validation, walkthroughs.)

(a) Gantt chart (4)

A Gantt chart is a horizontal bar chart that shows project activities against a timeline. Each activity is a bar whose position marks its start, length marks its duration, and overlaps show parallel work; milestones and dependencies can also be shown.

Sample (4 activities):

How it helps scheduling:

• Gives a clear visual timeline of when each task starts and ends.
• Shows parallel and dependent activities, helping allocate resources.
• Lets the manager track progress against plan and spot delays early.

(b) Verification vs Validation (4)

Examples:

• Verification: Reviewing the design document or code against the SRS to ensure it follows the specification (no execution needed).
• Validation: Running the finished software and performing user acceptance testing to confirm it actually meets the customer's needs.

Answer any two of the following.

(a) Integration testing strategies: Top-down vs Bottom-up (4)

Integration testing combines individual modules and tests them together to expose interface and interaction defects.

• Top-down integration: Testing starts from the top (main control) module and integrates downward following the control hierarchy. Lower modules not yet ready are replaced by stubs (dummy modules). Pro: major control logic and design flaws are found early. Con: stubs can be costly to write and low-level modules are tested late.
• Bottom-up integration: Testing starts from the lowest-level modules, which are combined into clusters and tested using driver modules that simulate the callers. Pro: low-level utilities are thoroughly tested early; no stubs needed. Con: the overall program does not exist as a whole until late, so high-level control errors surface late.

(Sandwich/hybrid integration combines both.)

(b) Regression testing (4)

Regression testing is the re-execution of existing test cases after the software has been changed (bug fix, enhancement, or new feature) to ensure that the modification has not introduced new defects or broken previously working functionality. It confirms that unchanged parts still behave correctly. Because it is repetitive, regression testing is a prime candidate for test automation, and a maintained regression test suite is run after every significant change or release.

(c) Software reliability and the MTBF metric (4)

Software reliability is the probability that software operates without failure for a specified period of time under stated conditions. It is a key non-functional quality attribute.

A common metric is MTBF (Mean Time Between Failures):

$$MTBF = MTTF + MTTR$$

where MTTF = Mean Time To Failure (average operating time before a failure) and MTTR = Mean Time To Repair (average time to fix and recover). A higher MTBF indicates more reliable software. Reliability is also expressed as availability:

$$\text{Availability} = \frac{MTTF}{MTTF + MTTR} \times 100\%$$