BSc CSIT (TU) Science System Analysis and Design (BSc CSIT, CSC315) Question Paper 2082 Nepal

Phases of Project Management

Project management is the discipline of planning, organising, leading and controlling resources to deliver a system within scope, time, cost and quality constraints. It is generally divided into four phases:

1. Initiation — identify the project, define its goal, prepare the system request and assess feasibility.
2. Planning — create the project plan: work breakdown, schedule, staffing, budget and risk management.
3. Execution (Monitoring & Controlling) — carry out the plan, track progress against the schedule/budget, and take corrective action.
4. Closure (Termination) — deliver the system, evaluate the project, document lessons learned and release resources.

(Some texts also list the management activities as Identifying project size, Creating and managing the work-plan, Staffing the project, Coordinating activities — these all fall within initiation and planning.)

Steps in the First Phase (Project Initiation / Identification & Selection)

The first phase is concerned with identifying the project and deciding whether to undertake it. Its main steps are:

1. Identify the System Request / Business Need A business need or opportunity is recognised (e.g., reduce cost, improve service, comply with regulation). The sponsor prepares a system request stating the project's sponsor, business need, business requirements and expected value.

2. Estimate the Project Size and Value The likely scope, effort and business value of the proposed system are estimated so it can be compared with other candidate projects.

3. Conduct Feasibility Analysis The project is assessed along the major feasibility dimensions:

• Technical feasibility — Can we build it? (technology, skills, risk).
• Economic (financial) feasibility — Should we build it? via cost-benefit analysis (ROI, NPV, payback period).
• Organisational/operational feasibility — Will it be used and accepted? (user and management support, strategic alignment).

4. Approval / Project Selection The approval committee reviews the system request and feasibility study and decides to approve, reject, or table the project. Approved projects are prioritised against available resources.

5. Hand-off to Planning Once selected, the project is formally chartered and moves to the planning phase, where a detailed work-plan and schedule are produced.

The first phase thus ensures only worthwhile, feasible projects that align with organisational goals are taken forward.

Observation vs. Document Analysis (in Requirement Determination)

Both are fact-gathering techniques used to determine requirements, but they look at very different sources of information.

In short: observation shows what people really do, while document analysis shows what the records say should happen. They are complementary — analysts often use document analysis first to learn the formal process, then observation to confirm the true process.

Radical Methods for Determining Requirements

Traditional fact-gathering (interviews, questionnaires) improves the existing process. Radical methods aim to fundamentally rethink and redesign the business, not just automate the current way of working. The main radical techniques are:

1. Business Process Re-engineering (BPR) The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in cost, quality, service and speed. Instead of asking how do we do this now?, BPR asks why do we do this at all? and what is the best way?. Requirements are derived from the newly designed (to-be) process rather than the old one. Three activities support BPR:

• Outcome Analysis — focus on the outcomes/value the customer wants (e.g., the customer wants insurance coverage), and design the process backward from that outcome, ignoring how it is done today.
• Technology Analysis — list important and new technologies and consider how each could be applied to the business to create a brand-new process (technology-driven innovation).
• Activity Elimination — examine each activity and deliberately try to eliminate it, forcing the team to find creative alternatives or prove the activity is truly essential.

2. Duration Analysis A detailed study of the time taken by each step versus the total time of the whole process. Large gaps (e.g., a process needing 2 days of work but taking 2 weeks) reveal where re-engineering, parallelisation or integration of steps is needed.

3. Activity-Based Costing (ABC) Assigns costs to each activity in the process to identify the most expensive steps; these high-cost activities become candidates for radical redesign or elimination.

4. Informal Benchmarking Studying how other (successful) organisations perform the same process and adopting/adapting their better practices, especially common for customer-facing processes.

Radical methods produce requirements for a re-designed business, delivering bigger gains than incremental automation but carrying higher risk.

DFD for the Online Pathology System

Identifying the components

• External Entities: Patient, Doctor
• Key Processes: Register, Login/Authenticate, Enter Test Details & Schedule, Process Payment, Generate & Notify Report, Schedule Doctor Visit
• Data Stores: D1 Patient/Credentials, D2 Tests, D3 Payments, D4 Reports, D5 Appointments

Context Diagram (Level 0)

            registration details,                login,
            test details, payment   --------->   credentials,
  +---------+ ------------------------+  Online  | test date/time,
  | Patient |                         | Pathology| report, notification
  +---------+ <-----------------------+  System  | <----------+
        ^         credentials, schedule         |            |
        |                                        +------------+
        |                                              | report (email),
        |                                              v visit schedule
        |                                         +--------+
        +---------------------------------------> | Doctor |
                                                  +--------+

Level-1 DFD

                +--------------------------------------------------+
  Patient       |                                                  |
   |  reg. details      +-----------+      patient data            |
   +------------------> | 1.0       | -------------------> [ D1 Patient ]
   |                    | Register  |  <-- credentials             |
   |  <-- credentials   +-----------+                              |
   |                                                               |
   |  login info        +-----------+   verify                     |
   +------------------> | 2.0 Login | <-------------------> [ D1 Patient ]
   |  <-- auth status   +-----------+                              |
   |                                                               |
   |  test details      +-------------------+   store test         |
   +------------------> | 3.0 Enter Test &  | --------------> [ D2 Tests ]
   |  <-- date & time   |    Schedule       |                      |
   |                    +-------------------+                      |
   |                                                               |
   |  payment info      +-----------+   payment record             |
   +------------------> | 4.0 Pay   | --------------------> [ D3 Payments ]
   |  <-- receipt       |  Online   |                              |
   |                    +-----------+                              |
   |                                                               |
   |  <-- notification  +-------------------+  read test  [ D2 Tests ]
   |  <-- report (down) | 5.0 Generate &    | <----------+         |
   |                    |  Notify Report    | --> store [ D4 Reports ]
   |                    +-------------------+                      |
   |                          |                                    |
   |                          | if visit required                  |
   |                          v                                    |
   |                    +-------------------+  store [ D5 Appointments ]
   |  <-- visit         | 6.0 Schedule      |                      |
   |      schedule      |  Doctor Visit     | -- report (email) --> Doctor
   |                    +-------------------+                      |
   +---------------------------------------------------------------+

Explanation of the flow

1. 1.0 Register — the patient submits registration details; the system stores them in D1 and issues login credentials back to the patient.
2. 2.0 Login — the patient logs in; credentials are validated against D1. On a valid login the patient may proceed.
3. 3.0 Enter Test & Schedule — the patient enters details of the test to be conducted; the system stores the request in D2 and returns the test date and time.
4. 4.0 Pay Online — the patient can pay online; the payment is recorded in D3 and a receipt is returned.
5. 5.0 Generate & Notify Report — once results are ready they are stored in D4; the patient gets a notification and can download the report.
6. 6.0 Schedule Doctor Visit — if a visit is required, an appointment is created in D5, the schedule is sent to the patient, and the report is emailed to the doctor.

(Note: in a strict DFD every data store connects only to processes; the external entities Patient and Doctor exchange data only with processes, satisfying the DFD rules.)

Critical Factors Distinguishing Agile from Traditional Methods

Agile methods (Scrum, XP, etc.) differ from traditional/plan-driven methods (e.g., waterfall) on several critical factors:

Key distinguishing points (summary)

• Adaptive vs. predictive: Agile responds to change; traditional follows a fixed plan.
• People & collaboration over processes & contracts.
• Working software over heavy documentation.
• Customer collaboration over rigid contract negotiation.
• Incremental delivery vs. big-bang delivery.

These factors trace directly to the four values of the Agile Manifesto, which prioritise individuals, working software, collaboration and responding to change.

The Heart of the Software Development Process: Analysis & Design (Modelling)

In most system-analysis texts, the heart of the software development process is the modelling activity — system analysis and design, where requirements are understood and turned into a blueprint for the solution. It is the bridge between what the user wants and how the system will work.

Why it is the "heart"

• It is where the real intellectual work of understanding the problem and designing the solution happens.
• Errors made here propagate to all later phases and are the most expensive to fix later.
• It converts vague business needs into precise, buildable specifications.

The core (heart) consists of two tightly linked activities

1. System Analysis — understanding what is needed

• Gather and analyse requirements (interviews, observation, document analysis).
• Model the system using DFDs (process view), ER diagrams (data view), use-case/UML models and a data dictionary.
• Produce the System Requirement Specification (SRS).

2. System Design — deciding how to build it

• Logical design — architecture, modules, processing logic.
• Physical design — database/tables, input screens, output reports, interfaces, hardware/software environment.

Illustration

  User needs (problem)
          |
          v
  +-------------------+        +-------------------+
  |   ANALYSIS        |  --->  |   DESIGN          |
  | (model the WHAT:  |        | (model the HOW:   |
  |  DFD, ERD, SRS)   |        |  DB, UI, modules) |
  +-------------------+        +-------------------+
          |                            |
          +------------ HEART ---------+
          v
  Blueprint -> Coding -> Testing -> Deployment

Coding and testing simply realise and verify the model created at the heart; therefore analysis and design (modelling the system) form the core of the entire software development process.

Discounted Payback Period using NPV

Given

• Initial investment (outflow at year 0): Rs. 5,00,000
• Annual cash inflow: Rs. 60,000 per year
• Discount (interest) rate: 15% = 0.15

The discounted payback period is the time needed for the cumulative present value of inflows to recover the initial investment.

Step 1 — Discount each year's cash flow

Present Value (PV) = Cash flow / (1 + r)ⁿ

Step 2 — Compare with the investment

The present value of an infinite (perpetual) stream of Rs. 60,000 at 15% is:

PV (perpetuity) = Cash flow / r = 60,000 / 0.15 = Rs. 4,00,000

Even if the project ran forever, the total discounted inflow can reach only Rs. 4,00,000, which is less than the initial investment of Rs. 5,00,000.

Step 3 — Conclusion

NPV (over infinite life) = 4,00,000 - 5,00,000 = - Rs. 1,00,000  (negative)

• The cumulative discounted cash flow never equals Rs. 5,00,000, so the discounted payback period does not exist (it is infinite / never recovered).
• Since the NPV is negative (-Rs. 1,00,000), the project is financially not viable at a 15% discount rate and should be rejected.

Insight: with a 15% rate, the annual inflow must exceed 5,00,000 × 0.15 = Rs. 75,000 even to be recoverable; Rs. 60,000 is too small, hence no discounted payback.

Steps in the Dialogue Design Process

Dialogue (or interface dialogue) design defines the sequence of interactions between the user and the system — the back-and-forth conversation through which a user navigates, gives commands and receives responses. Good dialogue design makes the system easy and natural to use.

The dialogue design process typically involves the following steps:

1. Designing the Dialogue Sequence (Dialogue Diagramming) Define the basic flow of the conversation — the order in which screens/menus appear and how the user moves among them. This is often documented with a dialogue diagram (state-transition / navigation diagram): boxes represent screens/states and arrows represent the user actions that move between them. It shows valid paths, menus, sub-menus and exit points.

2. Building a Prototype (Storyboarding / Mock-ups) Create a prototype or storyboard of the actual screens, menus and forms so users can see and walk through the proposed dialogue before it is coded. This makes the interaction concrete and reviewable.

3. Assessing User Usability (Evaluation) Evaluate the prototype against usability criteria — consistency, efficiency, ease of learning, error handling and user satisfaction — usually through user testing/feedback. The dialogue is refined based on results, and steps 2–3 are repeated as needed.

Principles guiding the dialogue (must be satisfied)

• Consistency — same actions/terms behave the same everywhere.
• Minimal user action — fewest keystrokes/clicks to complete a task.
• Feedback — system always tells the user what is happening.
• User control — user can move forward, back, cancel and recover from errors.
• Closure — clear sequences with a defined beginning, middle and end.

The output is a clear, prototyped and validated specification of how users will interact with the system.

Designing Physical Tables (Physical Database Design)

The goal of designing physical tables is to take the logical data model (normalised relations / ERD) and turn it into an efficient physical database of tables, columns, data types, keys and indexes that the chosen DBMS can store and retrieve quickly.

Process / Steps

1. Map logical entities to physical tables Each logical entity (relation) becomes a table, and each attribute becomes a column (field). Many-to-many relationships are resolved into associative (junction) tables.

2. Choose data types and field properties For every column select an appropriate data type and size (e.g., INT, VARCHAR(50), DATE, DECIMAL(10,2)), and set properties such as NOT NULL, DEFAULT values and CHECK constraints to enforce data integrity and minimise storage.

3. Define keys and referential integrity Define the primary key of each table, foreign keys to link related tables, and unique constraints. This enforces entity and referential integrity.

4. Decide on denormalisation (if needed) The normalised design avoids redundancy, but for performance some controlled denormalisation (combining tables or adding derived/redundant columns) may be applied where frequent joins are costly — trading some redundancy for speed.

5. Design indexes and file organisation Create indexes on primary keys and frequently searched/joined columns to speed up retrieval, and choose the file organisation (heap, sequential, hashed, clustered) appropriate to the access pattern. Avoid over-indexing, which slows inserts/updates.

6. Estimate size and plan for growth/performance Estimate storage volume (rows × row size) and expected access/transaction volumes to size the database, plan partitioning, and ensure adequate performance.

Example

CREATE TABLE Student (
    student_id   INT          PRIMARY KEY,
    name         VARCHAR(60)  NOT NULL,
    dob          DATE,
    program_id   INT          NOT NULL,
    FOREIGN KEY (program_id) REFERENCES Program(program_id)
);
CREATE INDEX idx_student_program ON Student(program_id);

The result is a well-structured set of physical tables that preserves data integrity while delivering good storage and retrieval performance.

Types of Installation (Conversion Strategies)

Installation (conversion) is the process of changing over from the old system to the new system. The strategy chosen balances risk, cost and disruption. There are four main types:

1. Direct (Plunge / Big-Bang) Conversion

The old system is switched off and the new system switched on at once on a chosen date.

• Advantages: cheapest, fastest, no need to run two systems.
• Disadvantages: highest risk — if the new system fails there is no fallback; suitable only for low-risk or non-critical systems.

Old system ----X (stops)
New system        |----> (starts)

2. Parallel Conversion

The old and new systems run simultaneously for a period; results are compared until the new system is proven reliable, then the old one is dropped.

• Advantages: lowest risk, old system acts as backup, outputs can be cross-checked.
• Disadvantages: expensive and effort-intensive (double work, double cost).

Old system  |------------------|  (stops after check)
New system  |------------------|------>

3. Pilot Conversion

The new system is installed in one location or department (a pilot site) first. After it works well there, it is rolled out to the rest of the organisation.

• Advantages: limits risk to one site; problems found before full rollout.
• Disadvantages: slower full deployment; pilot site bears the risk.

4. Phased (Staged / Incremental) Conversion

The new system is introduced module by module (in phases) over time rather than all at once.

• Advantages: risk spread over time; users adapt gradually.
• Disadvantages: takes longer; interfaces needed between old and new parts during transition.

The choice depends on how critical the system is, available budget and acceptable risk.

Measuring Maintenance Effectiveness

After a system goes live, maintenance keeps it useful and reliable. Measuring maintenance effectiveness tells whether the maintenance effort is efficient, the system is stable, and resources are well used. It is measured using a combination of quantitative metrics.

Key Measures

1. Number of Failures / Defect Rate The count of faults reported per period. A declining number of failures over time indicates effective (especially corrective and preventive) maintenance and a stabilising system.

2. Mean Time Between Failures (MTBF) The average operational time between two consecutive failures.

MTBF = Total operating time / Number of failures

A higher MTBF means the system runs longer without breaking — more effective maintenance and higher reliability.

3. Mean Time To Repair (MTTR) The average time taken to diagnose and fix a reported fault.

MTTR = Total repair time / Number of repairs

A lower MTTR means problems are resolved quickly — more responsive, effective maintenance.

4. System Availability Derived from MTBF and MTTR:

Availability = MTBF / (MTBF + MTTR)

Higher availability reflects effective maintenance keeping the system usable.

5. Maintenance Cost / Effort The time, money and staff spent on maintenance, often as a percentage of total system cost or per request. Effective maintenance keeps cost reasonable while keeping quality high.

6. Request Backlog and Turnaround The number of pending maintenance requests and the average time to close them; a small, fast-clearing backlog indicates effective maintenance.

Summary

Tracking these over time shows whether maintenance is keeping the system reliable, available and cost-effective.

Sequence Diagram: Online Food Ordering System with Online Payment

A sequence diagram is a UML interaction diagram that shows objects/actors as lifelines and the time-ordered sequence of messages exchanged between them. Below is the sequence for placing a food order and paying online.

Participants (lifelines)

• Customer (actor)
• UI / Order System (web/app interface)
• Restaurant (order acceptance)
• Payment Gateway
• Database

Sequence Diagram (ASCII)

 Customer        Order System        Restaurant       Payment GW        Database
    |                  |                  |                 |                |
    |--browse menu---->|                  |                 |                |
    |                  |--get menu items------------------------------------>|
    |<--show menu------|<--menu items--------------------------------------- |
    |                  |                  |                 |                |
    |--add to cart---->|                  |                 |                |
    |--place order---->|                  |                 |                |
    |                  |--save order (pending)----------------------------- >|
    |                  |                  |                 |                |
    |--choose online pay->|              |                 |                |
    |                  |--request payment------------------>|                |
    |<------ enter payment details ----- |                 |                |
    |--payment info---------------------------------------->|                |
    |                  |                  |   <--authorize--|                |
    |                  |<--payment success/token-----------|                |
    |                  |--update order (paid)----------------------------- ->|
    |                  |--send order------>|                 |                |
    |                  |<--order accepted--|                 |                |
    |<--confirmation & receipt-|          |                 |                |
    |                  |                  |                 |                |
    |<--- order status / delivery update -|                 |                |
    |                  |                  |                 |                |

Explanation of the interaction

1. The Customer browses the menu; the Order System fetches items from the Database and displays them.
2. The customer adds items to the cart and places the order, which is saved as pending.
3. The customer selects online payment; the Order System contacts the Payment Gateway.
4. The customer enters payment details; the gateway authorises the transaction and returns success.
5. The order is updated to paid in the Database and sent to the Restaurant, which accepts it.
6. A confirmation/receipt is returned to the customer, followed by order/delivery status updates.

(Optional alt fragment: if payment fails, the gateway returns failure, the order stays pending and the customer is asked to retry.)

a) Integration Testing

Integration testing is the level of testing performed after unit testing, in which individually tested modules/components are combined and tested together to verify that they interact and work correctly as a group. Its goal is to expose defects in the interfaces and interactions between modules (wrong parameters, mismatched data, incorrect calls).

Approaches:

• Big-Bang — all modules combined at once and tested together; simple but hard to locate faults.
• Top-Down — testing starts from the top (main) module downward, using stubs for lower modules not yet ready.
• Bottom-Up — testing starts from the lowest modules upward, using drivers to call them.
• Sandwich/Hybrid — combines top-down and bottom-up.

Integration testing comes between unit testing and system testing in the testing hierarchy and ensures modules cooperate correctly.

b) Relational Model

The relational model is a logical data model (proposed by E. F. Codd) that organises data into two-dimensional tables called relations. It is the foundation of relational databases (RDBMS) and SQL.

Key concepts:

• Relation (Table) — a collection of related data organised in rows and columns.
• Tuple (Row / Record) — a single record in the table.
• Attribute (Column / Field) — a named property of the relation.
• Domain — the set of permitted values for an attribute.
• Degree — number of attributes; Cardinality — number of tuples.
• Primary Key — attribute(s) that uniquely identify each tuple.
• Foreign Key — attribute referencing the primary key of another relation, enforcing referential integrity.

Example relation Student:

Advantages: simple tabular structure, data independence, integrity constraints, powerful querying via SQL, and reduced redundancy through normalisation.