Unit I: Basic System Concepts

Basic System Concepts

1. Concept of a System

A system is an integrated collection of components that interact to achieve a common goal.

Examples: educational system, computer system, solar system, etc.

2. Characteristics of a System

• Basic Components: Interrelated elements or parts of a system (e.g., students, teachers in an education system).
• Interaction and Structure: Components interact and form relationships within the system.
• Goal: Systems have a purpose or objective.
• Behavior: How a system reacts to its environment, guided by procedures.
• Life Cycle: Systems have a life span that includes evolution, wear, obsolescence, and end.

3. Elements of a System

• Input: The energizing component on which the system operates (e.g., raw materials, information).
• Processor: Transforms input into output (e.g., logical steps in a computer).
• Output: The result of system operation, often different in form from the input.

4. System Concepts

• Boundary and Environment: Defines what is inside and outside the system.
• Subsystem: Smaller parts of a system that perform specific functions.
• Interface: The interactions between subsystems.
• Black-box: Subsystems whose internal processes are not visible.
• Feedback Control: Mechanism for self-regulation by comparing outputs to standards.

5. Types of Systems

• Conceptual and Physical Systems: Abstract ideas vs. operational systems.
• Deterministic and Probabilistic Systems: Predictable vs. probabilistic outcomes.
• Open and Closed Systems: Interaction with the environment vs. self-contained.
• Natural and Artificial Systems: Naturally occurring vs. human-made systems.

Unit II: System Development Life Cycle (SDLC) Stages [1] [3] [4] [5]

1. Problem Identification

One of the most difficult tasks of systems analysis. Requires clear understanding to avoid wastage of time and energy later. Several questions must be posed, such as:

• What is the actual problem?
• What are the causes of this problem?
• Is it important to solve this problem?
• How complex is it?
• What are the likely solutions to this problem?
• What type of benefit can be expected once the problem is solved?

2. Feasibility Study and Cost Benefit Analysis

Determines if the proposed solution is feasible in terms of:

• Technical feasibility
• Economic feasibility
• Legal feasibility
• Operational feasibility
• Schedule feasibility

Involves cost-benefit analysis to assess the economic viability.

3. System Requirement Analysis

Determines the requirements for a new system. Identifies user requirements to ensure the system is user-friendly. Key questions:

• What outputs are needed?
• What inputs are needed to obtain these outputs?
• What operations are required to produce these outputs?
• What resources must be used?
• What operational and accounting controls are needed?

4. System Design Specifications and Programming

Translates system requirements into technical specifications. Involves:

• Output design
• Input design
• Procedure design
• Information flow design
• File and database design
• Volume analysis
• Form design
• Program specification

5. System Implementation, Follow Up, and Maintenance

Implementation:

• Site preparation
• Installation of new equipment
• User training and seminars
• Use of new inputs and procedures
• Trial and parallel runs of the system
• Gradual phasing out of the old system

Maintenance:

Ongoing process to fix problems and enhance the system. Involves system updates and efficiency improvements.

6. Evaluation of the System

Involves feedback to assess strengths and weaknesses. Includes:

• Development evaluation
• Operational evaluation
• User management assessment

Unit III: Structured System Analysis and Design Method (SSADM) [1] [2] [4][5]

Introduction to SSADM

Structured System Analysis and Design (SSADM): A well-defined approach in system development.

SSADM vs SDLC: SSADM is a modified form of SDLC, using structured techniques.

Limitations of Conventional SDLC

• Limited User Interaction: Users are only involved at the initial stages and during implementation.
• Overwhelming Details for Analysts: Analysts handle extensive business and technical details.
• Physical Focused Tools: Tools like system and program flowcharts focus on physical aspects rather than logical.
• Difficult Maintenance: Changes in user requirements necessitate multiple document modifications.
• Bottom-Up Development: Full package visibility only after completion, making corrections difficult.
• End-of-Project Documentation: Documentation is prepared at the project's end.

Components of SSADM

1. System Survey
2. Structured Analysis
3. Structured Design
4. Hardware Study
5. Implementation
6. Maintenance

Tools in Structured Analysis

• Data Flow Diagram (DFD): Visual representation of data movement.
• Data Dictionary
• Structured English
• Decision Trees
• Decision Tables

SSADM Methodology Steps

1. System Survey

• Identify scope, deficiencies, new system goals, and constraints.
• Prepare documentation including goals, objectives, project life cycle, constraints, and cost-benefit analysis.

2. Structured Analysis

Develop system specifications understandable to users using graphic symbols, DFDs, and DDs.

Sub-Processes in Structured Analysis:

1. Study Current System: Identify external entities, processes, data used, and physical model of the existing system.
2. Derive Logical Equivalent DFD: Create a logical DFD of the current system.
3. Develop Logical Model of New System: Modify logical DFD based on user requirements.
4. Establish Man-Machine Interface: Prepare physical DFDs for the proposed system.
5. Quantify Costs and Benefits: Conduct cost-benefit analysis.
6. Select the Best Option: Determine the best system option based on analysis.
7. Package Specifications: Organize structured specifications including DFDs, DDs, and process descriptions.

3. Structured Design

Transform logical design specifications into technical design specifications. Key activities: input-output design, files and database design, program design, and control design. Use structured charts to document module hierarchy and interrelationships.

4. Hardware Study

Specify configuration details for system implementation based on physical DFDs and DDs. Consider cost and benefits for hardware specifications.

5. Implementation

1. System Acquisition: Purchase hardware, software, and services.
2. Programming: Write and test coded instructions.
3. Testing: Test the combined coded pieces.
4. Conversion: Manage the changeover from old to new system.
5. Documentation: Create design, program, training, operations, and user reference documentation.

6. Maintenance

• Corrective Maintenance: Fix errors and bugs.
• Adaptive Maintenance: Modify system based on user requirements.
• Perfective Maintenance: Improve system performance in terms of response time and resource requirements.

Advantages of SSADM

• Good Documentation: Well-defined documentation for easy understanding.
• Better Communication: Graphical representation like DFDs enhances communication.
• Standardization: Minimal scope for individual approaches, promoting consistency.
• Modularization: Clear picture of smaller modules for thorough system understanding.
• Logical Design: Independent of vendor or hardware specifics.
• User Oriented: Involves users at every stage, reducing rejection risk.
• Maintainability: Easier and cheaper maintenance due to structured methodology.

Unit IV: Fact Finding Techniques and Input/Output Design [1] [2] [3] [5]

Fact Finding Techniques

Introduction: Information gathering in organizations should be systematic to ensure no details are missed, right problems are identified, repetitive work is avoided, and accurate details are collected.

Types:

• Interviewing
• Questionnaires
• Record Inspection
• Observation

Interviewing

Purpose: Collect qualitative information, opinions, policies, suggestions, and identify resistance.

Key Points:

• Put yourself in the interviewee's place.
• Understand before concluding.
• Maintain neutrality and genuine interest.
• Let the interviewee do most of the talking.
• Listen carefully and tactfully bring the interviewee back on track if necessary.
• Be prepared for disagreements and distinguish between fact and opinion.

Questionnaires

Purpose: Supplement interviews, gather numerical data, and obtain collective opinions.

Design Considerations:

• Clear objective.
• Useful structure.
• Easy to understand questions.

Uses: Getting feedback, gathering simple opinions from many people.

Record Review

Purpose: Understand existing systems by examining documents, forms, and files.

Types of Records:

• Written policy manuals
• Rules and regulations
• Standard operating procedures
• Forms and documents

Observation

Purpose: Identify missed facts, improve procedures, and understand actual operations.

Key Points:

• Operational inefficiencies
• Alternate routes and procedures
• Informal communication channels

Data Capture

Stages:

• Original Recording
• Data Transmission
• Data Preparation
• Verification
• Sorting
• Control
• Computer Input

Data Validation

Objective: Detect errors at the earliest stage to avoid costly mistakes.

Validation Checks:

• Field Check (Limit check, Picture check, Valid code check, Check digit, Arithmetic checks, Cross checks)
• Transaction Check (Sequence check, Format completeness, Redundant check, Combination check, Probability check, Passwords, Batch total, Hash total)

Output Design

Importance: Quality output ensures user satisfaction and system effectiveness.

Design Principles:

• Start with output needs
• Consider organization needs
• Effective internal control

Unit V: Data Flow Diagram & Decision-making Methods [1] [2] [3] [4]

Data Flow Diagrams (DFDs)

Meaning

DFDs are graphical aids for defining systems' inputs, processes, and outputs. They represent the flow of data through the system.

Significance

1. Provide a graphic tool for analysts to explain their understanding of the system to the user.
2. Can be converted into a structured chart for design purposes.

Symbols Used

• External Entities: Sources or destinations external to the system (e.g., suppliers, customers).
• Processes: Transformations of data (e.g., verifying credits, updating inventory files).
• Data Flows: Packets of data (e.g., documents, letters).
• Data Stores: Stored data without reference to physical storage methods (e.g., inventory master file).

Rules for Constructing DFDs

1. Processes should be named and numbered.
2. Flow direction is from top to bottom and left to right.
3. When a process is detailed into lower levels, they are numbered.
4. Data stores, sources, and destinations are in capital letters, while process and data flow names are capitalized at the beginning of each word.

Illustration Case Studies

1. Context Level Diagram: For a computer course project involving systems analysis and design in a company.
2. Saving Bank Deposit and Withdrawal System: Prepare a context diagram and zero-level DFD.
3. College Payroll System: Describe the system for computerizing payroll for senior college teachers using DFDs.
4. Railway Reservation System: Prepare a DFD to describe the reservation process.
5. Order Processing System: Draw PDFD and LDFD for order processing activities.
6. Magazine Subscription: Draw a logical DFD for managing magazine subscriptions and reminders.
7. Car Rental Services: Draw physical and logical DFDs for the car rental process.

Decision-making Methods

Decision Table

A visual tool for showing how rules apply to repetitive situations. Represents conditions and possible actions involved in a problem. Consists of conditions, actions, and rules that combine conditions to dictate actions.

Example

A cooperative bank's loan conditions based on customer account status and management approval.

Decision Tree

Graphical representation of decision tables. Used to express process logic and aid in constructing decision tables.

Steps to Draw Decision Table

1. List all conditions and actions.
2. Combine conditions with binary (Yes/No) outcomes.
3. Create a table with rules, conditions, and actions.

Types of Decision Tables

• Limited Entry Decision Table: Simple Yes/No answers for conditions and actions.
• Extended Entry Decision Table: More complex, with descriptive or quantified condition entries.

Structured English

A method to describe procedures using a combination of natural language and structured programming syntax. Useful in decision analysis, program writing, and software development.

Types of Structured English

• Sequential Structures: Single declarative statements in a logical sequence without branching or looping.
• Decision Structures: Use branching instructions with keywords like IF, THEN, ELSE.
• Looping or Repetition Structures: Specify repetition of instructions until a condition is met.

Data Dictionary

Contains information about data elements in a system. Complements DFDs by providing detailed descriptions of data elements, flows, stores, processes, and external entities.

Data Items

• Data Element: Smallest unit of data.
• Data Structure: Group of data elements.
• Data Flows and Data Stores: Data structures in motion (flows) or at rest (stores).