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

CASE Tools

CASE (Computer-Aided Software Engineering) tools are software applications that automate and support the various activities of the System Development Life Cycle, such as analysis, design, coding, testing and documentation. They improve productivity, reduce errors and enforce standards by providing a common, integrated environment for analysts, designers and developers.

Components of CASE Tools

CASE environments are usually built from the following components:

1. Central Repository (Information Repository): A shared database that stores all project data — data dictionary entries, diagrams, design specifications and metadata — ensuring consistency and reuse across the project.
2. Diagramming / Graphics Tools: Used to draw DFDs, ER diagrams, structure charts, flowcharts and UML diagrams that model the system pictorially.
3. Data Dictionary / Documentation Tools: Record definitions of data elements, data stores and processes, and automatically generate project documentation.
4. Analysis and Verification Tools: Check models for completeness, consistency and balancing errors (e.g. ensuring data flows in a DFD are properly defined).
5. Code Generators: Automatically produce source code or database schemas from the design specifications.
6. Prototyping / Screen-and-Report Generators: Help build sample input screens, forms and reports for user validation.
7. Project Management Tools: Support scheduling, estimation and tracking of project tasks.

Classification

• Upper CASE: Supports early SDLC phases — planning, analysis and design (diagramming, repository).
• Lower CASE: Supports later phases — coding, testing and maintenance (code generators, debuggers).
• Integrated CASE (I-CASE): Combines both through a shared repository.

Role in System Development

• Speeds up development and reduces manual effort.
• Enforces standardization and consistency of diagrams and documentation.
• Improves quality through automated error and consistency checking.
• Eases maintenance because changes are reflected automatically across linked components.
• Enhances communication among the development team via a shared repository.

Logical vs Physical System Design

In short, logical design describes the system conceptually (data, processes, relationships) without regard to technology, while physical design converts that logical model into a workable specification using a specific platform.

Input Design

Input design is concerned with converting user-oriented inputs into a computer-based format. Goals are accuracy, ease of use and minimum data-entry effort. Key activities:

• Deciding input data and media (keyboard, scanner, form, web).
• Designing source documents and input screens.
• Building validation and error-handling (range checks, format checks, check digits).
• Reducing input volume and delay.

Output Design

Output design determines how information is presented to users. A good output must reach the right user, at the right time, in a usable format. Considerations:

• Type of output: external/internal, printed report, screen display, file.
• Content, format and layout of reports.
• Frequency (on-demand, periodic) and distribution.
• Clarity, accuracy and relevance of information.

Principles of Good Form Design

1. Easy to fill in — logical flow (top-to-bottom, left-to-right), adequate spacing.
2. Meet the purpose — capture only required data, grouped logically.
3. Ensure accuracy — clear captions, instructions and validation.
4. Attractive and simple — uncluttered layout, proper use of fonts and boxes.
5. Identification — title, form number and organization name.
6. Sectioning — heading, body and footer zones; routing/control sections where needed.

System Development Life Cycle (SDLC)

The SDLC is a structured, phased framework that describes the entire process of developing an information system — from initial investigation through design, implementation and ongoing maintenance. It ensures systems are built systematically, on time, within budget and to required quality.

Phases of the SDLC

1. Preliminary Investigation / Planning The problem or opportunity is identified, the request is evaluated, and a feasibility study (technical, economic, operational, schedule) determines whether the project is worth pursuing.

2. Requirement (System) Analysis The analyst studies the existing system using fact-gathering techniques (interviews, questionnaires, observation, document review) and models requirements using DFDs, ER diagrams and a data dictionary. Output is the Software Requirement Specification (SRS).

3. System Design The logical model is converted into a technical blueprint. Includes input, output, database, interface and process design, producing logical and physical design documents.

4. Coding / Development Programmers translate design specifications into actual program code using a suitable programming language and build the database.

5. Testing The system is verified through unit, integration, system and acceptance testing to ensure it meets the requirements and is free of errors.

6. Implementation / Deployment The new system is installed and put into operation. Activities include file conversion, user training and changeover (direct, parallel, phased or pilot).

7. Maintenance After delivery, the system is corrected, adapted, enhanced or improved as needs change (corrective, adaptive, perfective, preventive maintenance).

Diagram (described)

The waterfall representation flows downward as boxes connected by arrows:

Planning/Investigation
        ↓
     Analysis
        ↓
      Design
        ↓
   Coding/Development
        ↓
      Testing
        ↓
   Implementation
        ↓
    Maintenance ──► (feedback loops back to earlier phases)

Feedback arrows from Maintenance back to earlier phases show the cyclic, iterative nature of the SDLC.

System Conversion (Changeover) Strategies

Conversion is the process of switching from the old system to the new one.

1. Direct (Plunge / Big-Bang) Conversion The old system is shut down and the new system is switched on at the same moment.

• Advantage: cheapest and fastest, no duplication of effort.
• Disadvantage: highest risk — if the new system fails there is no fallback.

2. Parallel Conversion Both old and new systems run simultaneously for a period; results are compared until the new system is proven reliable.

• Advantage: very safe, old system is a backup.
• Disadvantage: costly and labour-intensive (running two systems).

3. Phased (Staged) Conversion The new system is introduced in stages/modules, one part at a time, until the whole system is operational.

• Advantage: risk is spread out; problems are isolated to one module.
• Disadvantage: takes longer; old and new parts must interface temporarily.

4. Pilot Conversion The new system is first introduced in one location or department (the pilot site). After success there, it is rolled out to the rest of the organization.

• Advantage: limits risk to one site; acts as a live test.
• Disadvantage: full benefits delayed; chosen site may not represent all others.

System Maintenance

System maintenance is the modification of a software system after delivery to correct faults, improve performance, or adapt it to a changed environment. It is the longest and most expensive phase of the SDLC, since systems must continually evolve to remain useful.

Types of Maintenance

1. Corrective Maintenance — Fixing errors, bugs and defects discovered during operation (e.g. correcting a faulty calculation in a report).
2. Adaptive Maintenance — Modifying the system to keep it working in a changed environment, such as a new operating system, hardware, or government regulation (e.g. updating tax rates).
3. Perfective Maintenance — Enhancing functionality or performance in response to user requests, such as adding new features or improving the interface and speed.
4. Preventive Maintenance — Making changes to prevent future problems and improve maintainability/reliability, such as restructuring code or updating documentation before errors occur.

RAD vs Agile Development

Both RAD (Rapid Application Development) and Agile are iterative, user-focused alternatives to the traditional waterfall model, but they differ in emphasis.

In summary: RAD focuses on building software fast through prototyping and reusable components, whereas Agile focuses on flexibility and collaboration, embracing changing requirements through short, repeated iterations.

Relationship between DFD and ERD

The DFD (Data Flow Diagram) and the ERD (Entity-Relationship Diagram) are complementary modelling tools used together in structured analysis; one models processes and the other models data.

• DFD — Process model: Shows how data flows through the system, the processes that transform data, the external entities, and the data stores. It answers what the system does with the data.
• ERD — Data model: Shows the structure of the stored data: the entities, their attributes and the relationships among them. It answers how the data is organized.

How they relate

1. Data stores in a DFD correspond to entities (or entity sets) in the ERD. Each persistent data store typically maps to one or more entities and their relationships.
2. The DFD shows how data in those stores is created, read, updated and deleted by processes, while the ERD shows the structure and associations of that same data.
3. Both share a common data dictionary, which defines the data elements appearing in DFD flows/stores and in ERD attributes, keeping the two models consistent (balanced).
4. Together they give a complete picture: the DFD = dynamic/process view, the ERD = static/data view of the same system.

Example: In a library system, a DFD data store "Books" corresponds to a Book entity in the ERD, which has attributes (ISBN, Title) and a relationship borrows with the Member entity.

System

A system is a set of interrelated and interdependent components that work together in an organized way to achieve a common goal, by accepting inputs, processing them and producing outputs.

Characteristics of a System

1. Organization — components are arranged in a logical structure/hierarchy.
2. Interaction & Interdependence — components depend on and influence one another.
3. Integration — components form a unified whole, not isolated parts.
4. Central Objective/Goal — every system works toward a defined purpose.
5. Inputs and Outputs — it takes inputs, transforms them and delivers outputs.
6. Boundary and Environment — a system has a boundary separating it from its surroundings.
7. Feedback and Control — outputs are monitored to regulate the system.

Types of Systems (with examples)

• Physical vs Abstract: Physical systems are tangible (computer hardware); abstract systems are conceptual (a mathematical model).
• Open vs Closed: Open systems interact with their environment (a business information system); closed systems are isolated and self-contained (a controlled lab experiment).
• Deterministic vs Probabilistic: Deterministic systems behave predictably (a computer program); probabilistic systems involve uncertainty (weather forecasting).
• Man-made vs Natural: Man-made systems are built by humans (a banking system); natural systems occur in nature (the solar system).
• Adaptive vs Non-adaptive: Adaptive systems adjust to changes in the environment (a living organism, AI system); non-adaptive systems do not.

Fact-Gathering (Fact-Finding) Techniques

Fact-finding is the formal process by which an analyst collects information about the existing system, its problems and the requirements for the new system. The main techniques are:

1. Interviews — Face-to-face questioning of users and managers. Can be structured (fixed questions) or unstructured (open). Gives rich, detailed information and allows clarification, but is time-consuming.
2. Questionnaires — A set of written questions distributed to many respondents. Efficient for gathering data from large, geographically spread groups, though responses may be incomplete and inflexible.
3. Observation — The analyst watches users/operations in the real work environment to see how tasks are actually performed. Reveals facts users may not report, but the presence of an observer can alter behaviour.
4. Record/Document Review — Studying existing documents, forms, reports, manuals and records to understand current procedures and data. Provides factual, historical information but documents may be outdated.
5. Sampling — Examining a representative subset of documents or transactions to draw conclusions when the volume is too large to study fully.
6. JAD / Group Sessions (and Prototyping): Joint Application Development brings users and analysts together in workshops to define requirements quickly and collaboratively.

Analysts usually combine several techniques to cross-check and validate the facts gathered.

Data Dictionary

A data dictionary is a structured, centralized repository that stores the definitions and descriptions of all data elements used in a system. It documents the meaning of every data flow, data store, process and data element appearing in the DFDs and other models, acting as the "data about data" (metadata) of the system.

Contents of a Data Dictionary

For structured analysis a data dictionary typically records:

1. Data Elements (items): name, alias, description, data type, length, allowed values/range, and format.
2. Data Structures / Data Flows: composition of data flows using notation such as = (composed of), + (and), [ | ] (or/selection), { } (repetition / iteration), ( ) (optional).
3. Data Stores: description of stored data and the elements they contain.
4. Processes: brief description of each process and its inputs/outputs.
5. External Entities: sources and destinations of data.

Importance

• Consistency & Standardization: ensures every analyst/programmer uses the same definition for each data item.
• Documentation & Communication: serves as a common reference for the whole team and as system documentation.
• Reduces redundancy & ambiguity: avoids duplicate or conflicting definitions of the same data.
• Supports validation/balancing: helps verify that DFDs and ER diagrams are complete and consistent.
• Eases maintenance: changes to data definitions are managed and traced from one place.

Decision Tables and Decision Trees

Both are tools used in structured analysis to represent complex process logic that involves multiple conditions and resulting actions.

Decision Table

A decision table is a tabular representation showing all combinations of conditions and the corresponding actions. It has four quadrants: condition stub, condition entries, action stub and action entries.

Example — Discount policy: Give 10% discount if the customer is a member AND purchase ≥ Rs 5000; otherwise no discount.

With n conditions there are $2^n$ rules (here $2^2 = 4$).

Decision Tree

A decision tree is a graphical, branching representation of the same logic. The root is the first condition and each branch represents an outcome leading to further conditions or to an action.

Member?
 ├─ Yes ─► Purchase >= 5000?
 │           ├─ Yes ─► Give 10% discount
 │           └─ No  ─► No discount
 └─ No  ─────────────► No discount

Comparison

• A decision table is compact and good for many conditions (easy to check completeness).
• A decision tree is more readable/visual and shows the sequence of decisions clearly, but becomes large when there are many conditions.

Structured English

Structured English is a method of describing process logic (a process specification in a DFD) using a restricted, structured subset of the English language combined with the standard programming control constructs — sequence, selection (IF-THEN-ELSE), and iteration (DO-WHILE / REPEAT). It is precise and unambiguous yet easy for non-programmers to read, avoiding the syntax of a real programming language.

Key rules: use simple imperative verbs, capitalize keywords (IF, THEN, ELSE, DO, WHILE, REPEAT), indent to show structure, and avoid adjectives/adverbs that cause ambiguity.

Structured English for Computing Employee Payroll

BEGIN
    GET employee record (basic_pay, hours_worked, standard_hours)

    REGULAR_PAY = basic_pay

    IF hours_worked > standard_hours THEN
        overtime_hours = hours_worked - standard_hours
        OVERTIME_PAY = overtime_hours * overtime_rate
    ELSE
        OVERTIME_PAY = 0
    ENDIF

    GROSS_PAY = REGULAR_PAY + OVERTIME_PAY + ALLOWANCES

    IF GROSS_PAY > tax_threshold THEN
        TAX = (GROSS_PAY - tax_threshold) * tax_rate
    ELSE
        TAX = 0
    ENDIF

    DEDUCTIONS = TAX + PF + insurance
    NET_PAY = GROSS_PAY - DEDUCTIONS

    PRINT pay slip (GROSS_PAY, DEDUCTIONS, NET_PAY)
END

This specification clearly shows sequence (calculations), selection (overtime and tax conditions) and produces the net pay — readable by users and analysts alike.