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

Architectural Design Process

Architectural design is the early-stage process of identifying the sub-systems that make up a system and the framework for sub-system control and communication. The output is the software architecture — the overall structure of the system.

Key Decisions in the Process

During architectural design, the designer answers several fundamental questions:

1. System structuring — How is the system decomposed into major sub-systems and how do they communicate?
2. Control modelling — What model of control relationships exists between sub-systems?
3. Modular decomposition — How are sub-systems broken down into modules?
4. Selecting a generic application or architectural style that fits the requirements.
5. Documenting the architecture using views (e.g., logical, process, development, physical views — the 4+1 model).

A good architecture aims for non-functional qualities: performance, security, availability, maintainability and modifiability.

Common Architectural Patterns

Conclusion

The architectural design process structures a system into sub-systems and chooses suitable patterns. The right pattern is selected by trading off non-functional requirements (performance, security, maintainability) against the disadvantages above.

Software Project Management

Software project management is the application of knowledge, skills, tools and techniques to plan, organise, staff, direct and control software projects so that software is delivered on time, within budget and to the required quality. It is necessary because software is intangible, projects are often bespoke, and the process is not standardised.

Key activities include: proposal writing, project planning and scheduling, cost estimation, project monitoring and reviews, personnel selection, and reporting.

Project Scheduling

Project scheduling is the activity of dividing the total work into separate tasks (activities), estimating the time and resources for each, judging which tasks depend on others, and allocating people and resources. The aim is to organise tasks to make best use of the workforce and minimise dependencies that stall progress.

Steps:

1. Identify activities and break the project down (work breakdown).
2. Identify activity dependencies.
3. Estimate resources and effort/duration for each activity.
4. Allocate people to activities.
5. Create the schedule (charts) and monitor/revise as the project proceeds.

Schedules are usually represented graphically using bar charts and activity networks.

Bar Charts (Gantt Charts)

A bar chart shows the project calendar along the horizontal axis and activities along the vertical axis. Each activity is drawn as a horizontal bar whose length is proportional to its duration, positioned by its start and finish dates. They clearly show start/end dates, durations, overlapping (parallel) activities, milestones and staff allocation, making them ideal for communicating the plan to managers and staff.

Activity   | Week 1 | Week 2 | Week 3 | Week 4 |
T1 (Design)| ====== |        |        |        |
T2 (Code)  |        | ====== | ====== |        |
T3 (Test)  |        |        |        | ====== |

Activity Networks

An activity network (e.g., PERT/CPM diagram) shows activities and their dependencies as a directed graph of nodes and arrows. It reveals which activities can run in parallel and which must be sequential. By computing the longest path through the network, the critical path — the chain of dependent activities that determines the minimum project duration — is found. Any delay on a critical-path activity delays the whole project, so these activities are managed most closely.

Conclusion

Project management ensures controlled delivery of software; scheduling decomposes and times the work, while bar charts communicate the timeline and activity networks expose dependencies and the critical path.

UML Diagrams for an Online Movie Ticketing System

Assume actors: Customer, Admin, and an external Payment Gateway. Core functions: browse movies/shows, select seats, book and pay, and cancel tickets.

(a) Use Case Diagram

Described in words (UML notation):

• Actors: Customer, Admin, Payment Gateway (external system).
• Use cases (ovals inside the system boundary):
  • Customer → Register/Login, Search Movie, View Show Timings, Select Seats, Book Ticket, Make Payment, Cancel Ticket, View Booking History.
  • Admin → Add/Update Movie, Manage Shows & Screens, View Reports.
  • Make Payment <<include>> the Payment Gateway actor.
  • Book Ticket <<include>> Make Payment; Book Ticket <<include>> Select Seats.
  • Login may be <<include>>d by booking/cancelling use cases.

        +---------------------- Online Ticketing System ----------------------+
        |   (Login)  (Search Movie)  (Select Seats)  (Book Ticket)            |
Customer|   (Make Payment) (Cancel Ticket) (View History)                     | Payment
  O-----|        |Book Ticket >>include>> Make Payment >>include>> Pay |------| Gateway
        |   (Add Movie) (Manage Shows) (View Reports)                         |   O
  Admin |                                                                     |
  O-----|                                                                     |
        +---------------------------------------------------------------------+

(b) Class Diagram

Main classes with attributes (—) and key associations:

• Customer { id, name, email, password; register(), login() } — places → Booking.
• Movie { id, title, genre, duration, language } — has many → Show.
• Show { id, dateTime, screenId, price } — references Movie, Screen; has many → Seat.
• Screen { id, name, totalSeats }.
• Seat { id, row, number, status } — belongs to Show.
• Booking { id, bookingDate, totalAmount, status } — links Customer and selected Seats (1..*); has one → Payment.
• Payment { id, amount, method, status, transactionId } — associated with Booking (1:1).
• Admin { id, name } — manages Movie, Show.

Multiplicities: Customer 1 — * Booking; Booking 1 — 1..* Seat; Show 1 — * Seat; Movie 1 — * Show; Booking 1 — 1 Payment.

(c) Sequence Diagram — "Book a Ticket" scenario

Lifelines: Customer, UI, BookingController, ShowDB, PaymentGateway, Booking.

Customer -> UI            : selectShow(showId)
UI       -> BookingCtrl   : getAvailableSeats(showId)
BookingCtrl -> ShowDB     : querySeats(showId)
ShowDB   --> BookingCtrl  : seatList
BookingCtrl --> UI        : display available seats
Customer -> UI            : chooseSeats(seatIds)
UI       -> BookingCtrl   : bookSeats(custId, seatIds)
BookingCtrl -> ShowDB     : lockSeats(seatIds)
BookingCtrl -> PaymentGW  : processPayment(amount, card)
PaymentGW --> BookingCtrl : paymentSuccess(txnId)
BookingCtrl -> Booking    : create(custId, seatIds, txnId)
BookingCtrl --> UI        : confirmation(bookingId)
UI       --> Customer     : show e-ticket

Messages flow top-to-bottom along the time axis; the return messages (dashed arrows -->) carry results back. On payment failure, an alt fragment releases the locked seats.

Conclusion

The use case diagram captures functional requirements, the class diagram captures the static structure, and the sequence diagram captures the dynamic interaction for the booking scenario.

Software engineering and system engineering differ as follows:

In short, system engineering deals with the entire computer-based system, whereas software engineering is the part of it that builds the software, working within the constraints set by the system engineers.

Risk Management in Software Development

Risk management is the process of identifying risks (events that may adversely affect the project) and drawing up plans to minimise their effect. A risk is a probability that some adverse circumstance will occur, affecting the project, the product, or the business.

It is carried out as a continuous, iterative four-stage process:

1. Risk Identification — List possible project, product and business risks (e.g., staff turnover, requirements change, technology immaturity, schedule slip, hardware unavailability). Checklists and brainstorming are used.

2. Risk Analysis — Assess the probability (very low → high) and seriousness/impact (insignificant → catastrophic) of each identified risk, often combined into a risk exposure value (probability × impact).

3. Risk Planning — Devise strategies to manage key risks:

   • Avoidance strategies — reduce the probability the risk arises.
   • Minimisation strategies — reduce the impact if it does occur.
   • Contingency plans — prepare a fallback for the worst case.

4. Risk Monitoring — Regularly assess each risk to see whether it is becoming more or less probable, and whether its effects have changed. Risks are reviewed at every management progress meeting and plans revised.

The outcome is a risk management plan / risk register documenting risks, their analysis and the chosen strategies. Effective risk management reduces surprises and keeps the project on track.

Software Maintenance Is a Critical Activity

Software maintenance is the process of modifying a software system after delivery to correct faults, improve performance, or adapt it to a changed environment. It is justified as one of the most important activities for the following reasons:

• It consumes the largest share of cost. Studies show maintenance typically accounts for 60–80% of the total software life-cycle cost — far more than initial development. Ignoring it underestimates the real cost of software.
• Software must evolve to remain useful; business rules, laws, hardware and user needs change continuously.
• It preserves the investment made in the software and extends its useful life.

Types of Maintenance

1. Corrective — fixing defects/bugs found after release.
2. Adaptive — adjusting the software to a new environment (new OS, hardware, regulations).
3. Perfective — adding new features or improving performance/usability per user demand.
4. Preventive — restructuring/refactoring to make future maintenance easier (reducing technical debt).

Example

Consider a payroll system in Nepal. When the government revises income-tax slabs in the annual budget, the payroll software must be updated to compute the new tax — this is adaptive/corrective maintenance. Without it, the otherwise-correct software would produce wrong salaries and become unusable, even though no "new" software was built. This shows that the software's value depends on ongoing maintenance, justifying its importance.

Functional vs Non-Functional Requirements

Functional requirements state what the system should do — the specific services, functions, behaviours and outputs the system must provide in response to inputs.

Non-functional requirements (NFRs) are constraints on how the system delivers its functions — quality attributes and limitations such as performance, security and reliability. They often apply to the system as a whole rather than to individual features.

Examples

Functional:

• "The system shall allow a user to log in with a valid username and password."
• "The system shall let a user search for a book by title or author."
• "The system shall generate a monthly sales report."

Non-Functional:

• Performance: "The system shall return search results within 2 seconds."
• Security: "All passwords shall be stored encrypted (hashed)."
• Availability: "The system shall be available 99.9% of the time."
• Usability/Portability: "The system shall run on Windows, Linux and macOS."

Prototyping Model in Software Development

The prototyping model builds an early, working prototype — a partial, often quickly-built version of the system that demonstrates key features (especially the user interface) — so that users and developers can understand and refine the requirements before the final system is built.

Process

1. Requirements gathering — collect known/rough requirements.
2. Quick design — design the visible parts (screens, inputs/outputs).
3. Build prototype — implement a working model rapidly.
4. User evaluation — users try it and give feedback.
5. Refine — iterate steps 2–4 until requirements are clear; then build the final product.

How It Helps

• Clarifies unclear/ambiguous requirements — users react to something concrete, exposing misunderstandings early.
• Reduces requirements risk — mismatches between what users want and what developers think they want are caught before full development.
• Improves usability — UI is validated with real users early.
• Increases user involvement and acceptance, raising satisfaction with the final product.
• Saves cost/time overall by catching defects when they are cheap to fix.

Limitations

Users may mistake the prototype for the final product; developers may make poor design choices to build it quickly; and excessive iterations can extend schedules. Despite these, prototyping is very effective when requirements are not well understood.

Evolutionary vs Throw-away Prototyping

Both are prototyping approaches, but they differ in purpose and in what happens to the prototype.

Summary: In evolutionary prototyping the prototype becomes the system; in throw-away prototyping the prototype's only role is to nail down the requirements and is then thrown away before the real system is built (often using the waterfall model).

Behavioural Model

A behavioural model describes the dynamic behaviour of a system as it executes — that is, what the system does and how it responds to events and inputs over time, rather than its static structure or data. Behavioural models are part of the analysis/requirements phase and capture the system's responses to stimuli.

There are two main types:

1. Data-driven (data-flow) models — show how data moves through a sequence of processing steps as it passes through the system. A Data Flow Diagram (DFD) is the classic example, showing processes, data stores, external entities and data flows.

2. Event-driven models — show how a system reacts to internal and external events. A State Transition (State Machine) diagram is the classic example, showing states and the events that cause transitions between them.

Example (Event-driven — State diagram of an ATM)

Consider an ATM:

[Idle] --insert card--> [Reading Card] --valid--> [Awaiting PIN]
[Awaiting PIN] --correct PIN--> [Menu] --select withdraw--> [Dispensing Cash]
[Dispensing Cash] --cash taken--> [Idle]
[Awaiting PIN] --wrong PIN x3--> [Card Blocked] --> [Idle]

Each state (Idle, Awaiting PIN, Dispensing Cash …) represents a condition of the ATM, and each event (insert card, enter PIN, take cash) triggers a transition to a new state. This captures the behaviour of the system clearly.

Example (Data-driven — DFD)

For an order-processing system, a DFD shows: Customer → (Place Order) → Order data → (Check Stock) → (Generate Invoice) → Invoice, illustrating how data is transformed as it flows through processes.

Spiral Model of Software Development

The spiral model, proposed by Barry Boehm (1988), is an evolutionary, risk-driven process model. The software process is represented as a spiral rather than a sequence of activities. Each loop of the spiral represents one phase of the process, and the radius of the spiral represents the cumulative cost, while the angular dimension represents progress through the phases.

Each loop is divided into four quadrants (sectors):

1. Objective Setting — Define specific objectives for this phase, identify constraints, and draw up a management plan. Project risks are identified.
2. Risk Assessment and Reduction — For each identified risk, a detailed analysis is carried out and steps are taken to reduce the risk (e.g., building a prototype to resolve uncertain requirements). Risk handling is the distinguishing feature of this model.
3. Development and Validation — A development model for the system is chosen (it can be any generic model — waterfall, prototyping, etc.) and the product is developed and tested for that loop.
4. Planning — The project is reviewed and a decision made whether to continue with the next loop (next spiral); the plan for the next phase is drawn up.

Advantages

• Strong emphasis on risk analysis, reducing the chance of failure.
• Good for large, complex and high-risk projects.
• Requirements can be refined over iterations.

Disadvantages

• Costly and requires risk-assessment expertise.
• Not suitable for small or low-risk projects; complex management.

Thus the spiral model combines iterative development with the systematic control of the waterfall model, with explicit, continuous risk management at each cycle.

Key Principles of Agile Methods

Agile methods are based on the Agile Manifesto and a set of underlying principles that emphasise iterative, customer-focused, lightweight development. The key principles are:

1. Customer involvement — Customers are closely and continuously involved throughout development to provide and prioritise requirements and to evaluate iterations.

2. Incremental delivery — The software is developed and delivered in small increments, with the customer specifying the requirements to be included in each increment.

3. People not process — The skills of the development team are recognised and exploited. Team members are left to develop their own ways of working without prescriptive processes.

4. Embrace change — Expect system requirements to change, and design the system so that it can accommodate these changes.

5. Maintain simplicity — Focus on simplicity in both the software being developed and in the development process; actively work to eliminate complexity from the system.

Alongside these, agile values from the manifesto include: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. Other supporting practices include frequent delivery of working software, sustainable pace, face-to-face communication, and continuous attention to technical excellence.