BSc CSIT (TU) Science Software Engineering (BSc CSIT, CSC364) Question Paper 2082 Nepal

Software Testing

Software testing is the process of executing a program with the intent of finding errors and verifying that the software meets its specified requirements and behaves as expected. It is a key part of verification and validation (V&V): it demonstrates that the software does what it is intended to do (validation) and conforms to its specification (verification), and it exposes defects before the software is delivered.

Testing can only show the presence of defects, not their absence; the goal is to find as many defects as possible with realistic effort.

The Software Testing Process

The general testing process moves from individual components to the whole system:

1. Unit / Component Testing — Individual components (functions, objects, classes) are tested in isolation, usually by the developer, to ensure each works correctly.
2. Integration Testing — Components are combined and tested together to expose interface and interaction defects.
3. System Testing — The integrated system is tested as a whole against the requirements (functional and non-functional, e.g., performance, security).
4. Acceptance / Release Testing — The system is tested by/for the customer to confirm it is acceptable for deployment.

A typical model-based test workflow:

Design test cases  ->  Prepare test data  ->  Run program with test data  ->  Compare results to expected
        ^                                                                              |
        |______________________ (re-test after fixing defects) _________________________|

Test cases are derived from the specification (black-box) and/or program structure (white-box), with techniques such as equivalence partitioning, boundary value analysis, and path testing.

Development Testing vs Release Testing

In short, development testing is internal, defect-finding testing done while building the software; release testing validates a finished version against requirements before it is given to users.

How Test-Driven Development (TDD) Improves Software Quality

Test-Driven Development is an approach in which tests are written before the code. Development proceeds in short cycles known as Red–Green–Refactor:

1. Red — Write a small automated test for the next bit of functionality; it fails (no code yet).
2. Green — Write the minimum code needed to make the test pass.
3. Refactor — Clean up the code while keeping all tests passing.

TDD improves quality because:

• Every piece of code is covered by tests, giving high test coverage and a safety net against regressions.
• Defects are found immediately, when they are cheapest to fix.
• It clarifies requirements — writing the test first forces you to define expected behavior precisely.
• It encourages simple, modular, testable design.
• The test suite serves as living documentation and supports confident refactoring.

Example

Suppose we need an add(a, b) function.

# Step 1 (Red): write the test first
def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
# Running it fails: 'add' is not defined.

# Step 2 (Green): write minimum code to pass
def add(a, b):
    return a + b
# Now test_add() passes.

# Step 3 (Refactor): improve code/tests while keeping them green.

Because the test existed first, the function is guaranteed correct for the specified cases, and any future change that breaks add is caught instantly — directly raising software quality.

Architectural Design Decisions

Architectural design is the process of identifying the major structural components of a system and the relationships between them. It is a creative process; however, regardless of domain, architects must make a number of common architectural design decisions that fundamentally shape the system:

1. Is there a generic application architecture that can act as a template for the system being designed?
2. How will the system be distributed across hardware/cores (centralized vs distributed)?
3. Which architectural patterns/styles are appropriate (e.g., MVC, layered, client-server, pipe-and-filter)?
4. What approach will be used to structure the system (decomposition into modules/components)?
5. How will the structural components be decomposed into sub-components?
6. What control strategy will manage component operation (centralized control, event-based)?
7. How will the architectural design be evaluated against quality attributes?
8. How should the architecture be documented (views/diagrams)?

These decisions are driven by the required non-functional attributes — performance, security, safety, availability, and maintainability — which often conflict and must be traded off.

a) Model-View-Controller (MVC) Architecture

MVC separates a system into three logically distinct components so that presentation and interaction are decoupled from data and logic.

• Model — manages the system data and associated business logic.
• View — defines and manages how the data is presented to the user.
• Controller — handles user input, passes it to the model/view, and manages interaction.

        +-----------+   change notification   +---------+
        |   Model   |------------------------->|  View   |
        +-----------+                          +---------+
              ^                                     ^
        update|                                user |  sees
              |          +-------------+            |
              +----------| Controller  |<-----------+
                         +-------------+
                              ^
                         user input

Use: web applications and GUI systems where multiple views of the same data are needed. Advantage: data can change independently of its representation. Disadvantage: extra complexity for simple interfaces.

b) Client-Server Architecture

The system is organized as a set of services provided by servers and a set of clients that use those services, communicating over a network.

• Servers offer services (e.g., database, print, file).
• Clients request services; they need to know what servers exist but servers need not know all clients.

  Client 1     Client 2     Client 3
     \            |            /
      \           |           /
       +---------------------+
       |       Network       |
       +---------------------+
        /         |          \
  +---------+ +---------+ +-----------+
  | Catalog | | Video   | |  Payment  |
  | Server  | | Server  | |  Server   |
  +---------+ +---------+ +-----------+

Advantage: distributed, servers can be replicated/scaled, easy to add new clients. Disadvantage: each service is a single point of failure; performance depends on the network.

c) Pipe and Filter Architecture

Data flows through a sequence of filters (processing components), connected by pipes that carry the output of one filter to the input of the next. Each filter transforms its input and is independent of the others.

  Input --> [ Filter 1 ] --pipe--> [ Filter 2 ] --pipe--> [ Filter 3 ] --> Output
            (read)                 (process)              (write)

Example: A classic batch data-processing pipeline — Read records -> Validate -> Compute -> Print report, or Unix commands chained with |.

Advantage: easy to understand, supports reuse and transformation reuse, naturally matches many business/data processes. Disadvantage: common data format must be agreed; not suited to interactive systems.

Project Management

Software project management is the discipline of planning, organizing, leading and controlling the resources, activities and people involved in a software project so that the software is delivered on time, within budget, and to the required quality, while meeting organizational goals. It is needed because software is intangible, projects are often unique, and processes are not standardized, making software projects especially hard to manage.

Project Management Activities

1. Project Planning — Identifying the activities, milestones and deliverables; estimating effort, cost and schedule; allocating resources. Plans are produced at the start and revised continuously.
2. Risk Management — Identifying risks that may affect the project, assessing them, and planning to minimize their impact (detailed below).
3. People Management — Choosing the right people, organizing the team, motivating and coordinating staff, and dealing with communication and morale.
4. Project Scheduling — Breaking work into tasks, estimating durations, sequencing tasks (allowing for dependencies), and representing them using Gantt charts or activity networks (PERT).
5. Cost/Effort Estimation — Estimating the resources required, using techniques such as COCOMO, function points or expert judgement.
6. Proposal Writing — Preparing the bid/proposal that describes objectives and how the work will be done (at project initiation).
7. Monitoring and Reviews — Tracking progress against the plan, comparing actual vs planned cost/schedule, and taking corrective action.
8. Report Writing & Presentations — Communicating status and results to stakeholders and senior management.

Risk Management Process

Risk management is an iterative process with four key stages:

1. Risk Identification — Identify project, product and business risks.
2. Risk Analysis — Assess the probability and impact (seriousness) of each risk; compute risk exposure to prioritize.
3. Risk Planning — Plan responses: avoidance (reduce probability), minimization (reduce impact), or contingency (fallback plan).
4. Risk Monitoring — Continuously track risks and the effectiveness of mitigation; revise plans at each milestone.

Identify --> Analyse --> Plan --> Monitor --> (loop back to Identify)

Worked Example — Online Examination System

Walkthrough of one risk:

• Identify: "The exam server may crash under peak load when thousands of students log in simultaneously."
• Analyse: probability = moderate, impact = catastrophic (an exam could be invalidated) → high exposure, must address.
• Mitigate (plan): perform load/stress testing, deploy redundant/auto-scaling servers, and keep a contingency plan (paper/offline backup) ready.
• Monitor: watch server metrics and re-evaluate as student numbers grow.

This disciplined loop keeps the project's threats visible and under control throughout development.

Requirements Elicitation

Requirements elicitation (and analysis) is the process of working with system stakeholders — customers, end-users, domain experts — to discover, understand and gather the requirements of the system: the services it should provide, its required performance, and its constraints. It is the first technical activity of requirements engineering and is challenging because stakeholders may not know what they want, may express needs in their own terms, and may have conflicting requirements.

Requirements Elicitation Techniques

1. Interviews — Talking to stakeholders directly. Closed interviews use a predefined set of questions; open interviews explore issues without a fixed agenda. Good for in-depth understanding but interviewers must avoid bias and capture tacit knowledge.

2. Questionnaires / Surveys — A set of written questions distributed to many stakeholders. Useful for gathering information from a large, geographically spread group quickly, though answers can be shallow.

3. Observation (Ethnography) — The analyst observes users doing their actual work in their environment. Reveals tacit, real-world work practices and social factors that users cannot easily articulate.

4. Scenarios — Describing example sessions of how the system will be used in real-life situations (a sequence of normal events plus exceptions). They make requirements concrete and easy for users to relate to.

5. Use Cases — A UML technique that identifies actors and the interactions (use cases) they have with the system; complements scenarios.

6. Prototyping — Building an early working model so users can try it and give feedback, helping them discover and refine requirements.

7. Brainstorming / Workshops (e.g., JAD) — Group sessions where stakeholders and developers jointly generate and agree requirements.

8. Document/Domain Analysis — Studying existing systems, manuals and documents to extract requirements.

In practice several techniques are combined to obtain complete and consistent requirements.

COCOMO Estimation for a 320 KLOC Project

Given KLOC = 320. We apply the Basic COCOMO formulas for each mode.

a) Organic Mode

Effort = 2.4 × (KLOC)^1.05

Effort = 2.4 × (320)^1.05
       = 2.4 × 10^(1.05 × log10 320)
       = 2.4 × 10^(1.05 × 2.5051)
       = 2.4 × 10^(2.6304)
       = 2.4 × 427.0
       ≈ 1024.8 person-months

Development Time = 2.5 × (Effort)^0.38

Time = 2.5 × (1024.8)^0.38
     = 2.5 × 10^(0.38 × log10 1024.8)
     = 2.5 × 10^(0.38 × 3.01065)
     = 2.5 × 10^(1.1440)
     = 2.5 × 13.93
     ≈ 34.8 months

Organic: Effort ≈ 1025 person-months, Time ≈ 34.8 months.

b) Embedded Mode

Effort = 3.6 × (KLOC)^1.20

Effort = 3.6 × (320)^1.20
       = 3.6 × 10^(1.20 × 2.5051)
       = 3.6 × 10^(3.00614)
       = 3.6 × 1014.3
       ≈ 3651.5 person-months

Development Time = 2.5 × (Effort)^0.32

Time = 2.5 × (3651.5)^0.32
     = 2.5 × 10^(0.32 × log10 3651.5)
     = 2.5 × 10^(0.32 × 3.56245)
     = 2.5 × 10^(1.13998)
     = 2.5 × 13.80
     ≈ 34.5 months

Embedded: Effort ≈ 3651 person-months, Time ≈ 34.5 months.

Summary

(Values may vary slightly with rounding.) The embedded mode requires far more effort because of its higher exponent and coefficient, reflecting the tighter constraints of embedded systems.

Incremental Development vs Integration and Configuration

Both are software process approaches but differ fundamentally in whether software is built afresh or assembled from existing parts.

Which is suitable for large-scale enterprise systems, and why?

For large-scale enterprise systems, the Integration and Configuration (reuse-based) approach is generally most suitable. Such systems are large, complex and costly to build from scratch, and the market offers mature, proven components — ERP suites (SAP, Oracle), databases, middleware, payment and authentication services. Reusing and configuring these:

• reduces development cost, time and risk, since components are already tested and reliable;
• allows the organization to focus effort on business-specific configuration rather than reinventing standard functionality;
• improves reliability and maintainability by relying on well-supported, widely-used software.

Incremental development is still valuable and is often combined with reuse, but for very large enterprise systems building everything incrementally from scratch would be prohibitively expensive and slow.

Online Food Delivery System — Context Model & Use Case Diagram

Assumptions:

• Actors are Customer, Restaurant, Delivery Rider (Agent), and Admin.
• The system integrates with an external Payment Gateway and a Maps/Location service (e.g., for tracking).
• Customers browse restaurants, place orders, pay online, and track delivery.

1. Context Model

A context model shows the system as a single process and the external entities (systems/people) that interact with it, defining the system boundary.

        +-----------+                         +------------------+
        | Customer  |                         | Payment Gateway  |
        +-----------+                         +------------------+
              \                                        /
               \                                      /
                v                                    v
          +-----------------------------------------------+
          |        Online Food Delivery System            |
          |              (central system)                 |
          +-----------------------------------------------+
                ^               ^                ^
               /                |                 \
              /                 |                  \
   +--------------+   +------------------+   +----------------+
   | Restaurant   |   | Delivery Rider   |   | Maps / Location |
   +--------------+   +------------------+   +----------------+

The diagram shows that the system exchanges data with customers (orders, payments), restaurants (menus, order acceptance), riders (delivery assignment/status), the payment gateway (transactions) and the maps service (tracking).

2. Use Case Diagram

Actors & key use cases:

• Customer: Register/Login, Browse Restaurants, Search Food, Place Order, Make Payment, Track Order, Rate & Review.
• Restaurant: Manage Menu, Accept/Reject Order, Update Order Status.
• Delivery Rider: View Assigned Deliveries, Update Delivery Status.
• Admin: Manage Users, Manage Restaurants, View Reports.
• Payment Gateway (external): handles Make Payment.

                       Online Food Delivery System
   +-------------------------------------------------------------+
   |   ( Register / Login )                                       |
   |   ( Browse Restaurants )            ( Manage Menu )          |
Customer --( Place Order )--<<include>>--> ( Make Payment ) ------|--> Payment Gateway
   |   ( Track Order )                   ( Accept Order ) <-------|-- Restaurant
   |   ( Rate & Review )                 ( Update Status ) <------|-- Delivery Rider
   |                                     ( Manage Users )  <------|-- Admin
   |                                     ( View Reports )         |
   +-------------------------------------------------------------+

Relationships: Place Order includes Make Payment; Track Order extends Place Order; the Payment Gateway is associated with Make Payment. This captures the core interactions between all actors and the system.

Software Quality Management

Software Quality Management (SQM) is the set of management activities that ensure a software product achieves the required level of quality. It establishes a framework of organizational quality processes and standards, checks that they are followed, and continuously improves them. SQM operates at three levels — organizational (quality processes/standards), project (a quality plan), and process (applying QA and QC).

Its main concerns are defining quality goals, managing quality processes, and assuring & controlling quality throughout development.

Quality Management, Quality Assurance, and Quality Control

Relationship

          Quality Management (defines & oversees)
                 /                    \
      Quality Assurance          Quality Control
   (process: prevent defects)  (product: detect defects)

• Quality Management is the umbrella; it sets up and supervises both QA and QC.
• QA focuses on the process — building quality in by establishing good standards and procedures (defect prevention).
• QC focuses on the product — verifying that deliverables meet those standards via reviews, inspections and testing (defect detection).

Together they ensure that quality is both planned and built into the process (QA) and verified in the product (QC), under the coordination of overall quality management.

Model-Driven Architecture (MDA)

Model-Driven Architecture (MDA) is a model-focused approach to software design and implementation, proposed by the Object Management Group (OMG). It uses a set of UML models at different levels of abstraction as the primary artifacts of development; code is (semi-)automatically generated from these models. MDA is a particular instance of the broader idea of Model-Driven Engineering (MDE).

The Three MDA Models

MDA proposes building a system through successive, more detailed models:

1. Computation Independent Model (CIM) — Also called the domain model; it models the important domain concepts and the environment, independent of any computation. ("What the business needs.")
2. Platform Independent Model (PIM) — Models the system's operation and functionality without reference to a specific implementation platform; usually a UML model showing static structure and dynamic behavior. ("What the system does.")
3. Platform Specific Model (PSM) — Transforms the PIM into a model tied to a particular platform/technology (e.g., Java EE, .NET), from which code can be generated. ("How it runs on a platform.")

 CIM  --transform-->  PIM  --transform-->  PSM  --generate-->  Code
(domain)         (platform-independent) (platform-specific)

How MDA Helps in System Modeling

• It raises the level of abstraction — engineers work with models, not code, so they reason about the problem rather than implementation detail.
• Transformations between CIM → PIM → PSM → code can be automated, improving consistency and productivity.
• A single PIM can be retargeted to different platforms by applying different transformations, supporting portability and long-lived designs.

Advantages

• Higher abstraction lets developers focus on business/domain logic rather than platform details.
• Platform independence — the same model can be reused across technologies.
• Potential for automatic code generation, improving speed and consistency.
• Models serve as durable documentation.

Disadvantages

• Requires specialized tools and expertise; tool support is limited and varies in quality.
• Full automatic transformation is hard — generated code often still needs manual work.
• Abstract models may not capture all platform-specific details, and the approach is not widely adopted in practice.
• Significant upfront learning and modeling effort.

Implementation Issues in Software Development

Implementation is the activity of translating a design into a working program. Beyond simply writing code, several broader implementation issues strongly affect the cost, quality and manageability of the resulting software. Three of the most important are software reuse, configuration management, and host-target development.

1. Software Reuse

Reuse is the practice of building new software from existing software assets rather than writing everything from scratch. Reuse can occur at several levels:

• Abstraction level — reusing knowledge/patterns (e.g., design patterns).
• Object/component level — reusing classes, objects or components from a library.
• System level — reusing whole application systems (COTS) and configuring them.

Benefits: lower cost, faster delivery, and higher reliability (reused components are already tested). Costs/issues: finding suitable components, the effort to understand and adapt them, and possible loss of control over their evolution.

2. Configuration Management

Configuration management (CM) is the management of an evolving system so that changes to its components are controlled and a consistent, buildable system can always be produced. Key concerns during implementation:

• Version management — tracking versions of components (using a VCS such as Git) so concurrent changes don't conflict.
• System building — assembling and compiling components into an executable system, often automated and integrated with continuous integration.
• Change management — recording, evaluating and approving change requests in a controlled way.

CM is essential because many developers change many components over time; without it the system becomes inconsistent and unbuildable.

3. Host-Target Development

Most software is developed on one computer (the host) but executes on a different one (the target).

• The host is the development machine (with IDE, compilers, debuggers, build tools).
• The target is the platform where the software finally runs (e.g., a server, mobile device or embedded system).

Developers use an integrated development environment (IDE) on the host and then deploy the software to the target, often testing on a simulator/emulator of the target or on the target itself. Issues to manage include differences between host and target environments, deployment configuration, and choosing appimport tools.

Together, attention to reuse, configuration management and host-target development leads to cheaper, more reliable and more maintainable implementations.

Types of Software Maintenance

Software maintenance is the modification of a software product after delivery. It is classified into four types based on the reason for the change:

Which Type Consumes the Most Resources, and Why?

Perfective maintenance (closely followed by adaptive) consumes the most resources. Studies (e.g., by Lientz and Swanson) show that the largest share of maintenance effort — typically around 50–65% — goes to perfective maintenance.

Reasons:

• Once software is in successful operation, users continually request new features and improvements, generating a steady stream of enhancement work.
• Business environments evolve, so the system must keep growing in functionality to remain useful and competitive.
• Adding/changing functionality often requires understanding, modifying and re-testing large parts of an existing system, which is expensive.
• Corrective (bug-fixing) maintenance is typically a smaller fraction (~20%), because most serious defects are removed before release.

Thus the demand for continual enhancement of working software makes perfective maintenance the most resource-intensive category.

a) Open-Source Development

Open-source development is an approach in which the source code of a software system is made publicly available, and volunteers (and organizations) from around the world are invited to contribute to its development, modification and improvement.

Key characteristics:

• Source code is freely available and can be read, modified and redistributed under an open-source license (e.g., GPL, MIT, Apache).
• Development is community-driven: a large, distributed community of contributors submits patches/features, often coordinated through version-control platforms (e.g., GitHub) and a core maintainer team.
• Examples: Linux, Apache, Mozilla Firefox, MySQL, Python.

Advantages: lower cost, rapid bug detection and fixing ("many eyes"), transparency, and avoidance of vendor lock-in. Issues: managing many contributors, ensuring quality/consistency, license compatibility, and uneven documentation/support.

b) Agile Project Management

Agile project management is the management of software projects developed using agile methods, which emphasize iterative, incremental delivery, flexibility, and close customer collaboration rather than detailed up-front planning.

Key features:

• Work is delivered in short, time-boxed iterations (sprints, typically 2–4 weeks), each producing a potentially shippable increment.
• Requirements are kept in a prioritized product backlog; the most valuable items are built first.
• Scrum is the most widely used framework, with roles (Product Owner, Scrum Master, Development Team) and events (sprint planning, daily stand-up/scrum, sprint review, retrospective).
• Progress is tracked visually using burndown charts and boards rather than heavy documentation.
• The team self-organizes, welcomes changing requirements, and continuously improves through retrospectives.

Benefits: faster delivery of value, adaptability to change, high customer satisfaction, and early visibility of progress and risks.