System Analysis and Design -

Complete Study Guide with

Answers
Important: All answers are sourced directly from the official study materials. These are structured for easy
understanding and memorization.

UNIT 1: System Analysis Fundamentals

2 MARKS QUESTIONS & ANSWERS
Q1: What is Information System and Examples

Answer: An information system is an interconnected set of information resources to manage data for a particular
organization under Direct Management Control (DMC). It includes hardware, software, communication, data, and
applications for producing information according to the needs of an organization.

Man-made Information Systems are divided into three types:

1. Formal Information System - Based on the flow of information in the form of memos, instructions, etc., from top
level to lower levels of management.
2. Informal Information System - Employee-based system which solves day-to-day work-related problems.
3. Computer Based System - Directly dependent on the computer for managing business applications (e.g.,
automatic library system, railway reservation system, banking system).

Key Point: These systems collect, process, and distribute information to support decision-making in organizations.

Q2: System Analysis

Answer: System Analysis is a problem-solving technique that improves the system and ensures that all components
work efficiently to accomplish their purpose. It is conducted for the purpose of studying a system or its parts to identify its
objectives.

Structured Analysis - A development method that:

Allows the analyst to understand the system and its activities in a logical way
Uses graphical tools that analyze and refine objectives of an existing system
Develops new system specification easily understandable by users
 Specifies what the system should do (not how to implement it)

Main Focus Areas of SAD:

Systems
Processes
Technology

Q3: System Analyst

Answer: A System Analyst is the professional responsible for:

Using suitable fact-finding techniques to develop and implement the current existing system
Studying system or its parts to identify objectives
Analyzing and improving system components

Core Responsibility: Collecting required facts that are very important to apply tools in System Development Life Cycle
(SDLC) because tools cannot be used efficiently and effectively without proper fact extraction.

Q4: Role of System Analyst

Answer: The system analyst's role includes:

1. Fact Finding & Analysis - Collecting and analyzing facts using various techniques
2. System Understanding - Understanding the system and its activities in a logical way
3. Requirement Definition - Identifying system requirements and objectives
4. Communication - Interacting with users and stakeholders (requires good communication skills for interviews and
interactions)
5. Tool Application - Applying appropriate analysis and design tools
6. Problem Solving - Using problem-solving techniques to improve systems
7. Documentation - Ensuring proper documentation of findings and recommendations

Q5: Categories of Information

Answer: Facts in any information system can be tested based on three steps:

1. Data - Facts used to create useful information

2. Process - Functions to perform the objectives
3. Interface - Designs to interact with users

These three categories form the foundation for developing and implementing effective information systems.

7 AND 15 MARKS QUESTIONS & ANSWERS

Q1: SDLC (Software Development Life Cycle)
 Answer:

Definition: The Software Development Life Cycle (SDLC) is a structured process that encompasses all phases required
to develop and deploy information systems.

The Seven Phases of SDLC:

1. Planning Phase - Identifying project scope, resources, and feasibility

2. Analysis Phase - Gathering and analyzing requirements
3. Design Phase - Creating system architecture and design specifications
4. Prototyping Phase - Building sample/model versions of the system
5. Development Phase - Writing actual code and building the system
6. Testing Phase - Verifying the system works as intended
7. Implementation Phase - Deploying the system to production

Followed by:

Operations Phase - System is running in live environment

Maintenance Phase - Making updates, fixes, and enhancements

Purpose: SDLC provides a systematic approach to software development ensuring quality, efficiency, and effective
project management.

Q2: SDLC TASK

Answer:

SDLC Tasks are the specific activities and deliverables required at each phase of the Software Development Life Cycle:

Planning Phase Tasks:

Define project scope

Identify stakeholders and resources
Develop project plan

Analysis Phase Tasks:

Gather system requirements

Document requirements
Define system objectives

Design Phase Tasks:

Create system architecture

Design databases
Design user interfaces and system components

Development Phase Tasks:

 Write program code
Create program documentation
Develop code per requirements

Testing Phase Tasks:

Execute test cases

Identify and log defects
Verify system requirements are met

Implementation Phase Tasks:

Deploy system to production

Train users
Data conversion and migration

Maintenance Phase Tasks:

Monitor system performance

Fix bugs and issues
Make enhancements and modifications

Q3: SDLC BASELINE

Answer:

SDLC Baseline refers to the approved reference points or checkpoints throughout the Software Development Life Cycle.

Key Baseline Documents:

1. Requirement Baseline - Approved system requirements document

2. Design Baseline - Approved system design specifications
3. Code Baseline - Approved source code and configuration
4. Test Baseline - Approved test plans and test cases
5. Release Baseline - Approved system ready for deployment

Purpose of Baseline:

Provides control and traceability

Acts as reference point for measuring progress
Ensures consistency and quality across phases
Allows configuration management
Enables change control and version management

Importance: Once a baseline is approved, any changes require formal change control processes.

Q4: SDLC ACTIVITIES

 Answer:

SDLC Activities are the specific operational tasks performed during each phase to accomplish the phase objectives:

Major SDLC Activities include:

1. Requirement Analysis - Collecting and understanding business requirements

2. System Design - Creating detailed system specifications and architecture
3. Programming/Coding - Writing source code using programming language
4. Testing - Verifying system functionality and quality
5. Documentation - Recording all processes and decisions
6. User Training - Educating end-users on system usage
7. System Implementation - Deploying system to production
8. System Maintenance - Supporting and updating the system after deployment

Purpose: These activities ensure systematic development following a structured approach, maintaining quality, and
meeting project objectives.

Key Point: SDLC activities must be completed in sequence with proper control and quality assurance at each step.

UNIT 2: Tools for System Analysis

2 MARKS QUESTIONS & ANSWERS
Q1: Forms Design

Answer:

Forms Design is the process of creating business documents for data input and output that consist of specified data with
organized layout and structure.

Definition:

Forms and reports are products of input and output design

Forms are business documents used for collecting data through input fields
Reports are used for reading/displaying information

Examples of Forms:

Order forms
Employment forms
Credit application forms
Registration forms
Survey forms
Purpose: Forms design ensures effective collection, processing, and presentation of data in a systematic and user-
friendly manner.

Q2: Form Design Principles

Answer:

17 Expert Form Design Principles for Easy Memorization:

1. Keep your form simple - Avoid clutter and unnecessary elements

2. Ask only what's necessary - Don't request irrelevant information
3. The path to completion is a straight line down the page - Logical flow from top to bottom
4. Avoid error frustrations of your users - Prevent user confusion and mistakes
5. Never leave your users guessing - Clearly indicate what's working or not
6. Always order form fields from easy to hard - Progress from simple to complex fields
7. Keep group-related information in one block - Organize related fields together
8. Make your user typing experience easy - User-friendly input experience
9. Always indicate if a field is required or optional - Clear marking with * or label
10. Keep your user's contact details in one field - Organize contact information logically
11. Use radio buttons instead of drop-down boxes - Better user interaction
12. Avoid making coupon code fields prominent - Don't emphasize secondary elements
13. Create field focus for mobile phone users - Mobile-responsive design
14. Must avoid placing clear field buttons - Remove functionality that clears form
15. Never use mask passwords on mobile phone users - Allow visible input on mobile
16. Always match the input keyboard for mobile accommodation - Context-appropriate keyboards
17. Limiting your typing options on your website - Restrict entry to valid options

Q3: Pseudo Code

Answer:

Pseudo Code is written code that is close to actual programming language but is used as an intermediate between
Structured English and actual code.

Key Characteristics:

Written closer to programming language than Structured English

Can be considered as augmented programming language full of comments and descriptions
Avoids variable declaration but uses actual programming language constructs
Contains more programming details than Structured English
Uses actual programming language constructs (C, Fortran, Pascal, etc.)
Provides a method to perform the task as if a computer is executing the code

Example (Fibonacci Series):

void function Fibonacci
Get value of n
Set value of a to 1
Set value of b to 1
Initialize i to 0
for i=0 to n
if a greater than b
Increase b by a
Print b
else if b greater than a
increase a by b
print a

Purpose: Pseudo code bridges the gap between design and actual programming implementation.

Q4: ER Model (Entity Relationship Model)

Answer:

Entity Relationship Model (ER Model) is a type of database model based on the notion of real-world entities and
relationships among them.

Definition:

Creates a set of entities with their attributes, constraints, and relations

Best used for the conceptual design of database
Maps real-world scenarios onto ER database model

Key Terms in E-R Model:

1. ENTITY - Specifies distinct real-world items in an application

Example: vendor, item, student, course, teacher

Represented by a rectangle in diagram

2. RELATIONSHIP - Meaningful dependencies between entities

Example: vendor supplies items; teacher teaches courses

"supplies" and "teaches" are relationships
Represented by diamond in diagram

3. ATTRIBUTES - Properties of entities/relationships

Example: vendor code, student name, course title

Represented by ellipse in diagram

Three Types of Relationships:

 One-to-One (1:1) - One entity related to one other entity
One-to-Many (1:M) - One entity related to many entities
Many-to-Many (M:M) - Many entities related to many entities

Purpose: ER Model provides clear representation of data structure and relationships before database implementation.

Q5: Data Dictionary

Answer:

Data Dictionary is the centralized collection of information about data used in the information system.

Alternative Name: Meta-data (data about data) repository

Definition:

Stores meaning and origin of data

Documents data relationships with other data
Specifies data format for usage
Has rigorous definitions of all names to facilitate users and software designers
Created along with DFD (Data Flow Diagram) model
Expected to be updated whenever DFD is changed or updated

Contents of Data Dictionary:

1. Data Flow - Description of data movement in system

2. Data Structure - Organization and composition of data
3. Data Elements - Individual data items with names and descriptions
4. Data Stores - Repositories where data is stored
5. Data Processing - How data is logically and physically processed

Data Elements Include Details:

Primary Name
Secondary Name
Alias
Use-case (how and where to use)
Content Description
Notation
Supplementary Information (preset values, constraints)

Purpose of Data Dictionary:

Removes ambiguity in data usage

Keeps programmers and designers synchronized
Provides complete documentation for database system
Validates DFD correctness
Ensures consistent data naming and usage

7 AND 15 MARKS QUESTIONS & ANSWERS

Q1: TYPES OF FORMS

Answer:

Four Types of Forms Based on Physical Structure:

1. Flat Forms

Single copy form prepared manually or by machine

Printed on paper
For additional copies: carbon papers inserted between copies
Characteristics:
Simplest and inexpensive to design, print, reproduce
Uses less volume of paper
Easy to manage and store

2. Unit Set/Snap-out Forms

Papers with one-time carbons interleaved into unit sets

Can be used for either handwritten or machine use
Carbons Used:
Blue carbons - Best for handwritten forms
Black carbons - Best for machine use
Standard Intensity: Medium intensity grade

3. Continuous Strip/Fanfold Forms

Multiple unit forms joined in continuous strip

Perforations between each pair of forms
Characteristics:
Less expensive method for large volume use
Continuous feeding (suitable for printers)
Easy to separate by perforations
Ideal for high-volume document needs

4. No Carbon Required (NCR) Paper

Uses carbonless papers with two chemical coatings

How it Works:
Two capsules: one on face, one on back of sheet
When pressure applied: capsules interact and create image
No physical carbon required
 Advantages:
Cleaner than carbon paper
More professional appearance
Better image quality
Suitable for modern printing methods

Key Differences Summary: | Type | Cost | Volume | Usage | |------|------|--------|-------| | Flat | Low | Small | Basic | | Unit
Set | Medium | Medium | Organized | | Fanfold | Medium | Large | Bulk | | NCR | Medium-High | Any | Modern |

Q2: DATA FLOW DIAGRAM (DFD)

Answer:

Data Flow Diagram (DFD) is a graphical representation of the flow of data in an information system.

Key Characteristics:

Capable of depicting incoming data flow, outgoing data flow, and stored data
Does NOT mention how data flows through the system (only what flows)
Does NOT contain control or branch elements
Represents data flow at various levels

Difference Between DFD and Flowchart:

Flowchart - Depicts flow of control in program modules

DFD - Depicts flow of data in the system at various levels

DFD Components (4 Main Elements):

1. Entities - Source and destination of information/data

Represented by: Rectangle with names

Example: Customer, Supplier, Bank

2. Process - Activities and actions taken on the data

Represented by: Circle or Round-edged rectangles

Example: Validate Order, Calculate Total

3. Data Storage - Where data is stored

Represented by: Rectangle with both smaller sides missing (like two parallel lines)
Example: Customer Database, Order File

4. Data Flow - Movement of data

Represented by: Pointed arrows showing direction

Source at base of arrow
Destination at head of arrow
 Types of DFD:

1. Logical DFD

Concentrates on system process

Shows flow of data in the system
Independent of implementation
Example: In banking software, how data moves between different entities

2. Physical DFD

Shows how data flow is actually implemented

More specific and close to implementation
Shows actual systems and processes
Includes file names and physical storage details

Levels of DFD:

1. Level 0 (Context Diagram)

Highest abstraction level

Depicts entire information system as one diagram
Conceals all underlying details
Shows external entities and main data flows

2. Level 1 (Detailed DFD)

Level 0 DFD broken down into more specific details

Depicts basic modules in the system
Shows flow of data among various modules
Mentions basic processes and sources of information

3. Level 2 (More Detailed DFD)

Shows how data flows inside modules from Level 1

Further decomposition of processes

Higher level DFDs can be transformed into more specific lower-level DFDs with deeper understanding until desired
specification level is achieved.

Purpose: DFDs help understand system data requirements and communication without focusing on implementation
details.

Q3: HIPO DIAGRAM

Answer:

HIPO - Hierarchical Input Process Output Diagram

Definition: A combination of two organized methods to analyze the system and provide the means of documentation.

Key Points:

Developed by: IBM in 1970

Purpose: Represents the hierarchy of modules in the software system
Focus: High-level view of system functions

What HIPO Does:

1. Represents the hierarchy of modules - Shows module structure

2. Decomposes functions into sub-functions - Breaks down functions hierarchically
3. Depicts functions performed by system - Shows what system does
4. Provides documentation - Serves documentation purpose
5. Graphical representation - Easy for designers and managers to understand

Two Parts of HIPO:

1. Hierarchical Presentation

Shows module hierarchy

Shows relationships between modules
Shows decomposition of functions

2. IPO Chart (Input Process Output)

Input - What goes into module

Process - What module does
Output - What comes out of module

Important Difference:

HIPO vs IPO Diagram:

IPO - Depicts flow of control and data in a module (shows process flow)
HIPO - Does NOT provide information about data flow or control flow
HIPO focuses on hierarchical structure and high-level documentation

Usage:

Used for structure design of software programs

Used for documentation of software systems
Particularly useful for documentation purposes
Helps managers get pictorial idea of system structure

Advantage: Makes it easier for designers, managers, and stakeholders to understand the overall system structure and
function hierarchy.

Q4: STRUCTURED ENGLISH

 Answer:

Structured English is the description of coding requirements using plain English words in a structured programming
paradigm.

Key Characteristics:

1. Plain English Words - Uses everyday English language

2. Structured Format - Follows structured programming paradigm
3. NOT Ultimate Code - Description of what to code, not actual code
4. Independent of Language - Not specific to any programming language
5. Prevents Misinterpretation - Clearer than just diagrams

Why Structured English?

Problem It Solves:

Most programmers are unaware of the large picture of software

Methods using graphs/diagrams may be interpreted differently by different people
Need for clear communication between analysts and developers

Solution:

Both Structured English and Pseudo-Code mitigate the understanding gap

Provides clear description of requirements and implementation approach
Helps programmer write error-free code

Common Structured Programming Tokens (Keywords):

IF-THEN-ELSE
DO-WHILE-UNTIL
FOR loops
CASE statements

Example (Customer Authentication in Online Shopping):

Enter CustomerName
SEEK CustomerName in CustomerNameDB file
IF CustomerName found THEN
Call procedure USERPASSWORDAUTHENTICATE
ELSE
PRINT error message
Call procedure NEWCUSTOMERREQUEST
ENDIF

Key Features:
 Uses same variable and data names stored in Data Dictionary
Makes code simpler to write and understand
More like day-to-day spoken English
Cannot be implemented directly as code
Serves as bridge between requirements and actual programming

Purpose: Structured English enables clear communication of system logic and requirements to programmers, ensuring
they understand exactly what needs to be coded.

Q5: BASIC FLOWCHART SYMBOLS

Answer:

Flowchart is a graphical representation showing process flow and logic between ideas and concepts.

5 Most Popular and Commonly Used Flowchart Symbols:

1. The Oval or Pill Shape

Represents: START / END

Purpose: Indicates beginning or end of a process
Usage: First and last elements in flowchart
Example Labels: "Start", "End", "Begin", "Stop"

2. The Rectangle Shape

Represents: PROCESS
Purpose: Shows a process or operational step
Usage: Main action or transformation of data
Example Labels: "Calculate Total", "Validate Input", "Process Order"

3. The Parallelogram Shape

Represents: INPUT / OUTPUT

Purpose: Shows input of data or output of results
Usage: Reading data or displaying information
Example Labels: "Read Customer Name", "Print Report", "Enter Data"

4. The Diamond Shape

Represents: DECISION
Purpose: Shows a decision point with branching paths
Usage: Conditional logic (IF-THEN-ELSE)
Example Labels: "Is Amount > 1000?", "Valid Y/N?", "Success?"
Note: Usually has two or more exits (Yes/No or True/False)

5. The Arrow Shape

 Represents: FLOW OF SEQUENCE
Purpose: Shows direction of flow from one symbol to another
Usage: Connects all symbols indicating sequence
Direction: Arrow head points to next step

How to Use Flowchart Symbols:

Connect symbols with arrows showing flow direction

Follow sequence from top to bottom and left to right
Start with Oval (Start)
End with Oval (End)
Use rectangles for actions/processes
Use diamonds for decisions
Use parallelograms for input/output

Flowchart Purposes:

Depict process a company follows to create its products

Provide information about company history
Explain organizational structure
Outline main steps of an activity
Show process flow or data flow diagrams

Key Benefit: Visual representation makes it easier to understand, communicate, and analyze system processes.

UNIT 3: Design Phase

2 MARKS QUESTIONS & ANSWERS
Q1: Fact Finding Techniques

Answer:

Fact Finding Techniques are specific methods for finding and collecting information of the system used by system
analysts.

Definition:

Process of collection of data and information based on techniques

Includes: sampling, research, observation, questionnaires, interviews, prototyping, JRP
System analyst uses suitable techniques to develop and implement current system
Crucial for applying tools in SDLC effectively

When Used:
 Early stage of SDLC
System analysis phase
Design phase
Post-implementation review

Seven Common Fact-Finding Techniques:

1. Sampling of existing documentation, forms and databases

2. Research and Site visits
3. Observation of the work environment
4. Questionnaires
5. Interviews
6. Prototyping
7. Joint Requirements Planning (JRP)

Why Important:

Collecting required facts is very important for applying SDLC tools

Tools cannot be used efficiently and effectively without proper fact extraction
Facts form the foundation for system analysis and design

Q2: What is Fact Analysis

Answer:

Fact Analysis is the process of collecting and interpreting facts, identifying problems, and decomposition of a system
into its components.

Definition:

A factual analysis isolates relevant facts

Helps expose the legal question and issues
Requires practice to perform effectively

How to Perform Fact Analysis:

PEC Method (Parties, Events, Claims):

Parties - Who is involved

Events - What happened
Claims - What are the outcomes/arguments

Techniques Used for Fact Analysis:

1. Interview - Face-to-face information collection

2. Questionnaire - Survey-based information
3. Record View - Reviewing existing documentation
4. Observations - Direct observation of processes
 Purpose of Fact Analysis:

Isolate relevant facts from data

Identify system problems
Decompose system into components
Form basis for system improvements
Understand current system thoroughly

Relationship to System Analysis:

System analysis uses fact analysis results

System analysis = problem-solving technique that improves system
Ensures all system components work efficiently

Q3: Design Phase

Answer:

Design Phase is the phase that bridges the gap between problem domain and existing system in a manageable way.

Key Definition:

Focuses on solution domain (HOW to implement)

Converts SRS (Software Requirements Specification) document into format that can be implemented
Decides how the system will operate
Essential phase of the Software Development Life Cycle

What Happens in Design Phase:

One or more designs are created to achieve project result

Products include: diagrams, flowcharts, sketches, site trees, HTML designs, prototypes, UML schemas
Project supervisors choose definitive design for production
Development phase follows design phase

Important Note:

Once design is selected, cannot make changes in later project stages

Must be done carefully and thoroughly

Design Phase Participants and Roles:

Participant Role
Customer Sponsors project, signs-off effort, reviews strategy
Business
Provides requirements, reviews design and artifacts
Analyst
Project
Finalizes data conversion and test strategy
Manager
 Participant Role
Technical Most crucial role - describes functions, operations, database layout;
Architect provides architectural plan
Design Team Designs architecture and software components
Developer
Assists in data conversion strategy, reviews architecture
Team
Testing Team Identifies and finalizes testing strategy
Database
Assists in architecture design and data conversion
Team

Technical Architect's Role (Most Important):

Describes required functions and operations in detail

Screen layout design
Business rules definition
System database layout
Provides architectural plan down to physical level

Q4: Structure Design

Answer:

Structure Design is a data-flow based methodology for identifying input and output of the developing system.

Key Definitions:

1. Structured Design - Conceptualization of problem into several well-organized elements of solution

Basically concerned with solution design

Data-flow based methodology
Identifies input and output of developing system

2. Structural Design - Methodical investigation of stability, strength, and rigidity of structures

Basic objective: produce structure capable of resisting loads without failure

Technical engineering focus

Main Objectives of Structured Design:

1. Minimize Complexity - Reduce system complexity

2. Increase Modularity - Build modular, manageable components
3. Describe Functional Aspects - Clearly specify what system does
4. Improve Understanding - Provide better understanding of problem solution

Benefits of Structured Design:

1. Better Understanding - Clear picture of how problem is being solved

2. Future System Definition - Tool to define system that will be live
 3. System Analysis - Analyze working of system and different modules
4. Interaction Understanding - Understand interactions between modules
5. Data Flow Visibility - See type of data modules use or share

Tools Used: Structured Chart

Structured Chart consists of 3 elements:

1. Module

Single unit of system performing unique task

Represented by rectangle
Name inside defines action performed
System has various functional units divided into sub-units (modules)

2. Connection

Defines interaction between different modules

Shows relationship to each other
Shows flow of operations and control
Represented by vector (arrow)
Directed towards module from higher level
Passes data from lower to higher level modules

3. Couple

Describes data items or parameters passed to modules from parent module

Identifies information formed from different modules
Input to module and output from module necessary for task performance
Represented by arrow with circular tail and parameters attached

Usage: Structured Design analyzes system working, module interactions, and data usage to create well-organized
solution.

7 AND 15 MARKS QUESTIONS & ANSWERS

Q1: Fact Finding Techniques (Detailed)

Answer:

Seven Common Fact-Finding Techniques with Detailed Explanation:

1. Sampling of Existing Documentation, Forms and Databases

What It Is:

Process of combining representative sample of documents, forms, and records

Best way to analyze existing system is collect facts from documentation rather than human sources
 Documents to Collect:

Emails and communications

Customer complaints
Suggestion box notes
Problem area reports
Performance reviews
Samples of completed manual forms and reports
Samples of completed computerized forms and reports
Flowcharts and diagrams
Program documentation
User training manuals

Sampling Techniques:

Randomization - Process of selecting sample data randomly

Stratification - Systematic process to reduce variance of sampling data

Benefit: Better understanding of system due to analysis of existing documents, forms, files related to current system

2. Research and Site Visits

What It Is:

Process of examining problems that had previously been solved by other sources
Can be human or document sources
Analyst visits organization that previously experienced similar problems

Information Sources:

Databases
Reference books
Case studies
Internet
Other organizations

Advantages:

Can save time if problem already solved

Researcher knows how different people previously solved same problems
Always know detailed information about current development system

Disadvantages:

Need authority to access appropriate source of information

As documentation of problem is not recorded, difficult to solve problem
May not be directly applicable to your specific situation
 3. Observation of the Work Environment

What It Is:

System analyst participates in organization

Studies flow of documents
Applies existing system
Interacts with users

How It Works:

Analyst directly observes how work is performed

Can be useful technique when analyst has user point of view
Uses work sampling technique to observe how employees spend their days

Advantage: Get realistic view of actual system operation and user behavior

4. Questionnaires

What It Is:

Useful fact-finding technique to collect information from large number of users

Users fill questions given by analyst and return answers

Advantages:

Saves time (don't need to interview each user individually)

People can fill forms and give answers freely
Inexpensive technique
Users more willing to respond real answers (don't need give personal information)
Responses can be calculated and analyzed quickly

Disadvantages:

Incomplete answers received from users

Analyst cannot observe body language
Analyst has no chance to clarify vague/incomplete responses
Good questionnaires difficult to prepare

Types of Questionnaires:

1. Free-Format Questionnaires

Users allowed to answer freely without immediate response

Results useful in learning feelings, opinions, experiences of respondents

2. Fixed-Format Questionnaires

Gather information from predefined format

 Users choose from given answers

Types of Fixed-Format Questions:

Multiple-choice questions
Yes or No type
Rating questions (Strongly agree, Agree, No opinion, Disagree, Strongly disagree)
Ranking questions (numbering according to preferences)

5. Interviews

What It Is:

Most commonly used technique to collect information

Face-to-face interaction between system analyst and users/owners

Purpose:

Find, verify, clarify facts

Motivate end-users involved
Identify requirements
Gather ideas and opinions

Participants:

Interviewer - System analyst

Interviewee - System owner or user

Requirements:

Good communication skills for interaction between analyst and user

Two Types of Interviews:

1. Unstructured Interviews

Conducted with only general goal/subject in mind

Few, if any, specific questions
Uses open-ended questions type allowing user to answer freely in appropriate way
More conversational approach

2. Structured Interviews

Contains predefined set of questions

Uses close-ended questions type limiting answers to specific choices
Short and direct responses from interviewees
More formal and controlled approach

Advantages:
By motivating interviewees, they have confidence to answer more effectively
System analyst can examine more feedbacks
Analyst can prepare questions suitable for interviewees or change for each individual
Analyst can know nonverbal communications by perceiving body movements and facial expressions
Personal touch and rapport building

Disadvantages:

Time consuming and costly mechanism

Communication skills of analyst affect success of interview
Not scalable to large number of users
May require travel for on-site interviews

6. Prototyping

What It Is:

Sampling a small working model of the system

More related to pre-design of information system
Implementation can be developed in earlier stage of SDLC during analysis phase
Also known as discovery prototyping when used for specifying user requirements

Advantages:

Users and developers can test and understand system in advance before final implementation
Determine development of system before applying high development costs
Kind of training mechanism for users
Requires less time on fact-finding
Useful in defining constant and consistent requirements
Early feedback and validation

Disadvantages:

Training of developers is requirement

Users may misunderstand performance, reliability, features of prototype as real results
Development cost and schedule may change
Need user training to understand prototype covers functionality but not complete system
May create false expectations

7. Joint Requirements Planning (JRP)

What It Is:

Structured group work meeting to identify, analyze problems and define system requirements
Increasingly common in systems planning and systems analysis
Obtain group consensus on problems, objectives, requirements
 Participants with Specialized Roles:

1. Sponsor

Individual in top management

Full authority to decide participants, time, location of JRP session
Final decision maker

2. Facilitator

Leads JRP session

Motivates participants
Solves conflicts
Ensures meeting requirements met

3. Users and Managers

Users: responsible for business rules, requirements, prototype, decisions

Managers: responsible for projects, schedules, costs, training requirements

4. Scribes

Record everything discussed in meeting

Document decisions and action items

5. IT Staff

Responsible for models and documentation

Technical expertise during discussion

Advantages:

Different individuals with various roles

Covers both users and management levels
Saves time (not required one-on-one interviewing of each participant)
When JRP incorporates prototyping benefits of prototyping realized
Group consensus achieved
Efficient fact tabulation in short time
Can replace numerous separate interviews

Disadvantages:

Extensive training required (group form)

Active participation of all individuals essential for success
Requires coordination and scheduling
May be dominated by strong personalities
Need skilled facilitator
 Q2: Element of a System

Answer:

Elements of a System are the components that make up any system. Every system consists of the following six
elements:

1. Outputs and Inputs

Inputs:

Information that enters into system for processing

Source of raw data and information

Outputs:

Outcome of processing
Result/product produced by system
Main aim of system is to produce output useful for its user

Example: In banking system, transaction data is input; account statement is output

2. Processors

What It Is:

Element of system involving actual transformation of input into output

Operational component of system
Core processing mechanism

How It Works:

Modifies input either totally or partially depending on output specification

As output specifications change, processing changes
Input may also be modified to enable processor for transformation

Example: Calculation engine that transforms raw data into meaningful information

3. Control

What It Is:

Element that guides the system

Decision-making subsystem controlling pattern of activities
Controls: input, processing, and output

How It Works:

In computer systems, controlled by Operating System and software

 What and how much input is needed determined by Output Specifications
Ensures system operates within defined parameters

Example: Operating system controlling resource allocation and data flow

4. Feedback

What It Is:

Provides control in dynamic system

Information returned to control mechanism

Two Types:

1. Positive Feedback

Routine in nature
Encourages performance of system
Motivates continuation

2. Negative Feedback

Informational in nature
Provides controller with information for action
Enables corrective measures

Purpose: Enables system to adjust and improve its operation

5. Environment

What It Is:

Supersystem within which organization operates

Source of external elements striking on system
Determines how system must function

External Factors:

Vendors
Competitors
Government regulations
Market conditions
Customer expectations

Impact: Provides constraints and opportunities affecting system performance

Example: Market competition affects how business system must function

 6. Boundaries and Interface

What It Is:

Boundaries: Limits that identify system components, processes, interrelationships

Determine sphere of influence and control of system
When system interfaces with another system

Importance:

Crucial for determining nature of interface with other systems

Essential for successful design
Defines what is part of system and what is external

Interface:

Connection point between this system and other systems

Standardized connection ensuring compatibility
Defines how data/control flows between systems

Example: In company, boundaries separate HR system from Finance system; interface allows data exchange

Q3: Types of System

Answer:

Systems can be classified into various types based on different characteristics:

1. Physical or Abstract Systems

Physical Systems:

Tangible entities
Can touch and feel them
Static Physical System - Doesn't change (e.g., desks and chairs in computer center)
Dynamic Physical System - Changes according to needs (e.g., programmed computer with changing programs,
data, applications)

Abstract Systems:

Non-physical entities
Conceptual in nature
Formulas, representation, or model of real system
Example: Information system, organizational structure

2. Open or Closed Systems

Open Systems:
Must interact with environment
Receives inputs from outside and delivers outputs outside
Example: Information system which must adapt to changing environmental conditions
Responsive to environmental changes

Closed Systems:

Does not interact with environment

Isolated from environmental influences
No external input/output
Note: Completely closed system is rare in reality

3. Adaptive and Non-Adaptive System

Adaptive System:

Responds to change in environment

Improves performance and survives
Examples: Human beings, animals, living organisms

Non-Adaptive System:

Does not respond to environment

Fixed behavior
Example: Machines, mechanical systems

4. Permanent or Temporary System

Permanent System:

Persists for long time

Continues indefinitely
Example: Business policies, organizational structure

Temporary System:

Made for specified time

Demolished after purpose achieved
Example: DJ system set up for program and dismantled after program; project team for specific project

5. Natural and Manufactured System

Natural Systems:

Created by nature
Not human-made
Examples: Solar system, seasonal system, weather systems, biological systems
 Manufactured System:

Man-made system
Created by human beings
Examples: Rockets, dams, trains, computers, software systems

6. Deterministic or Probabilistic System

Deterministic System:

Operates in predictable manner

Interaction between components known with certainty
Output is definite and known
Example: Two molecules of hydrogen + one molecule of oxygen = water (always)

Probabilistic System:

Shows uncertain behavior

Exact output not known with certainty
Behavior depends on probability
Examples: Weather forecasting, mail delivery, stock market prediction

7. Social, Human-Machine, and Machine System

Social System:

Made up of people
Human-based system
Examples: Social clubs, societies, organizations, communities

Human-Machine System:

Both human and machines involved

Collaborative work between people and systems
Example: Computer programming (programmer + computer)

Machine System:

Human interference neglected or minimized

All tasks performed by machine
Automated system
Example: Autonomous robot, automated manufacturing line

Q4: Types of Feasibilities

Answer:
Feasibility Study - Preliminary investigation helping management decide whether system should be developed.

Types of Feasibilities Analyzed:

1. Economic Feasibility

What It Is:

Evaluating effectiveness of candidate system using cost-benefit analysis method

Demonstrates net benefit in terms of benefits and costs to organization

Purpose:

Estimate economic requirements of candidate system before committing investment funds

Prefer alternative maximizing net worth of organization
Achieve earliest and highest return of funds
Maintain lowest level of risk in developing candidate system

How to Analyze:

Compare benefits vs. costs

Calculate return on investment (ROI)
Analyze payback period
Consider ongoing maintenance costs

Decision: Feasible if benefits exceed costs

2. Technical Feasibility

What It Is:

Investigates whether solution can be supported by existing technology

Determines if current technical resources can be upgraded or added

Questions to Answer:

Can solution be built with current technology?

Do we have necessary hardware and software?
Can current systems integrate with new system?
Do we need new technology investments?

Analysis Includes:

Current technical resources inventory

Required technology specifications
Technology gaps identification
Upgrade or acquisition costs

Decision: Feasible if organization can obtain necessary technology

 3. Operational Feasibility

What It Is:

Determines whether system will operate effectively once developed and implemented
Ensures management supports proposed system
Works feasible in current organizational environment

Considerations:

Will users accept the system?

Can current organizational structure support it?
Are computer resources and network architecture workable?
Will business methods changes be accepted?

Analysis Includes:

User readiness and acceptance

Organizational readiness
Resource availability
Process compatibility
Staff skill levels

Decision: Feasible if organization can successfully operate the system

4. Behavioral Feasibility

What It Is:

Evaluates and estimates user attitude or behavior towards development of new system
Determines if special effort needed for user education, retraining, or organizational change

Considerations:

Will users accept changes?

Is workforce willing to adapt?
What is user attitude?
Are there change management concerns?

Analysis Includes:

Employee attitudes and concerns

Need for training and retraining
Job changes and impact
Change management requirements
Resistance to change identification

Decision: Feasible if users and organization ready for change

 5. Schedule Feasibility

What It Is:

Ensures project completed within given time constraint or schedule

Verifies project deadlines are reasonable

Considerations:

Can development be completed in required timeframe?

Are milestone dates achievable?
Is timeline realistic?

Analysis Includes:

Project scope and complexity

Resource availability
Team skills and experience
Realistic timeline development
Buffer for contingencies

Decision: Feasible if project can be completed within acceptable timeframe

Q5: Types of System Design

Answer:

System Design Types based on level of detail and focus:

1. Logical Design

What It Is:

Pertains to abstract representation of data flow, inputs, and outputs of system

Independent of how system will actually be built
Focuses on what needs to be done

Describes:

Input sources
Output destinations
Databases/data stores
Procedures/data flows
All in format meeting user requirements

Analysis Level:

System analyst specifies user needs at level of detail

 Virtually determines information flow into/out of system
Identifies required data sources

Tools Used:

Data Flow Diagram (DFD)

Entity-Relationship (E-R) diagram
Data modeling

Characteristics:

User-focused
Platform-independent
Shows logical relationships
Documents requirements

Output: Clear understanding of what system should do

2. Physical Design

What It Is:

Relates to actual input and output processes of system

Focuses on how system will be implemented
Produces working system by defining design specifications

Focus Areas:

How data is entered into system

How data is verified
How data is processed
How data is displayed as output
User interface design
Process design
Data design

Design Specification:

Specifies exactly what candidate system does

Detailed technical specifications

Steps in Physical Design:

1. Input/Output Media Specification

What input devices will be used

What output devices will be used
Physical storage media
2. Database Design

Physical database structure

File organization
Indexing strategy
Storage allocation

3. Backup Procedures

Data backup strategy

Recovery procedures
Disaster recovery plan

4. System Implementation Planning

Devising test plan

Implementation plan
Specifying new hardware and software needed

5. Update Costs and Constraints

Updating costs based on physical design

Updating benefits
Updating conversion dates
Considering system constraints

Output: Detailed specifications ready for development team

3. Architectural Design

What It Is:

Also known as high-level design

Focuses on design of system architecture
Describes structure and behavior of system

What It Defines:

Structure of system
Relationship between various modules
System development process organization
High-level components and their interactions

Characteristics:

Overview level detail

Shows major components
Shows inter-component relationships
 Guides detailed design and development

Output: System architecture blueprint

4. Detailed Design

What It Is:

Follows Architectural design

Focuses on development of each module
Most granular level of design detail

What It Includes:

Detailed specifications for each module

Component internal logic
Data structures for each module
Algorithm specifications
Interface specifications between modules
Error handling for each module

Characteristics:

Development team level detail

Implementation-ready specifications
Module-by-module approach
Guides actual coding

Output: Ready for programmers to begin coding

Q6: Input and Output Design

Answer:

Input and Output Design relates to the way data enters and exits the system.

Inputs to System Design (What the Design Phase Receives):

1. Statement of Work - Description of work to be done

2. Requirement Determination Plan - How requirements were gathered
3. Current Situation Analysis - Analysis of existing system
4. Proposed System Requirements including:
Conceptual data model - Entity relationships
Modified DFDs - Refined data flow diagrams
Metadata - Data about data definitions

Outputs from System Design (What the Design Phase Produces):

 1. Infrastructure and Organizational Changes

Hardware infrastructure needed

Software infrastructure needed
Organizational structure changes
Staffing requirements
New processes or procedures

2. Data Schema

Often a relational schema

Database structure definition
Table relationships
Keys and constraints

3. Metadata (Data about Data)

Defines tables/files and columns/data-items

Describes data elements
Documents data meanings
Specifies data formats
Documents data validation rules

4. Function Hierarchy Diagram or Web Page Map

Graphically describes program structure

Shows function hierarchy
Shows page relationships (for web systems)
Module organization overview

5. Actual or Pseudocode for Each Module

Detailed logic for each module

Algorithm specifications
Either actual code or pseudo-code
Ready for development team

6. Prototype for Proposed System

Sample/model of system
User interface prototype
System functionality demonstration
User validation model

UNIT 4: Object-Oriented Approach

 2 MARKS QUESTIONS & ANSWERS
Q1: Define Object Oriented

Answer:

Object-Oriented (OO) Approach is a software development methodology based on organizing software into objects.

Key Concepts:

1. Objects - Contain both data and methods/functions that operate on that data
2. Classes - Blueprint or template for creating objects
3. Encapsulation - Bundling data and methods together
4. Inheritance - Objects can inherit properties from parent classes
5. Polymorphism - Objects can take many forms

Main Characteristics:

Data and functionality combined in objects

Objects interact with each other
Reusable code through classes
Models real-world entities more naturally

Difference from Structured Approach:

Structured - Focuses on functions/processes (procedure-oriented)

Object-Oriented - Focuses on data and operations together (object-oriented)

Benefits:

Better code organization

Improved code reusability
Easier maintenance
Models real-world concepts effectively

Q2: Activity Diagram

Answer:

Activity Diagram is a graphical representation showing flow of activities or processes in a system.

Key Characteristics:

UML (Unified Modeling Language) diagram

Shows sequence of activities
Shows decision points and branches
Shows parallel activities
Similar to flowchart but more focused on activities
 Purpose:

Visualize workflow or business processes

Show activity sequence and dependencies
Display decision logic
Represent concurrent activities

Common Elements:

Activity (action or task)

Decision (branching)
Fork (parallel activities beginning)
Join (parallel activities merging)
Flow arrows connecting elements

Usage: Used in analysis and design phases to document processes

Q3: Notation of Diagram

Answer:

Notation of Diagram refers to the symbols and conventions used in drawing diagrams.

Key Points:

Each symbol has specific meaning

Consistent notation enables universal understanding
Different diagram types have different notations

Examples of Notations:

In DFD:

Circle/bubble = Process
Rectangle = Entity
Parallel lines = Data store
Arrow = Data flow

In Flowchart:

Oval = Start/End
Rectangle = Process
Diamond = Decision
Parallelogram = Input/Output

In E-R Diagram:

Rectangle = Entity
 Diamond = Relationship
Ellipse = Attribute

In UML Diagrams:

Various specific symbols for classes, objects, relationships

Importance:

Clear communication
Standardization
Easy interpretation
Professional documentation

Q4: Benefits of Sequence Diagram

Answer:

Sequence Diagram is a UML diagram showing interaction between objects over time.

Benefits:

1. Clear Interaction Visualization

Shows how objects interact

Display message flow between objects
Easy to understand object interactions

2. Time-Based Representation

Shows sequence of interactions over time

Top to bottom flow shows progression
Easy to follow timeline

3. Message Communication

Shows exact messages passed between objects

Documents communication protocols
Clarity in message content and order

4. Scenario Documentation

Documents specific scenarios

Shows alternative flows
Exception handling visualization

5. Requirements Verification

Validates system requirements

 Shows how requirements are implemented
Helps identify missing interactions

6. Design and Testing Support

Supports design decisions

Helps in test case creation
Documents expected behavior

7. Improved Communication

Better team understanding

Clear specification for developers
Easier stakeholder communication

Q5: Purpose of Models

Answer:

Purpose of Models in System Analysis and Design:

Key Purposes:

1. Visualization

Make abstract concepts concrete and visual

Help stakeholders understand system better
Show structure and relationships

2. Communication

Communicate ideas clearly

Common language for team
Bridge gap between business and technical people

3. Documentation

Document system design

Create reference for future maintenance
Keep knowledge for organizational continuity

4. Analysis

Analyze system structure and behavior

Identify problems and issues
Test design ideas

5. Design Support
 Guide design decisions
Show alternative designs
Validate design approach

6. Risk Reduction

Identify issues early

Test concepts before implementation
Reduce development risk

7. Blueprint for Development

Guide programmers on what to build

Document specifications
Ensure consistent implementation

Types of Models:

Data models (E-R diagram)

Process models (DFD, activity diagram)
Behavioral models (sequence diagram, state diagram)
Structural models (class diagram, component diagram)

Q6: Class Diagram Benefits

Answer:

Class Diagram is a UML diagram showing classes, attributes, methods, and relationships.

Benefits:

1. System Structure Representation

Shows overall structure of system

Displays all classes and components
Shows relationships between classes

2. Data Modeling

Shows what data each class contains

Documents attributes and their types
Shows data relationships

3. Behavior Specification

Shows what methods/operations each class has

Documents class responsibilities
Shows functionality associated with data
4. Relationship Clarity

Shows associations between classes

Documents inheritance hierarchies
Shows dependencies

5. Design Foundation

Serves as foundation for code development

Guides programmer implementation
Documents design decisions

6. Code Generation

Supports automatic code generation

Ensures consistency between design and code
Reduces development time

7. Documentation and Communication

Documents system design

Communicates design to team
Reference for system understanding
Easier maintenance and future changes

8. Quality and Maintainability

Better organized code

Easier to maintain and update
Better for long-term support

7 AND 15 MARKS QUESTIONS & ANSWERS

Q1: ELEMENTS OF OO SYSTEM

Answer:

Elements of Object-Oriented (OO) System are the fundamental building blocks:

Basic Elements:

1. Object

Instance of class
Contains data (attributes) and behavior (methods)
Self-contained unit with state and behavior

2. Class
 Blueprint or template
Defines structure of objects
Contains attributes and methods
Multiple objects created from one class

3. Attributes

Data/properties of class
Characteristics of objects
Hold state information

4. Methods/Operations

Functions/procedures of class
Define behavior of objects
Operations performed on attributes

5. Encapsulation

Bundling data and methods together

Hiding internal details from outside
Accessing data only through defined methods
Provides data protection and security

6. Inheritance

Child classes inherit from parent classes

Reuse parent class properties and methods
Establish hierarchical relationships
Supports code reusability

7. Polymorphism

Objects can take many forms

Methods can have same name but different behavior
Enables flexible and extensible code
Reduces code complexity

8. Abstraction

Hide unnecessary details

Show only essential features
Simplify complex systems
Focus on what not how

Additional Elements:

Messages/Communication:
 Objects communicate by sending messages
Request for action from one object to another
Parameters may be passed with messages

Relationships:

Association - Objects related to each other

Composition - One object contains another
Aggregation - Collection of objects

Q2: STRUCTURED AND OO APPROACH (Comparison)

Answer:

Comparison between Structured and Object-Oriented Approaches:

Aspect Structured Approach Object-Oriented Approach

Functions/Processes
Focus Objects (Data + Functions combined)
(Procedure-oriented)
Building Blocks Functions, procedures, modules Objects and classes
Data Data bundled with functions
Data separate from functions
Organization (encapsulation)
Code
Limited reusability High reusability through inheritance
Reusability
Changes in one place may Changes localized to classes (easier
Maintainability
affect others maintenance)
Difficult to scale for large Better scalability for large, complex
Scalability
systems systems
Modeling Real- Difficult - breaks down into Natural - models real-world entities as
World functions objects
Design Collaborative objects with defined
Top-down decomposition
Approach interactions
Flexibility Less flexible for changes More flexible and extensible
Learning Curve Easier to learn Steeper learning curve
Examples C, Pascal, COBOL Java, C++, Python, C#, .NET
Not supported (in traditional
Inheritance Fully supported
structured)
Polymorphism Not available Fully supported
Encapsulation Weak or no encapsulation Strong encapsulation
Data Hiding Limited data protection Strong data hiding
Concurrency Difficult to manage Better concurrent object support
Testing Test functions individually Test objects and interactions
Typical Use Small to medium projects Medium to large projects

Q3: TYPES OF MODELS

Answer:
 Types of Models in System Analysis and Design:

1. Data Models

Purpose: Represent data structure and relationships

Examples:

Entity-Relationship (E-R) Model - Shows entities and relationships

Relational Model - Shows tables and relationships
Object Data Model - Objects with attributes
Hierarchical Model - Tree-like structure
Network Model - Complex relationships

2. Process Models

Purpose: Show what processes/activities system performs

Examples:

Data Flow Diagram (DFD) - Shows data flow and processes

Activity Diagram - Shows sequence of activities
Business Process Model - Workflow representation
State Diagram - Shows state transitions
Flowchart - Process flow visualization

3. Behavioral Models

Purpose: Show how system behaves and interacts

Examples:

Sequence Diagram - Interaction between objects over time

State Machine Diagram - State transitions and events
Use Case Diagram - System functionality from user perspective
Collaboration Diagram - Object interactions

4. Structural Models

Purpose: Show organization and structure of system

Examples:

Class Diagram - Classes, attributes, methods, relationships

Component Diagram - System components and dependencies
Deployment Diagram - System hardware deployment
Object Diagram - Object instances and relationships
Package Diagram - Packages and dependencies
 5. Static Models

Purpose: Show system structure at specific point in time

Examples:

E-R Diagram
Class Diagram
Component Diagram

6. Dynamic Models

Purpose: Show system behavior over time

Examples:

Sequence Diagram
Activity Diagram
State Diagram
Use Case Diagram

Selection of Models Based on System Type:

Data-focused System - Use data models (E-R, relational)

Process-focused System - Use process models (DFD, activity)
Object-Oriented System - Use OO models (class, sequence, use case)
Complex System - Combine multiple model types

Q4: UML CLASS DIAGRAM (**)

Answer:

UML Class Diagram is a static structural diagram showing classes, attributes, methods, and relationships.

What is Class Diagram:

Most commonly used UML diagram

Represents static structure of system
Shows classes and their relationships
Foundation for object-oriented design

Components of Class Diagram:

1. Class (Box with Three Sections)

Structure:
┌─────────────────────────┐
│ Class Name │ ← Class Name
├─────────────────────────┤
│ -attribute1: type │ ← Attributes (data members)
│ -attribute2: type │
├─────────────────────────┤
│ +method1(): returnType │ ← Methods (operations)
│ +method2(): returnType │
└─────────────────────────┘

Sections:

1. Top Section - Class name

2. Middle Section - Attributes (data/properties)
3. Bottom Section - Methods (operations/functions)

Visibility Modifiers:

+ (Public) - Accessible from anywhere

- (Private) - Accessible only within class
# (Protected) - Accessible within class and subclasses
~ (Package) - Accessible within package

2. Relationships Between Classes

Association

Simple relationship between classes

One class uses another
Represented by: Line between classes
With labels showing relationship
Multiplicity indicators (1, , 0..1, 1..)

Inheritance (Generalization)

Child class inherits from parent class

"IS-A" relationship
Represented by: Arrow pointing to parent class
Example: Student IS-A Person

Composition

Whole-part relationship (strong ownership)

Child cannot exist without parent
Represented by: Solid diamond at parent end
Example: House composed of Rooms
 Aggregation

Whole-part relationship (weak ownership)

Child can exist independently
Represented by: Empty diamond at parent end
Example: Team aggregates Players

Dependency

One class depends on another

Temporary relationship
Represented by: Dashed arrow

3. Multiplicity Notation

1 - Exactly one
0..1 - Zero or one
* - Zero or more
1..* - One or more
0../* - Zero or more
2..5 - Two to five

Example Uses:

1:1 (One-to-One)
1:* (One-to-Many)
: (Many-to-Many)

How to Read Class Diagram:

1. Identify Classes - What entities does system have?

2. List Attributes - What data does each class hold?
3. List Methods - What operations each class performs?
4. Identify Relationships - How do classes relate?
5. Check Multiplicity - How many objects participate?

Example Class Diagram Structure:

Person
├─ Attributes: name, age, address
├─ Methods: getName(), setName()
└─ Relationships:
└─ Inheritance: Student (child), Employee (child)
└─ Student
├─ Attributes: studentID, major
├─ Methods: getStudentID()
└─ Relationships:
└─ Association with Course (Many-to-Many)

Benefits of Class Diagram:

1. Design Clarity - Clear system structure

2. Code Generation - Generate code from diagram
3. Documentation - Visual documentation of design
4. Team Communication - Shared understanding
5. Database Design - Foundation for database schema
6. Validation - Check completeness of design
7. Maintenance - Reference for system updates

Guidelines for Creating Good Class Diagrams:

1. Include only relevant classes

2. Show essential attributes and methods
3. Use meaningful names
4. Define clear relationships
5. Specify multiplicities
6. Use visibility modifiers appropriately
7. Keep diagram clear and organized
8. Group related classes

Tools for Creating Class Diagrams:

Enterprise Architect
Visual Studio
UML modeling tools
[Link]
Lucidchart

UNIT 5: Development Phase

2 MARKS QUESTIONS & ANSWERS
 Q1: PERT (Program Evaluation and Review Technique)

Answer:

PERT - Program Evaluation and Review Technique

Definition:

A graphical representation of a project's timeline

Displays all individual tasks necessary to complete project
Project management tool used to schedule, organize, and coordinate tasks

Purpose:

Analyze all project tasks

Estimate time required to complete each task
Estimate minimum time to complete entire project
Develop project budget
Determine resources needed

Key Components:

1. Nodes (Events)

Represent project events or milestones

Shown as circles or rectangles
Represent completion of tasks/phases

2. Arrows/Vectors

Represent tasks/activities
Connect nodes showing task sequence
Show dependencies between tasks

3. Critical Path

Longest sequence of dependent tasks

Determines minimum project duration
Any delay on critical path delays project

4. Time Estimates

Optimistic Time (O) - Best case scenario

Pessimistic Time (P) - Worst case scenario
Most Likely Time (M) - Normal scenario
Expected Time = (O + 4M + P) / 6

Advantages:

Handles uncertainty in timing

 Identifies critical path
Shows task dependencies
Helps in resource planning
Enables risk management
Improves project control

Disadvantages:

Complex to prepare
Requires detailed estimation
Time consuming
Needs skilled project manager

Q2: PERT Chart Work

Answer:

How PERT Chart Works:

Step-by-Step Process:

1. Identify All Tasks

Break down project into individual tasks

List all activities needed

2. Estimate Task Durations

Optimistic Time (O) - If everything goes perfectly

Pessimistic Time (P) - If everything goes wrong
Most Likely Time (M) - Most probable time
Formula: Expected Time = (O + 4M + P) / 6

3. Identify Dependencies

Which tasks depend on which

What tasks can run in parallel
What tasks must be sequential

4. Create Network Diagram

Draw nodes for milestones

Connect with arrows showing task flow
Label each task with duration

5. Calculate Critical Path

Identify longest path through network

This path determines minimum project time
 Focus management on critical path tasks

6. Resource Allocation

Assign resources to tasks

Identify resource constraints
Optimize resource usage

7. Monitor and Control

Track actual vs. planned times

Update chart as project progresses
Identify delays early
Make corrections as needed

PERT Chart Helps With:

Timeline visualization
Early identification of delays
Resource management
Risk identification
Project scheduling
Stakeholder communication

7 AND 15 MARKS QUESTIONS & ANSWERS

Q1: BOTTOM UP APPROACH

Answer:

Bottom-Up Approach (Also called Inductive Reasoning)

Definition:

Integration testing where testing takes place from bottom to up

Lower-level modules tested first with higher-level modules
Upper-level modules tested afterwards
Opposite of top-down approach

How It Works:

1. Start from Bottom - Test lowest-level/basic modules first

2. Create Drivers - Temporary modules to drive/call lower modules for testing
3. Integrate Upward - Integrate tested modules with higher-level modules
4. Test Integration - Test interaction between modules at each level
5. Remove Drivers - Remove temporary driver modules after testing
6. Move Up - Gradually test higher levels of program
 7. Complete Build - Builds integrated moving upwards in program

Process Flow:

Level 3 (Top) [Final Integration]

↑
Level 2 (Middle) [Intermediate Integration]
↑
Level 1 (Bottom) [Initial Testing]
[Basic Modules Tested First]

Key Features:

Advantages of Bottom-Up Approach:

1. Easy Fault Localization

Problems easily identified in tested modules

Errors traced to specific modules
Debugging easier

2. No Waiting for Module Development

Don't wait for all modules to be developed

Test lower modules first while others being coded
Better time utilization

3. Early Error Detection

Errors detected early in process

Critical modules/functionality tested first
Major flaws caught at early stage
Provides high deployment coverage in early phases

4. Easy Test Condition Development

Easier to develop test conditions

Focus on isolated functionality
Less complex test scenarios

5. Early Interface Defect Detection

Interface defects detected at early stage

Problems between modules found early
Easier to fix when found early

6. User-Friendly
 More user-friendly approach
No stubs required (no need for dummy modules)
Works with actual lower-level modules

7. Higher Accuracy at Granular Level

Better accuracy at lower levels

Detailed testing of basic functionality
Ensures quality foundation

8. Easier Test Observation

Observation of test results easier

Direct observation of module behavior
Clear results on lower-level functionality

Disadvantages of Bottom-Up Approach:

1. No Early Prototype

Cannot demonstrate system early

Cannot show partial working system to stakeholders
Limited visibility of functionality during development

2. Drivers More Difficult to Write

Drivers more complex than stubs

Requires more effort and time
Temporary code development needed

3. Design Defects Caught Late

System-level design issues not detected early

Problems in overall architecture not seen until later
Major redesign possible after much work

4. No Working Application Until End

Don't have working application until all modules integrated

Cannot demonstrate partial system
Risks not visible until late stage

5. Interface Errors Caught Late

High-level interface problems caught in later stage

System integration issues found late
Expensive to fix at late stage

When to Use Bottom-Up Approach:

 When lower modules are critical
When focusing on basic functionality quality
When modules are relatively independent
When testing hardware interfaces
When need to test early in development

Q2: TOP DOWN APPROACH

Answer:

Top-Down Approach (Also called Step-wise Design Approach)

Definition:

Integration testing where testing takes place from top to bottom

Top-level modules tested first
Then lower-level modules tested in step-by-step manner
Follows control flow or architectural structure of software system

How It Works:

1. Test Top Module - Top module tested separately first

2. Create Stubs - Dummy modules (stubs) for lower-level modules not yet developed
3. Integrate Gradually - Lower-level modules combined one by one
4. Test Integration - Test to ensure working as expected
5. Add Real Modules - Replace stubs with actual modules gradually
6. Continue Downward - Process repeated until all modules integrated

Process Flow:

Module A (Top Level) [Tested First]

↓
Module A1, A2 [Sub-modules Combined One by One]
↓
Sub-modules [Lower Levels]
↓
Most Detailed Level [Tested Last]

Key Features:

What are Stubs:

Dummy piece of code used for testing

Simulates behavior of modules not yet developed
Accepts requests from top-level module
Returns response compared to expected behavior
 Temporary code for testing purposes

Advantages of Top-Down Approach:

1. Easy Fault Localization

Errors easily identified and localized

Problem traced to specific module
Easier debugging

2. Early Prototype Possible

Can demonstrate partial system early

Shows system functionality from beginning
Early stakeholder feedback possible
Proof of concept early

3. Critical Modules Evaluated on Priority

Critical functionality tested first

Major design flaws detected and fixed first
Risk mitigation early
Core functionality validated early

4. Few or No Drivers Needed

Requires few or no temporary driver modules

Actual top module acts as driver
Less temporary code needed
Reduces overhead

5. More Stable and Accurate at Aggregate Level

Better stability at system level

System-level accuracy verified
Overall integration quality assured
Fewer surprises at end

6. Stubs Can be Written Quickly

Stubs simpler than drivers

Less time to create temporary modules
Faster setup for testing
Reduces development overhead

7. Test Results Very Consistent

Integration testing in realistic environment

Similar to actual deployment environment
 Fewer environmental issues
More consistent behavior

8. Simple Test Case Representation

Test cases easier to represent once IO functions added

Clear input/output definition
Clearer test scenarios
Better documentation

Disadvantages of Top-Down Approach:

1. Many Stubs Required

Need stubs for all non-developed lower modules

As system gets deeper, more stubs needed
Significant overhead for large systems
Maintenance of stubs required

2. Lower-Level Modules Tested Inadequately

Lower modules not tested thoroughly early

Limited testing before integration
May have hidden defects
Issues surface only during integration

3. Difficult to Test Upper-Level Modules

Top modules depend on lower modules (via stubs)

Hard to test complex logic without real lower modules
Stubs may not accurately simulate behavior
May hide issues in upper modules

4. Stub Development Cost

Creating and maintaining stubs is costly

Time and effort required to develop stubs
May need multiple versions of stubs
Reduces time available for actual coding

5. Basic Functionality Evaluated at End of Cycle

Core functionality not thoroughly tested until late

Basic modules not validated early
Problems found too late
Higher cost to fix late-stage issues

When to Use Top-Down Approach:

 When architecture and design are critical
When need early prototype and demo
When critical modules are at top level
When need stakeholder feedback early
When focusing on system behavior
For user-interface-driven systems

QUICK MEMORIZATION TIPS

Unit 1: Remember "INFO-SAT"
INFO - Information System basics
SA - System Analysis and Analyst
T - Tasks, Baseline, Activities of SDLC

Unit 2: Remember "FORMS & TOOLS"

FORMS - Form design and types
TOOLS - DFD, HIPO, Structured English, Flowchart, Pseudo Code

Unit 3: Remember "FEASIBILITY DESIGN"

F - Fact Finding, Feasibility (5 types)
D - Design Phase, Design Types (4 types)
E - Elements of System (6 elements)
S - System Types (7 types)

Unit 4: Remember "OO MODELS"

OO - Object Oriented concepts
MODELS - Class, Sequence, Activity, various types

Unit 5: Remember "BOTTOM-TOP"

BOTTOM - Bottom-up approach (advantages/disadvantages)
TOP - Top-down approach (advantages/disadvantages)
PERT - Program Evaluation Review Technique

Study Strategy:

1. Read each answer completely

2. Understand the concepts
3. Memorize key points and definitions
4. Create mind maps for complex topics
5. Practice writing answers
6. Review regularly before exam

Good Luck with Your Exams!