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

(a) Waterfall vs Spiral Model (8)

Other points: Waterfall is simple, document-driven and easy to manage for small/stable projects, but no working software is available until late. Spiral combines prototyping with the systematic nature of waterfall, but is costlier, needs risk-assessment expertise, and is overkill for small projects.

(b) Recommended model for evolving requirements + early working software (4)

Recommendation: an Incremental / Iterative model — specifically an Agile model (e.g., Scrum).

Justification:

• Requirements that evolve significantly cannot be frozen up front, so a plan-driven model like Waterfall is unsuitable.
• Agile/iterative development delivers software in short increments (sprints), so the customer sees working software early and frequently.
• Continuous customer collaboration and feedback after each increment let the team embrace changing requirements even late in development.
• Each increment is independently tested and potentially shippable, reducing risk and delivering business value sooner.

(The Spiral model would also handle evolving requirements and risk, but Agile better satisfies the early and frequent working software demand for a typical customer-facing project.)

(a) Requirements of the Library Management System (5)

Functional Requirements

• Member registration / management: add, update, view and deactivate members; issue membership IDs.
• Book issue: check availability and member eligibility (issue limit), record loan with due date.
• Book return: mark book returned, update availability, trigger fine calculation if overdue.
• Fine calculation: compute fine = rate per day x days overdue; record and accept payment.
• Online catalogue search: search/browse books by title, author, ISBN, subject and show availability status.

Non-Functional Requirements

• Performance: catalogue search results returned within ~2 seconds.
• Reliability/Availability: system available during library hours (e.g. 99% uptime) with data backup.
• Security: authentication and role-based access (member vs librarian); protect member data.
• Usability: simple, intuitive UI for members and staff.
• Scalability/Maintainability: support growing number of members/books; modular, easy to update.

(b) Data Flow Diagrams (7)

Context (Level-0) DFD

A single process "0 Library Management System" at the centre, with external entities and data flows:

        registration / search request           catalogue results / receipts
  [Member] ------------------------------>  ( 0 Library Management  ) ------> [Member]
           <------------------------------  (        System        )

  [Librarian] -- book/member updates -->    (                      )
              <-- reports / alerts ------    (                      )

• External entities: Member, Librarian.
• The single process exchanges request/response flows with each entity; no internal data stores shown at Level 0.

Level-1 DFD for Book Issue and Return

The single process is decomposed into sub-processes with data stores:

[Member] --issue request (book id, member id)--> ( 1.0 Issue Book )
                                                      |  reads/updates
                                                      v
                                          [D1 Book File] [D2 Member File] [D3 Loan File]
                                                      ^
[Member] --return (book id)----------------> ( 2.0 Return Book )--writes--> [D3 Loan File]
                                                      |
                                                      v overdue?
                                              ( 3.0 Calculate Fine ) --> [D4 Fine File] --fine notice--> [Member]

Flow description:

1. 1.0 Issue Book — validates member (D2) and book availability (D1), creates a loan record with due date in D3 Loan File, marks the book as issued.
2. 2.0 Return Book — looks up the loan in D3, marks the book available again in D1, and passes return date to fine calculation.
3. 3.0 Calculate Fine — if return date > due date, computes fine and stores it in D4 Fine File, sending a fine notice to the member.

(Data stores: D1 Book File, D2 Member File, D3 Loan File, D4 Fine File.)

(a) Layered (n-tier) Architecture (7)

The layered architecture organizes a system into a stack of horizontal layers, each providing services to the layer above and using services of the layer below. A typical 3-tier arrangement is:

1. Presentation layer — user interface, input/output.
2. Business/Application logic layer — processing rules, validation, workflow.
3. Data layer — persistent storage and database access.

Layers communicate only through well-defined interfaces, ideally only with the adjacent layer (closed-layer principle).

Advantages

• Separation of concerns / modularity — each layer has a focused responsibility.
• Maintainability & testability — a layer can be modified or replaced (e.g. swap the database) without affecting others, as long as the interface is unchanged.
• Reusability of lower layers across applications; supports parallel development.
• Portability — presentation can be changed without touching business logic.

Limitations

• Performance overhead — requests pass through multiple layers (the "sinkhole" anti-pattern when layers just pass data through).
• Rigidity — a change cutting across layers (e.g. adding one field) may require edits in every layer.
• Not ideal for highly scalable, real-time systems.

Appropriate domain: typical enterprise / web business applications such as banking, e-commerce or an ERP system, where UI, business rules and data are naturally separated.

(b) Black-box vs White-box Testing + Test Cases (5)

Black-box test cases for grade(score), score in 0-100

Assume grading: 0-39 = Fail, 40-59 = Pass, 60-79 = Good (B), 80-100 = Distinction (A), with invalid input outside 0-100.

Equivalence partitioning (one representative per valid/invalid class):

Boundary value analysis (values at the edges of each partition):

These cases exercise every class and every boundary of the input domain.

(a) Three modes of Basic COCOMO (4)

Basic COCOMO (Constructive Cost Model, Boehm) classifies projects into three modes based on size, team experience and constraints:

1. Organic — small teams, well-understood applications, familiar/stable requirements, relaxed constraints. Size typically up to ~50 KLOC (e.g. a simple inventory system). Coefficients a=2.4, b=1.05.
2. Semi-detached — intermediate size and complexity; mixed team experience, a blend of rigid and flexible requirements (e.g. a new OS utility, a DBMS). Coefficients a=3.0, b=1.12.
3. Embedded — large, complex projects with tight hardware/software/operational constraints and high reliability needs (e.g. avionics, real-time control systems). Coefficients a=3.6, b=1.20.

(b) Effort, time and staffing for a 40 KLOC organic project (8)

Given: KLOC = 40, organic, $a=2.4,\ b=1.05,\ c=2.5,\ d=0.38$.

Effort

$$E = a\,(KLOC)^{b} = 2.4 \times (40)^{1.05}$$

$40^{1.05} = e^{1.05 \ln 40} = e^{1.05 \times 3.6889} = e^{3.8734} \approx 48.08$

$$E = 2.4 \times 48.08 \approx 115.4 \text{ person-months}$$

Development time

$$D = c\,(E)^{d} = 2.5 \times (115.4)^{0.38}$$

$115.4^{0.38} = e^{0.38 \ln 115.4} = e^{0.38 \times 4.7485} = e^{1.8044} \approx 6.08$

$$D = 2.5 \times 6.08 \approx 15.2 \text{ months}$$

Average staffing

$$P = \frac{E}{D} = \frac{115.4}{15.2} \approx 7.6 \text{ persons}$$

Results: Effort $\approx$ 115 person-months, Development time $\approx$ 15.2 months, Average staff $\approx$ 7-8 persons.

A Software Requirements Specification (SRS) is a formal document that completely describes the functions, behaviour, constraints and external interfaces of the software to be developed. It acts as an agreement (contract) between the customer and the development team and is the basis for design, testing and validation.

Desirable characteristics of a good SRS (IEEE 830):

• Correct — every requirement stated is one the software actually must meet.
• Unambiguous — every requirement has only one interpretation.
• Complete — includes all functional, non-functional and interface requirements; no TBDs.
• Consistent — no requirement conflicts with another.
• Verifiable — each requirement can be tested/checked by a finite, cost-effective process.
• Modifiable — well structured (cross-referenced, not redundant) so changes are easy.
• Traceable — each requirement can be traced to its origin and forward to design/test.
• Ranked for importance and/or stability.

Software Configuration Management (SCM) is the discipline of systematically controlling and tracking changes to software work products (code, documents, models, test cases) throughout the software life cycle. Its key activities are configuration identification, change control, status accounting and configuration auditing, so that the integrity and traceability of the product are maintained.

Role of Baselines:

• A baseline is a formally reviewed and agreed-upon version of a work product (e.g. an approved SRS or design) that serves as a stable reference point for further work.
• Once an item is baselined, it can be changed only through a formal change-control procedure (raise change request, review/approve, implement, re-baseline). This prevents uncontrolled, ad-hoc changes and provides a known-good fallback.

Role of Version Control:

• A version control system (VCS) (e.g. Git, SVN) stores every revision of each work product, recording who changed what, when and why.
• It enables developers to retrieve any previous version, work concurrently on branches, merge changes, and resolve conflicts, while preserving a complete change history.

Together, baselines define controlled reference points and version control implements the mechanics of storing and managing successive versions, ensuring orderly, auditable management of change.

Verification vs Validation

V-Model of Testing:

The V-model arranges development phases on the left arm (going down) and corresponding testing phases on the right arm (going up), forming a "V". Each development phase has an associated test level planned at the same time:

 Requirements  ----------------------->  Acceptance Testing
   System Design  ------------------->  System Testing
     Architectural/HL Design  ----->  Integration Testing
       Module/Detailed Design  --->  Unit Testing
                    \  Coding  /

Mapping of test level to development phase:

• Unit testing verifies individual modules against the detailed (module) design.
• Integration testing verifies combined modules against the architectural / high-level design.
• System testing verifies the whole system against the system design / specification.
• Acceptance testing validates the product against the user requirements.

The V-model stresses that the left side is verification and the right side is validation, and that test planning starts early (in parallel with design), improving defect detection.

Software maintenance is the process of modifying a software product after delivery to correct faults, improve performance, or adapt it to a changed environment. It is the longest and most costly phase of the software life cycle.

Four types of maintenance:

1. Corrective maintenance — fixing defects/bugs discovered after release.

   • Example: fixing a crash that occurs when a user enters a negative quantity in an order form.

2. Adaptive maintenance — modifying software to keep it usable in a changed or new environment.

   • Example: updating an application to run on a new operating system version or a new tax/GST rate change imposed by the government.

3. Perfective maintenance — improving performance, maintainability or adding new functionality requested by users.

   • Example: adding a search filter feature or optimizing a slow report-generation query.

4. Preventive maintenance — making changes to prevent future problems and improve future maintainability (e.g. code refactoring, updating documentation).

   • Example: refactoring tangled code and adding comments to reduce the chance of future bugs (re-engineering for Y2K-style issues).

Coupling measures the degree of interdependence between modules — how much one module relies on the internals of another. Cohesion measures how strongly the elements within a single module belong together toward one well-defined purpose.

Why low coupling and high cohesion are desirable:

• Low coupling means modules are largely independent, so a change in one module has minimal ripple effect on others. This improves maintainability, testability, and reusability, and reduces the risk of introducing errors.
• High cohesion means each module does one thing well, making it easier to understand, test and reuse, and easier to locate functionality.
• Together they produce a modular design that is easier to develop, maintain and extend.

Example of a coupling type: Data coupling (good) — two modules communicate by passing only the simple data parameters they need (e.g. area(length, width)). Content coupling (worst) — one module directly modifies the internal data of another.

Example of a cohesion type: Functional cohesion (best) — every element of the module contributes to a single, well-defined task (e.g. a module that only computes a square root). Coincidental cohesion (worst) — elements grouped arbitrarily with no meaningful relationship.

Gantt Chart

A Gantt chart is a horizontal bar chart that lists tasks on the vertical axis against a calendar/time scale on the horizontal axis. The length and position of each bar show a task's start, duration and end; bars can be shaded to show progress.

Task          | W1 | W2 | W3 | W4 | W5 |
Requirements  |####|    |    |    |    |
Design        |    |####|####|    |    |
Coding        |    |    |####|####|    |
Testing       |    |    |    |    |####|

• Advantage: simple and intuitive; at a glance it shows the schedule, task durations and current progress/overlap, making it ideal for monitoring and communicating status.

Network (PERT/CPM) Diagram

A network diagram represents tasks as nodes/arrows connected by dependency links, showing the sequence and precedence of activities. By computing earliest/latest times it identifies the critical path (the longest path = minimum project duration) and the slack/float of each task.

      A(3)        C(4)
  () ------> () ------> ()   ----> ()
     \ B(2)        D(5) /
      ----------> () --
  Critical path = longest chain of dependent tasks

• Advantage: explicitly shows task dependencies and the critical path, so managers know which tasks must not slip and where slack exists — excellent for analysing the effect of delays.

Summary: Gantt charts are best for tracking schedule and progress over time; PERT/CPM networks are best for analysing dependencies and identifying critical activities.

Capability Maturity Model Integration (CMMI) is a process-improvement framework (from the SEI) that provides organizations with the essential elements of effective software processes. It assesses and guides the maturity of an organization's processes on a five-level staged scale; higher levels indicate more disciplined, predictable and continuously improving processes.

Five maturity levels:

1. Initial — processes are ad-hoc, chaotic and unpredictable; success depends on individual effort and heroics.
2. Managed (Repeatable) — basic project management processes (planning, tracking, requirements and configuration management) are established; successes can be repeated on similar projects.
3. Defined — processes are documented and standardized across the organization into a standard process; projects tailor it.
4. Quantitatively Managed — processes are measured and controlled using quantitative/statistical data; performance is predictable.
5. Optimizing — focus on continuous process improvement through quantitative feedback and piloting innovative ideas; defect prevention and process refinement.

How it helps: By moving up the levels an organization replaces unpredictable, person-dependent work with measured, standardized and continuously improving processes, leading to better quality, lower cost, predictable schedules and reduced project risk.

(Answer any TWO.)

(a) Use-case diagram

A use-case diagram is a UML behavioural diagram that captures the functional requirements of a system from the user's viewpoint. Its elements are: actors (external users/systems shown as stick figures), use cases (ovals representing functions the system performs), the system boundary (a box enclosing the use cases), and relationships (association between actor and use case; <<include>>, <<extend>> and generalization between use cases). Example: in an ATM, the Customer actor is associated with use cases Withdraw Cash, Check Balance, where Withdraw Cash <<include>> Authenticate.

(b) Requirement elicitation techniques

Elicitation is the activity of gathering requirements from stakeholders. Common techniques:

• Interviews — structured/unstructured one-to-one questioning of stakeholders.
• Questionnaires/Surveys — collecting input from many users efficiently.
• Brainstorming / workshops (e.g. JAD) — group sessions to generate ideas.
• Observation (ethnography) — watching users perform their tasks.
• Prototyping — building a mock-up to clarify requirements through feedback.
• Document analysis — studying existing documents/forms/systems.

(c) Feasibility study

A feasibility study is an early analysis that determines whether a proposed system is worth developing before committing resources. It typically examines: Technical feasibility (can it be built with available technology/skills?), Economic feasibility (do benefits outweigh costs — cost-benefit analysis?), Operational feasibility (will it work within the organization and be accepted by users?), Schedule feasibility (can it be delivered in time?) and Legal feasibility. The outcome is a recommendation on whether to proceed.