American International University- Bangladesh (AIUB)

Department of Computer Science

Spring 2021-2022

Course: Software Development Project Management

Section: A

Project Title: Developing Online Rail way ticket booking system.Submitted by:

Serial No. Student Name Student ID

01 ABU MD NAFIS ISLAM 20-43077-1
02 NUR RAISA RAHMAN 20-42228-1
03 HASIBUL ISLAM 20-42865-1

1.0 INTRODUCTION: The following is Shohoz's plan for managing their software
development project for the Automated (Online) Ticket Issuing System. The purpose of
this document is to provide a comprehensive overview of various aspects of software
development, including the project's objectives, system overview, feasibility, justification,
components,stakeholder identification, effort estimation, development schedule, and risk
analysis. The intended readers of this plan are the project leader, client representatives,
and members of the project steering committee. The main goal of this document is to
create a project development plan that encompasses all of the aforementioned areas.

2.0 Project Title: : Developing Online Rail way ticket booking system.
3.0 Objectives:Currently, the SHOHOZ manages the Ticket Issuing System process
manually, which is a time-consuming procedure. The ticket booking transporter finds it
challenging to manage these details in order to complete the task on time. The
Automated Ticket Issuing System completely automates the whole process, making it
easier to manage the ticket issuing process and reducing labor pressure. Some of these
include: Improving the effectiveness of issuing tickets;Keeping tickets current; Sharing
information online; and Offering a user-friendly system.

4.0 Justification: This Online ticketsystem offers the user a number of benefits. This
method may stop runway scheduling. Also, prevent customer expenditure overruns.
Customers might save significant amounts of time using this approach, potentially at the
sacrifice of product quality. Speed and accuracy are the two main benefits of automated
ticket issuing. We are all aware that sorting through several tickets might take some
time. Agents may instead focus on the tickets that have already been assigned to them
when customers automate this process. The system generates a ticket by emailing a
user. Every purchase order that isreceived is converted into a ticket and sent to a
registered email address. The user only needs to get into the system and reprint the
ticket from the order history if he ever loses the mail. The system has a particular
safeguard against people exploiting it (ticket black-marketing).
5.0 System Overview: Tickets are sold via an automated ticketing system. Users
(Registered) choose their destination and provide a credit card number and a PIN
(personal identification number). The ticket is provided, and the fee is debited to their
credit card. When the user touches the start button, a choice of possible locations
appears, along with a message asking the user to choose one. Once a destination has
been chosen, consumers are prompted to input their payment card. Its legitimacy is
confirmed, and the user is then invited to enter a PIN. The ticket is provided after the
credit transaction has been confirmed.

There are two major actors in our system- administrators and registered users. Other
actors are the system itself and users(non-registered/visitors).

Administrator- Users (Visitor)-

• Manage Ticket Data • User signup

• Monitor and Control Users System-

• Tracks Orders • Verify id and password

• Report Generation (Sale) • Verify phone/email

• Bug Report • Verify updated info

Users (Registered)- Database Configuration

• User Login • Database name ATS by O-Inc.

• Update User Details • User data table

• Browse Tickets • Tickets table

• Orders Details – View and History • Orders Table

• Purchase Tickets

• Make Payments
• Reissue Tickets
A use case diagram of the overall system is given below:

6.0 Stakeholders analysis: Stakeholders of this project can be categorized into two type:

Internal Stakeholder- External Stakeholder-

 Owners  Customers (Users)

 Board of Directors  Creditors
 Managers  Service Providers
 Sponsors  Competitors (Negative Stakeholder)
 Employees  Government
7.0 Feasibility study: Feasibility in terms of technical and financial is discussed below-

Technical Assessment

HW Requirement (Min)- SW Requirement-

 Memory: 4 GB  BMS version 2.0 (Transaction)

 GPU: GT650  CMS version 3.0 (Verification)
 CPU: Intel core i3  MySQL
 OS: Windows 10/11  IDE: XAMPP
 Language:
PHP/HTML/CSS/JSON
It can be concluded that the project is feasible in terms of technical assessment.

Financial Assessment

Project Budget: BDT 500,000

Assumed Costs-

Development cost: BDT 400,000

Setup Cost : BDT 25,000

Operational Cost : BDT 55,000

Others : BDT 10,000

Total Cost : BDT 490,000

From the above estimates, it can be stated that the project is financially feasible.
8.0 Systems component: The system components are identified below using the Work
Breakdown Structure (WBS).

9.0 Efforts estimation: COCOMO (Constructive Cost Model) is used to estimate the
effort for our project.

Project type: Organic

Coefficient<Effort factor>: 2.4
Project complexity, P: 1.05
SLOC-dependent coefficient, T: 0.38
Effort Estimation Formulas:
Effort = PM = Coefficient<Effort factor> *(SLOC/1000)^P
Development Time = DM = 2.50 *(PM) ^T
Required number of people = ST = PM/DM

SL Development Tasks Size (SLOC) PM DM ST

1 Code at unit level 8000 21.30373 7.993798 2.665033
2 Integrate units 2000 4.969272 4.597601 1.08084
3 Integrate OTS 4500 11.64352 6.354071 1.832451
4 Install System 14500 39.77843 10.13459 3.925017
10.0 Activity Diagram: The activity diagram identifying different activities for
scheduling y project is given below:

11.0 Risk Analysis: The possible risks for the proposed project is given in the following
risk table.

Risks Category Probability Impact RMMM

System failure TI 10% 1 Make sure the units or

components pass the
required test cases
before integrating the
system
Late delivery BU 30% 2 Make sure the project
progress is on track,
other take immediate
action.
Technology will not TE 5% 2 Check whether the
meet expectations technologies

are acquirable
 End users BU 10% 1 The system passes the
resist system acceptance test, try to
come to
an
understanding with the
client
Changes in PS 60% 3 Check if the changed
requirements Requirements

are feasible, try to

make the requirement
change before starting
the development
phase
Deviation from PI 15% 3 After the completion of
software certain activities, check
engineering whether it meets the
standards standard, otherwise
make necessary
change
Less reuse PS 60% 3 Find out the
than cause, readjust
planned the plan
Poor comments in TI 20% 4 Train the programmers
code

12.0 Conclusion: This project is a novel approach to ticketing operations will be made
available by this project as a whole. Online ticket administration and automation will be
used. However, as the firm also caters to walk-in clients, this strategy does not prevent
anyone from approaching the counter. Additionally, less papers are needed than in the
earlier ticketing method.