BE Computer Engineering (IOE, TU) Software Engineering (IOE, CT 601 / ENCT 352) Question Paper 2078 Nepal

(a) Waterfall vs. Spiral Model (6)

Most suitable conditions:

• Waterfall is best when requirements are clear, stable and well understood, the technology is familiar, the project is small to medium and short, and where strong documentation/traceability is mandated (e.g. defence or regulatory projects).
• Spiral is best for large, complex, high-risk projects where requirements are uncertain or evolving, where new technology is involved, and where the budget allows repeated risk analysis and prototyping.

(b) Recommended Model for the Examination Portal (6)

Because the requirements are likely to change frequently and the client wants working software delivered in increments, the Incremental / Agile (iterative) model (e.g. Scrum) is recommended rather than the rigid Waterfall.

Justification with reference to its phases:

1. Requirement gathering (per increment): Only the requirements for the current increment are detailed, so frequent changes are accommodated without re-doing the whole specification.
2. Design & build: A small, working slice of functionality (e.g. student registration, then online exam, then result publishing) is designed and coded in each iteration.
3. Testing & integration: Each increment is tested and integrated with previously delivered increments, producing a shippable working product early.
4. Delivery & feedback: The client uses each increment and provides feedback, which feeds the requirements of the next iteration — directly satisfying the demand for incremental delivery.
5. Iteration: The cycle repeats until all features are delivered.

This model gives early and continuous delivery of working software, easy accommodation of changing requirements, and continuous client involvement, exactly matching the portal's needs. (The Spiral model would also handle changing requirements but is heavier and risk-focused; for incremental working-software delivery, Incremental/Agile is the better fit.)

(a) Context-Level (Level-0) DFD (5)

A context diagram models the whole Library Management System (LMS) as a single process and shows the external entities (terminators) and the major data flows between them.

Description of the diagram (drawn as one bubble in the centre):

          search request / book details
  Member ----------------------------->  +-------------------------+
         <-----------------------------  |                         |
          search results / due info      |   0.                    |
                                         |  Library Management     |
         issue/return request            |     System              |
  Member ----------------------------->  |                         |
         <-----------------------------  |                         |
          confirmation                   +-------------------------+
                                              ^            |
  Librarian  catalogue updates / queries      |            | reports / catalogue data
            --------------------------------->-+            v
            <----------------------------------         (to Librarian)

Components:

• Process (circle/bubble, numbered 0): the entire LMS, the single transformation in a context diagram.
• External entities (rectangles): Member and Librarian — sources/sinks of data outside the system boundary.
• Data flows (arrows): labelled movements of data, e.g. search request, search results, issue/return request, confirmation, catalogue update, reports.
• There are no data stores shown at Level 0; they appear only when the process is decomposed to Level 1.

(b) Entity-Relationship Diagram (5)

Main entities and attributes:

• Member (MemberID, Name, Address, Phone)
• Book (BookID/ISBN, Title, Author, Subject, Copies)
• Librarian (StaffID, Name)
• Loan/Issue (associative entity: IssueID, IssueDate, DueDate, ReturnDate)

Relationships and cardinalities:

[Member] ===<Borrows>=== [Book]      (M:N, resolved via Loan)
   1                          M
   |                          |
   +----< Loan >--------------+        Member 1 -- M Loan ;  Book 1 -- M Loan

[Librarian] ==<Manages>== [Book]       (1:N : one librarian manages many catalogue entries)

• Member — Loan: one member can have many loans -> 1:N.
• Book — Loan: one book (title) can appear in many loans -> 1:N.
• (Hence Member — Book is conceptually M:N, resolved by the Loan associative entity.)
• Librarian — Book: one librarian manages many catalogue entries -> 1:N.

Entities are drawn as rectangles, relationships as diamonds, attributes as ellipses, with cardinality markings (1, M, N) on the connecting lines.

(c) Functional vs. Non-Functional Requirements (2)

• Functional requirements describe what the system must do (services/behaviour). Examples: the system shall allow a member to search a book by title/author; the system shall let a member issue and return a book.
• Non-functional requirements describe how well / under what constraints the system operates (quality attributes). Examples: a search shall return results within 2 seconds; the system shall be available 24x7 and support at least 100 concurrent users securely.

(a) Three Modes of Basic COCOMO (4)

The Basic COCOMO model classifies projects into three modes based on size, team experience and constraints:

(b) Estimation for 33.3 KLOC, Semi-detached (6)

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

Step 1 — Effort:

$$E = a \times (\text{KLOC})^{b} = 3.0 \times (33.3)^{1.12}$$ $$(33.3)^{1.12} = e^{1.12 \ln 33.3} = e^{1.12 \times 3.5057} = e^{3.926} \approx 50.7$$ $$E = 3.0 \times 50.7 \approx \mathbf{152.2\ person\text{-}months}$$

Step 2 — Development time:

$$T_{dev} = c \times (E)^{d} = 2.5 \times (152.2)^{0.35}$$ $$(152.2)^{0.35} = e^{0.35 \ln 152.2} = e^{0.35 \times 5.025} = e^{1.759} \approx 5.81$$ $$T_{dev} = 2.5 \times 5.81 \approx \mathbf{14.5\ months}$$

Step 3 — Average staffing:

$$\text{Staff} = \frac{E}{T_{dev}} = \frac{152.2}{14.5} \approx \mathbf{10.5 \approx 11\ persons}$$

Results: Effort $\approx 152$ PM, Development time $\approx 14.5$ months, Average staff $\approx 10\text{–}11$ people.

(c) Two Limitations of COCOMO (2)

1. It depends on an accurate estimate of KLOC (lines of code), which is very hard to predict reliably at the start of a project.
2. It ignores many real factors (e.g. requirement volatility, customer skill, hardware constraints in the basic version) and is calibrated on historical project data that may not match a new project, so estimates can be inaccurate.

(a) Software Architecture and Architectural Styles (7)

Software architecture is the high-level structure of a software system — the set of its principal components/modules, their externally visible properties, and the relationships (connectors) and constraints among them. It defines how the system is organised and provides a blueprint that satisfies functional and quality (non-functional) requirements.

Three architectural styles:

1. Layered (n-tier) architecture Components are organised into horizontal layers; each layer provides services to the layer above and uses the layer below.

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

Eases maintenance and portability; a change in one layer affects only the adjacent interface.

2. Client–Server architecture A central server provides services/resources to multiple clients that send requests over a network.

[Client 1] \
[Client 2]  ---requests--->  [   Server   ] ---> [Database]
[Client 3] /  <--responses--

Supports centralised data and many distributed users (e.g. web applications).

3. Pipe-and-Filter architecture Data flows through a series of processing components (filters) connected by pipes; each filter transforms its input stream and passes it on.

[Source] -->(pipe)--> [Filter A] -->(pipe)--> [Filter B] -->(pipe)--> [Sink]

Each filter is independent and reusable (e.g. a Unix command pipeline or a compiler's lexer->parser->codegen).

(Repository style — components share a central data store/blackboard — is an acceptable alternative.)

(b) Black-box vs. White-box Testing & Test Levels (5)

Levels of testing:

• Unit testing tests the smallest individual components (a single module/function/class) in isolation, usually by the developer, often with stubs/drivers.
• Integration testing tests the interfaces and interactions between combined units/modules to find errors in how they work together (e.g. top-down, bottom-up, or sandwich integration). It sits between unit and system testing.
• System testing tests the complete, integrated system as a whole against the overall functional and non-functional requirements in a production-like environment.

In short: unit -> verifies a part; integration -> verifies parts working together; system -> verifies the whole product.

Requirement Engineering Process

Requirement engineering is the systematic process of discovering, documenting and maintaining the requirements for a system. Its main activities are:

1. Feasibility study — assess whether the system is technically, operationally and economically viable.
2. Requirement elicitation & analysis — gather requirements from stakeholders (interviews, questionnaires, observation, use cases) and analyse them for conflicts and priorities.
3. Requirement specification — document the agreed requirements formally in a Software Requirements Specification (SRS), separating functional and non-functional requirements.
4. Requirement validation — check that the documented requirements are correct, complete and consistent.
5. Requirement management — control changes to requirements throughout the project (traceability).

Importance of Requirement Validation

Validation is important because errors in requirements are the most expensive to fix if they reach later phases (design, coding or after release). Validation ensures the SRS is correct, complete, consistent, unambiguous, feasible and verifiable, so the team builds the right product and avoids costly rework.

Validation Techniques

• Requirement reviews / inspections — a team systematically reads the SRS to find errors and omissions.
• Prototyping — build an executable model and let users confirm requirements.
• Test-case generation — derive tests from each requirement; if a test cannot be written, the requirement is poorly stated.
• Requirement checklists / consistency checking — verify against a checklist of quality criteria (completeness, consistency, ambiguity).

Coupling and Cohesion

• Coupling is the degree of interdependence between modules — how strongly one module relies on others. Low (loose) coupling is desirable.
• Cohesion is the degree to which the elements inside a single module belong together and serve one well-defined purpose. High cohesion is desirable.

Types of Coupling (worst -> best)

1. Content coupling — one module directly modifies or relies on the internals of another (worst).
2. Common coupling — modules share global data.
3. Control coupling — one module controls another's behaviour by passing a control flag.
4. Stamp coupling — a whole data structure is passed when only part is needed.
5. Data coupling — modules communicate only through simple parameters (best/loosest).

Types of Cohesion (worst -> best)

1. Coincidental — elements grouped arbitrarily (worst).
2. Logical — elements do similar kinds of work, selected by a flag.
3. Temporal — elements executed at the same time (e.g. initialisation).
4. Procedural — elements follow a sequence of execution.
5. Communicational — elements operate on the same data.
6. Sequential — output of one element is input to the next.
7. Functional — all elements contribute to a single well-defined task (best).

Relation to Good Modular Design

A good modular design aims for high cohesion and low coupling. High cohesion makes each module simple, focused and reusable; low coupling makes modules independent, so changes in one module have minimal ripple effects on others. Together they improve maintainability, testability, reusability and understandability.

Test Case

A test case is a documented set of inputs, execution conditions and expected results designed to verify a specific requirement or feature of the software. It typically includes a test-case ID, input data, preconditions, the expected output and the actual result.

Test Design for marks in range 0–100

Valid range: 0 to 100 (inclusive). Anything below 0 or above 100 is invalid.

Equivalence Partitioning (EP)

Divide inputs into classes; one representative test per class.

Boundary Value Analysis (BVA)

Test at and just around the boundaries (min−1, min, min+1, max−1, max, max+1).

BVA is effective because most defects cluster at the edges of input ranges, while EP reduces the total number of tests by treating each class as equivalent.

Software Configuration Management (SCM)

SCM is the discipline of identifying, organising and controlling changes to the artefacts (code, documents, designs, test data) produced during the software lifecycle, so that the integrity and traceability of the product are maintained throughout development and maintenance. Its key activities are configuration identification, version control, change control, configuration auditing and status reporting.

Version Control

Version control manages multiple versions/revisions of configuration items. It records every change, allows several developers to work concurrently (branching and merging), lets you retrieve any previous version, and prevents one developer's changes from overwriting another's (using tools such as Git, SVN, CVS).

Change Control

Change control is the formal procedure for handling change requests to baselined items. A typical flow is: submit change request -> evaluate impact -> approval/rejection by a Change Control Board (CCB) -> implement -> test -> update baseline and records. This ensures changes are made in a controlled, traceable manner.

Role of a Baseline

A baseline is a formally reviewed and agreed-upon configuration item (or set of items) that thereafter serves as the basis for further development and can be changed only through formal change control. Baselines (e.g. requirement baseline, design baseline) provide stable reference points, control the ripple effect of changes, and enable measurement of progress.

(a) Verification vs. Validation (3)

(b) Four Types of Software Maintenance (3)

1. Corrective maintenance — fixing detected faults/bugs. Example: correcting a wrong total in a payroll report.
2. Adaptive maintenance — modifying software to keep it usable in a changed environment. Example: updating an app to run on a new OS version or a changed tax rate/regulation.
3. Perfective maintenance — enhancing functionality or performance based on user requests. Example: adding a new search filter or speeding up a slow query.
4. Preventive maintenance — changes made to prevent future problems and improve maintainability. Example: refactoring code and updating documentation to reduce future defects.

Risk Management in Software Projects

A risk is a potential future event that, if it occurs, can adversely affect the project's cost, schedule or quality. Risk management is the proactive process of identifying, analysing and controlling risks before they become real problems, so their probability and impact are reduced.

(1) Risk Identification

Systematically discovering possible risks. Common categories include project risks (budget, schedule, staffing), technical risks (design, implementation, technology), and business risks (market, product viability). Techniques: checklists, brainstorming, reviewing past projects.

(2) Risk Projection (Estimation)

Assessing each identified risk by estimating:

• its probability/likelihood of occurring, and
• its impact/severity if it occurs.

Risks are then prioritised (e.g. using a risk table and an exposure value $RE = \text{probability} \times \text{impact}$) so the most significant risks get attention first.

(3) RMMM — Risk Mitigation, Monitoring and Management

• Mitigation: plan actions to reduce the probability or impact of a risk before it occurs (e.g. cross-train staff to reduce the impact of a key person leaving).
• Monitoring: continuously track risk indicators during the project to detect whether a risk is becoming more likely.
• Management: if a risk does materialise, execute the prepared contingency plan to limit damage.

The RMMM plan documents all these and is reviewed throughout the project.

Capability Maturity Model (CMM)

The CMM, developed by the SEI (Software Engineering Institute), is a framework that describes the maturity of an organisation's software process. It defines five evolutionary levels, each building on the previous one, that an organisation can climb to improve process capability and predictability.

The Five Maturity Levels

1. Level 1 — Initial: Process is ad hoc, chaotic and unpredictable; success depends on individual heroics. Few processes are defined.
2. Level 2 — Repeatable (Managed): Basic project-management processes are established (planning, tracking, configuration management); earlier successes can be repeated on similar projects.
3. Level 3 — Defined: The software process is documented, standardised and integrated into an organisation-wide standard process; all projects use a tailored version of it.
4. Level 4 — Managed (Quantitatively Managed): The process and product quality are measured quantitatively and controlled using metrics; performance is predictable.
5. Level 5 — Optimizing: Focus on continuous process improvement through quantitative feedback, innovation and defect prevention.

(Answering any two as required.)

(a) Software Quality Attributes (ISO 9126)

ISO 9126 is an international standard that defines a model for software product quality through six main characteristics:

1. Functionality — does it provide the required functions (suitability, accuracy, security, interoperability)?
2. Reliability — maturity, fault tolerance, recoverability.
3. Usability — understandability, learnability, operability.
4. Efficiency — time behaviour and resource utilisation.
5. Maintainability — analysability, changeability, testability, stability.
6. Portability — adaptability, installability, replaceability across environments.

Each characteristic is broken into measurable sub-characteristics used to assess product quality.

(b) Formal Technical Reviews (FTR)

A Formal Technical Review is a planned, structured quality-assurance activity in which a small team of technical staff examines a work product (requirements, design or code) to find errors early, before they propagate to later phases. Characteristics: 3–5 participants, advance preparation, a meeting of 1–2 hours, defined roles (author, reviewer, recorder, moderator), and a review report listing issues. Walkthroughs and inspections are common forms. Benefits: early defect detection, knowledge sharing and improved quality at low cost.

(c) Reverse Engineering and Re-engineering

• Reverse engineering is the process of analysing existing software to recover its design, structure and specifications (extracting higher-level abstractions from code), typically when documentation is missing. It is an examination, not modification process.
• Re-engineering is restructuring or rewriting existing (legacy) software to improve its quality, maintainability or to migrate it to new technology, without changing its essential functionality. It usually involves reverse engineering to understand the system, then forward engineering to rebuild it.