PUNJAB COLLEGE OF TECHNICAL EDUCATION

PRACTICAL FILE
SOFTWARE ENGINEERING LABORATORY
UGCA – 1924
In Partial Fulfilment of the requirement from degree of
BACHELOR OF COMPUTER APPLICATIONS

Submitted To:- Submitted B-

Mr Kamapreet kaur mam Lakshay Sharma
(Assistant professor CSE Department) Roll No.:- 2322153
Class:- BCA 2 C
PRACTICAL 1
Identify project scope and objective of given problem:
a. COLLEGE AUTOMATION SYSTEM.
b. BANKING MANAGEMENT SYSTEM.

a. COLLEGE AUTOMATION SYSTEM:

 Project Scope:

The scope of the College Automation System includes the development and implementation of a
comprehensive software solution tailored for managing various administrative and academic processes
within a college or educational institution. This system aims to streamline and automate tasks such as
student enrollment, class scheduling, attendance tracking, examination management, grading, and overall
student information management. Additionally, it may involve features for faculty management, resource
allocation, and reporting.

 Project Objectives:

 Efficient Student Management: Enable the efficient handling of student records, including
enrollment, personal details, academic performance, and attendance.
 Automated Class Scheduling: Develop a system for automated creation and management of class
schedules, taking into account various factors such as room availability, faculty schedules, and student
preferences.
 Examination Management: Implement features for exam scheduling, result processing, and
generation of transcripts or grade reports.
Faculty Management: Provide tools for managing faculty details, class assignments, and performance
evaluations.
 Resource Allocation: Optimize the allocation of resources such as classrooms, laboratories, and
equipment to enhance overall operational efficiency.
 Reporting and Analytics: Incorporate reporting tools to generate various reports for administrators,
faculty, and students. Analytics features may help in identifying trends and areas for improvement.
 User Authentication and Security: Ensure a secure system with proper user authentication
mechanisms to protect sensitive information.
b. BANKING MANAGEMENT SYSTEM:

 Project Scope:

The scope of the Banking Management System involves creating a software solution to automate and
manage various banking operations. This includes core banking functions such as customer account
management, transactions, loans, and other financial services. The system may also encompass features
related to online banking, mobile banking, and integration with other banking channels.

 Project Objectives:

 Customer Account Management: Develop a system for creating and managing customer accounts,
including personal details, account balances, and transaction histories.
 Transaction Processing: Implement secure and efficient transaction processing for various banking
activities such as deposits, withdrawals, fund transfers, and bill payments.
 Loan Management: Provide functionalities for handling loan applications, approvals, disbursements,
and repayments.
 Online and Mobile Banking: Integrate online and mobile banking features to allow customers to
access their accounts, make transactions, and manage their finances remotely.
 Security and Compliance: Ensure the system complies with security standards and regulations to
protect customer information and financial transactions.
 Reporting and Audit Trails: Include reporting tools and audit trails to monitor and analyze banking
activities for compliance, risk management, and decision-making.
 Integration with External Systems: Enable integration with other financial systems, payment
gateways, and external services to enhance the overall banking experience.
PRACTICAL 2
Develop software requirements specification for
a. College Automation System
b. Banking Management System

a. College Automation System

1. Introduction

1.1 Purpose

The purpose of this document is to outline the requirements for the development of the College Automation
System (CAS), a comprehensive software solution designed to streamline and automate various
administrative and academic processes within a college or educational institution.

1.2 Scope

CAS will cover student information management, class scheduling, attendance tracking, examination
management, faculty management, resource allocation, reporting, and analytics.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirements Specification

● CAS: College Automation System

2. Overall Description

2.1 Product Perspective

CAS will be a standalone system that interfaces with existing college databases for student and faculty
information. It will be accessible through a web-based interface.

2.2 Product Features

Student Management Class Scheduling Attendance Tracking Examination Management Faculty

Management Resource Allocation Reporting and Analytics
2.3 User Classes and Characteristics

● Administrator: Manages the overall system and data.

● Faculty: Manages class-related activities.

● Student: Accesses personal and academic information.

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

● Intuitive web-based interface for administrators, faculty, and students.

3.1.2 Hardware Interfaces

● Compatible with standard hardware used in the college.

3.1.3 Software Interfaces

● Integration with existing college databases for seamless data retrieval.

3.2 Functional Requirements

3.2.1 Student Management

● Add, modify, and delete student records.

● Track enrollment status, academic performance, and attendance. 3.2.2 Class Scheduling

● Automatically generate and manage class schedules.

● Consider room availability, faculty schedules, and student preferences

3.2.3 Attendance Tracking

● Record and track student attendance.

● Generate attendance reports.

3.2.4 Examination Management

● Schedule exams, record results, and generate transcripts.

3.2.5 Faculty Management

● Add, modify, and delete faculty records.

● Assign classes and manage performance evaluations.

3.2.6 Resource Allocation

● Optimize allocation of classrooms, laboratories, and equipment.

3.2.7 Reporting and Analytics

● Generate various reports for administrators, faculty, and students.

● Provide analytics for identifying trends and areas for improvement.

4. Non-functional Requirements

4.1 Performance Requirements

● System response time: 2 seconds for standard operations.

4.2 Security Requirements

● User authentication for all roles.

● Data encryption for sensitive information.

4.3 Scalability

● The system should handle a minimum of 1000 concurrent users.

5. Constraints

5.1 Regulatory

● Compliance with data protection and privacy regulations.

5.2 Technology

● Development to be done using XYZ programming language and ABC database.

b. Banking Management System

1. Introduction

1.1 Purpose

This document outlines the requirements for the development of the Banking Management System (BMS), a
software solution aimed at automating and managing various banking operations.

1.2 Scope

BMS will cover customer account management, transaction processing, loan management, online and
mobile banking, security and compliance, reporting, and integration with external systems.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirements Specification

● BMS: Banking Management System

2. Overall Description

2.1 Product Perspective

BMS will be a standalone system interfacing with banking databases. It should be accessible through web
and mobile interfaces for customers.

2.2 Product Features

Customer Account Management Transaction Processing Loan Management Online and Mobile Banking
Security and Compliance Reporting and Audit Trails Integration with External Systems

2.3 User Classes and Characteristics

● Bank Administrator: Manages overall system and data.

● Bank Staff: Performs various banking operations.

● Customer: Accesses accounts and manages finances.

3. Specific Requirements

3.1 External Interface Requirements.

3.1.1 User Interfaces

● Intuitive web and mobile interfaces for bank staff and customers.

3.1.2 Hardware Interfaces

● Compatible with standard banking hardware and security systems.

3.1.3 Software Interfaces

● Integration with core banking systems and payment gateways.

3.2 Functional Requirements

3.2.1 Customer Account Management

● Add, modify, and delete customer accounts.

● Track account balances and transaction histories.

3.2.2 Transaction Processing

● Process deposits, withdrawals, fund transfers, and bill payments.

● Ensure real-time updates of account balances.

3.2.3 Loan Management

● Handle loan applications, approvals, disbursements, and repayments.

3.2.4 Online and Mobile Banking

● Provide secure online and mobile banking services for customers.

3.2.5 Security and Compliance

● User authentication for all roles.

● Data encryption for sensitive information.

3.2.6 Reporting and Audit Trails

● Generate reports for compliance, risk management, and decision-making.

● Maintain audit trails for all banking activities.

3.2.7 Integration with External Systems

● Seamless integration with other financial systems and external services.

4. Non-functional Requirements

4.1 Performance Requirements

● System response time: 3 seconds for standard operations.

4.2 Security Requirements

● Compliance with banking industry security standards.

4.3 Scalability

● The system should handle a minimum of 5000 concurrent users.

5. Constraints

5.1 Regulatory

● Compliance with banking regulations and data protection laws.

5.2 Technology

● Development to be done using XYZ programming language and ABC database.

PRACTICAL 3

Develop a UML Use case model for given problem:

a. COLLEGE AUTOMATION SYSTEM.
b. BANKING MANAGEMENT SYSTEM.

COLLEGE AUTOMATION SYSTEM

BANKING MANAGEMENT SYSTEM

PRACTICAL 4
CLASS DIAGRAM FOR

a. College Automation System

b. Banking Management System

College Automation System

Banking Management System
PRACTICAL -5

Represent Project Scheduling Of Above Mentioned Projects

1. College Automation System:

Phase 1: Planning and Requirements Gathering

• Define project scope and objectives: This involves identifying the

boundaries of the project and what it aims to achieve.

• Gather requirements from stakeholders: Meet with faculty, staff, and students to
understand their needs and expectations from the automation system.

Phase 2: System Design

• Design database schema: Plan the structure of the database to efficiently store and
retrieve data related to students, courses, grades, etc.

• Design user interface: Create mockups or prototypes of the user interface to ensure
it's intuitive and user-friendly.

• Define system architecture: Decide on the overall architecture of the system,

including technology stack and frameworks to be used. Phase 3: Development

• Implement backend logic: Write code to handle processes such as student enrollment,
course registration, and grade calculation.

• Develop frontend modules: Build the user interface components based on the design
specifications.

• Integrate database and user interface: Connect the frontend and backend
components to ensure seamless interaction.
Phase 4: Testing

• Conduct unit testing: Test individual components/modules to verify their

correctness.

• Perform integration testing: Ensure that different parts of the system work together as
expected.

• Execute system testing: Test the entire system to validate its functionality and
performance.

Phase 5: Deployment

• Deploy the system in a test environment: Install the system on a test server for further
validation and testing.

• Conduct user acceptance testing: Allow stakeholders to interact with the system and
provide feedback.

• Make necessary adjustments: Address any issues or bugs identified during testing
before final deployment.

Phase 6: Maintenance and Support

• Provide user training: Conduct training sessions for faculty, staff, and students
on how to use the system effectively.

• Fix bugs and issues: Address any reported problems and release patches or updates as
needed.

• Regular maintenance and updates: Perform routine maintenance tasks and implement enhancements
to keep the system up-to-date and secure.
2. Banking Management System:
Phase 1: Planning and Analysis

• Define project scope and objectives: Determine the goals and deliverables of the
banking management system project.

• Conduct market research: analyses the banking industry, identify

competitors, and understand market trends.

• Gather requirements from stakeholders: Consult with bank managers,

employees, and customers to gather their needs and expectations. Phase 2: System

Design

• Design database structure: Create a robust database schema to store banking

transactions, customer information, etc.

• Design user interface: Design a user-friendly interface for bank employees to perform
various tasks efficiently.

• Define security measures: Implement security protocols to safeguard sensitive

data and prevent unauthorized access.

Phase 3: Development

• Develop core banking modules: Build modules for account management, transaction
processing, loan processing, etc.

• Implement security features: Integrate encryption, authentication, and

authorization mechanisms to ensure data security.

• Integrate with external systems: Connect the banking system with payment gateways, ATM networks,
and other external systems.

Phase 4: Testing

• Conduct unit testing: Test individual functions and modules to verify their correctness.

• Perform integration testing: Test the integration of different components to ensure they
work together smoothly.
• Execute system testing: Test the entire system to validate its functionality,
performance, and security.

Phase 5: Deployment

• Deploy the system in a controlled environment: Install the banking system in a

controlled environment to minimize disruption to bank operations.

• Conduct user acceptance testing: Allow bank employees to test the system and
provide feedback before full deployment.

• Address any issues identified during testing: Fix any bugs or issues
discovered during testing to ensure a smooth deployment process. Phase 6:

Training and Transition

• Provide training to bank staff: Train bank employees on how to use the new
banking system effectively.

• Migrate data from legacy systems: Transfer data from existing systems to the new
banking system without data loss or corruption.

• Ensure smooth transition: Plan and execute the transition from the old system to
the new system with minimal disruption to bank operations.

• Phase 7: Maintenance and Support

• Provide ongoing support and maintenance: Offer technical support to bank employees
and address any issues or concerns that arise.

• Regular updates and enhancements: Release updates and enhancements to the banking
system to improve functionality, security, and performance.

• Address security vulnerabilities: Monitor for security threats and vulnerabilities and
take measures to mitigate them to ensure the security of the banking system and

customer data
PRACTICAL 6

Use Any Model For Estimating The Effort, Schedule And Cost Of
Software Project
Estimating effort, schedule, and cost for software projects requires specific models

considering project characteristics.

Here are some common models to consider:

1. Function Point Analysis (FPA): Measures project size based on the functionality
delivered. It counts specific user functions and data elements, and then applies weightings

for complexity. FPA tools exist to assist in calculation.

2. COCOMO Model: Considers project size (lines of code) along with influencing
factors like team experience and project maturity. Different versions (Basic, Intermediate,

and Detailed) are available, requiring varying levels of project information.

3. Three-Point Estimation: Uses optimistic, pessimistic, and most likely

estimates

for tasks to build a statistically robust schedule and cost estimation. It accounts for uncertainty

and potential variations in task duration.

Applying these models to your College Management System:

 FPA: Identify user functions like student registration, course enrollment, attendance
recording, etc. Count functions and data elements, apply
complexity weights, and use an FPA tool to estimate effort in person- months.
 COCOMO: Estimate the total lines of code required for the system’s different
modules. Choose a COCOMO version based on available project information and
adjust for team experience and project maturity. The model generates effort, schedule,
and cost estimates. Three-Point Estimation: Break down project tasks into smaller units
(design, development, testing) and estimate their durations for each scenario
(optimistic, pessimistic, most likely). Calculate averages and standard deviations to build
a realistic time and cost estimation for the project.
Remember:
• These models provide approximate estimates, not guarantees.

• Accuracy relies on accurate project information and input values.

•Consider adapting models and incorporating your domain knowledge for better

results.

•Always factor in contingencies for risks and uncertainties.

Additional Points:

•Cost is a function of effort, team rates, infrastructure, and other factors. Utilize your

organization’s cost estimation practices for calculating project costs.

•Scheduling your project involves identifying task dependencies and allocating

resources effectively. Utilize scheduling tools like Gantt charts based on your

chosen estimation model.

PRACTICAL 7

Develop The Dfd Model (Level-0, Level-1 Dfd And Data Dictionary)
Of The Weather Forecasting Application With User Customised
Alerts Project
LEVEL 0

At Level 0, we have two main external entities:

 User Interface: This represents the interface through which users interact with the
application.
 Weather Data Provider: This represents the external source of the application fetches
weather data.
 The only process at this level is the Weather Forecasting System, which acts as the
central component of the application. The data flows depict the interaction between the
entities and the system, showing that weather data is received from the Weather Data
Provider and user inputs are received from the User Interface.

LEVEL1
 At Level 1, we delve deeper into the processes and data flows within the Weather
Forecasting System:
 User Management: This process handles user registration, authentication, and account
management.
 Alerts Customization: This process allows users to customize their alert preferences,
storing these settings for each user.
 Weather Data Retrieval: This process fetches weather data from the external Weather
Data Provider, parses it, and stores it for further processing.
 Alerts Generation: This process evaluates weather conditions against user- defined alert
settings, generates alerts accordingly, and stores them for delivery.
 Alerts Delivery: This process selects appropriate notifications based on user preferences
and sends them to the User Interface for display.
 The data stores hold relevant information such as customized alert settings, retrieved
weather data, and generated alerts. Data flows illustrate the flow of information between
the User Interface, external Weather Data Provider, and various processes within the
system.

LEVEL 2
 At Level 2, we further decompose the processes to show more detailed sub-

processes:

 Alerts Customization: This process includes sub-processes for user input validation,
storage of customization settings, and alert configuration.
 Weather Data Retrieval: This process includes sub-processes for making API requests,
parsing data, and storing retrieved weather data.
 Alerts Generation: This process includes sub-processes for evaluating alert conditions,
processing alert rules, and storing generated alerts.0
 Alerts Delivery: This process includes sub-processes for creating notifications, selecting
appropriate notifications for users, and sending notifications to the User Interface.

PRACTICAL 8
Develop Sequence Diagram For Library Management System
PRACTICAL 9
Develop Structured Design For The DFD Model Developed
Level 0 DFD Structured Design

External Entities:
 User Interface:

 Represents the interface through which users interact with the application.

 Weather Data Provider:

 Represents the external source providing weather data to the application.

Processes:

 Weather Forecasting System:

 Represents the main process that interacts with external entities to manage
weather data and user interactions.

Data Flows:

 From User Interface to Weather Forecasting System:

 Carries user requests and interactions to the system.

 From Weather Data Provider to Weather Forecasting System:

 Provides weather data to the system for processing. Level 1
DFD Structured Design

Weather Forecasting System:

1. Processes:

 User Management:
 Manages user registration, authentication, and profile management.
 Alerts Customization:
 Handles customization of alert settings based on user

preferences.

 Weather Data Retrieval:

 Fetches weather data from external source (Weather Data Provider

API).

 Alerts Generation:
 Evaluates weather conditions against user-defined settings to generate alerts.

 Alerts Delivery:
 Delivers alerts to users via notifications using Twilio API.

2. Data Stores:

 Storage Customization Settings:

 Stores customized alert settings for each user.

 Weather Data Storage:

 Stores retrieved weather data for further processing.

 Generated Alerts Storage:

 Stores generated alerts based on weather conditions and user settings.

3. Data Flows:
 Various data flows between processes to manage user requests, weather data, alert
settings, and alert delivery.

Level 2 DFD Structured Design (Selected Processes):

Alerts Customization:
1. Processes:

 User Input Validation:

 Validates user input for alert customization.

 Customization Settings Storage:

 Stores user-customized alert settings.

 Alerts Configuration:
 Configures alerts based on user settings.

Weather Data Retrieval:

1. Processes:
 API Request:

 Sends request to Weather Data Provider API.

 Data Parsing:

 Parses received weather data.

 Data Storage:

 Stores parsed weather data for further use.

Alerts Generation:

1. Processes:

 Alert Conditions Evaluation:

 Evaluates weather conditions against user-defined alert settings.

 Alert Rules Processing:

 Processes rules to generate alerts.

 Alerts Storage:

 Stores generated alerts for delivery.

Alerts Delivery:

1. Processes:
 Notification Creation:

 Creates notifications for generated alerts.

 User Notification Selection:

 Selects appropriate notifications for users.

 Notification Sending:

 Sends notifications to users via Twilio API.

PRACTICAL 10

Develop The Waterfall Model, Prototype Model And Spiral Model

Library Management System
Waterfall Model:

The waterfall model is a sequential software development process where progress flows

steadily downwards through the phases of conception, initiation, analysis, design,

construction, testing, deployment, and maintenance.

Phases:

1. Requirements Gathering: Define the requirements for the Library Management System by
interviewing stakeholders such as librarians, patrons, and administrators. Document these
requirements comprehensively.

2. System Design: Create a detailed system design based on the requirements gathered. This
includes the architecture of the system, database design, user interface design, and module
design.

3. Implementation: Develop the Library Management System according to the design

specifications. This involves coding, unit testing, and integration testing of the various
components.

4. Testing: Conduct thorough testing of the system to ensure it meets the specified requirements
and functions correctly. This includes functional testing, performance testing, and user
acceptance testing.

5. Deployment: Deploy the Library Management System to the production environment. This
may involve installation, configuration, and data migration.

6. Maintenance: Provide ongoing support and maintenance for the system, including bug fixes,
updates, and enhancements as required.
Prototype Model:

The prototype model involves creating a simplified version of the Library Management

System to gather feedback and refine requirements iteratively. Steps:

1. Identify Basic Requirements: Identify the core functionalities that the Library Management
System must have.

2. Develop Prototype: Develop a basic prototype of the system with limited functionality.
Focus on implementing the most critical features first.

3. Gather Feedback: Demonstrate the prototype to stakeholders such as librarians, patrons, and
administrators to gather feedback on its usability and functionality.

4. Refine Requirements: Based on the feedback received, refine the requirements and update
the prototype accordingly.

5. Iterate: Continue to iterate on the prototype, adding new features and refining existing ones
based on ongoing feedback from stakeholders.

6. Finalize: Once the prototype meets the desired requirements and stakeholders are satisfied,
finalize the design and move into full-scale development.
Spiral Model:
The spiral model combines elements of both waterfall and prototype models, emphasizing risk
analysis and iterative development.

Phases:

1. Planning: Identify objectives, constraints, and alternative solutions. Plan the development
process.

2. Risk Analysis: Evaluate potential risks associated with the project, such as technical
challenges or changing requirements.
3. Prototype Development: Develop a prototype to address the most critical risks and validate
key design decisions.

4. Evaluation: Review the prototype with stakeholders to gather feedback and assess its
effectiveness.

5. Development: Develop the Library Management System incrementally,

addressing high-risk areas first and adding functionality with each iteration.

6. Testing: Test the system thoroughly at each iteration to identify andmitigate any issues.

7. Deployment: Deploy the system to production once it meets the desired

requirements and has been thoroughly tested.

8. Maintenance: Provide ongoing support and maintenance for the system,

incorporating feedback and making updates as needed.

Each of these models has its strengths and weaknesses, and the choice of which to use depends
on factors such as project requirements, timeline, budget, and the level of stakeholder
involvement. For a Library Management System, where requirements may evolve over time and
user feedback is crucial, a combination of the prototype and spiral models may be particularly
suitable.
PRACTICAL 11

Explain With Reason Which Model Is Best Suited For Library

Management System
Choosing the most suitable Software Development Life Cycle (SDLC) model for a Library

Management System (LMS) depends on various factors such as project requirements, timeline,

budget, and stakeholder involvement. Here's an analysis of which SDLC model might be most

suitable for an LMS:

1. Waterfall Model:
The waterfall model is a traditional sequential approach to software development. It involves
completing one phase before moving on to the next, making it suitable for projects with well-
defined requirements and a stable scope.

Suitability for LMS:

• If the requirements for the LMS are well-defined and unlikely to change significantly
throughout the project, the waterfall model could be suitable.

• In cases where there's a clear understanding of what the LMS needs to do and how it will
function, the waterfall model provides a structured approach to development, ensuring each
phase is completed thoroughly before moving on to the next.

• However, if there's a possibility of evolving requirements or if stakeholders may require

frequent demonstrations and adjustments, the waterfall model may not be the best choice.