Real State Property Final Print

Realstate Property Management System
A project submitted to
BHILAI INSTITUTE OF TECHNOLOGY, DURG
An Autonomous Institute
Affiliated to
Chhattisgarh Swami Vivekanand Technical University, Bhilai (CG)
in the partial fulfillment of the requirements for the award of
MASTER OF COMPUTER APPLICATIONS

(MCA)
By
Anurag
Roll No.: 500102122035
Enrollment No.: CC2742
Under the Guidance of
Dr. Vinita A Gupta
DEPARTMENT OF COMPUTER APPLICATIONS,

Session: 2022-2024
CERTIFICATE OF SUPERVISOR(S) /GUIDE
This is to certify that the work incorporated in the project Realstate Property Management
System is a project work assigned by our Institute, successfully carried out by Anurag bearing
Roll No: 500102122035, Enrollment No: CC2742. Under my guidance and supervision for the
award of Degree of Master of Computer Applications (MCA) from Bhilai Institute of Technology,
Durg, C.G., affiliated to Chhattisgarh Swami Vivekanand Technical University (CSVTU), Bhilai,
C.G., India. To the best of my knowledge and belief the report embodies the work of the candidate
him/herself and has duly been successfully completed.
Signature of the Supervisor/Guide

Name:
Designation:
Date:
DELCLARATION BY THE CANDIDATE
I, Anurag ,Student of 4th Semester MCA, Bhilai Institute of Technology, Durg, C.G., India,
bearing Enrolment Number CC2742 here by declare that the project entitled Realstate Property
Management System has been carried out by me under the Guidance / Supervision of External
Guide Mr. Harish Sen, Co-Founder & C.E.O submitted in partial fulfillment of the requirements
for the award of the Degree of Master of Computer Applications (MCA) by the Chhattisgarh
Swami Vivekanand Technical University during the academic year 2022 - 2024. This report has
not been submitted to any other Organization/ University for any award of Degree/ Diploma.
(Signature of Candidate)
Date:
Place:
CERTIFICATE OF FORWARDING
This is to Certify that Anurag, a bonafide Student of Master of Computer Applications (M.C.A) at
Bhilai Institute of Technology, Durg, C.G., India, has carried out his project work as mentioned
in this project entitled “Realstate Property Management System” at “YASHVITECH IT
SOLUTIONS PVT. LTD”., during his fourth semester of studies in M.C.A as a part of a
curriculum for obtaining the degree of M.C.A from Chhattisgarh Swami Vivekanand Technical
University (CSVTU), Bhilai, C.G., India to which the institute is affiliated.
This Certificate Issued by the undersigned does not cover any responsibility regarding the
statements made and work carried out by the concerned student.
The current dissertation is hereby being forwarded for evaluation for the purpose for which it has
been submitted
Signature of Project Coordinator Signature of Head of Department

Name: Mr. B Varghese Name: Dr. Jyothi Pillai
Designation: Associate Professor Designation: Head Of Department
Institution: Bhilai Institute of Technology Institution: Bhilai Institute of Technology
Date: Date:
CERTIFICATE OF APPROVAL
This is to Certify that the project the entitled “Realstate Property Management System”, carried
out by Anurag a student of fourth semester, M.C.A. at Bhilai Institute of Technology, Durg,
C.G., India, is here by approved after proper examination and evaluation as a creditable work for
the partial fulfillment of the requirement for awarding the degree of Master of Computer
Applications (M.C.A) from Chhattisgarh Swami Vivekanand Technical University (CSVTU),
Bhilai C.G. India
(Internal Examiner) (External Examiner)

Name: Name:
Designation: Designation:
College Name: College Name:
Date: Date:
ACKNOWLEGEMENT
I have great pleasure in the submission of this project report entitled “Realstate Property
Management System” for YASHVITECH IT SOLUTIONS PVT. LTD. in partial fulfillment
the degree of the degree of Master of Computer Applications. While submitting this Project report,
I take this opportunity to thank those directly or indirectly related to project work.
I would like to thank my external guide Mr. Harish Sen in Organization who has provided the
opportunity and organizing project for me. Without his active co-operation and guidance, it would
have become very difficult to complete task in time.
I would like to express sincere thanks to Dr. Arun Arora, Principal, Dr. Jyothi Pillai, Head of
Department, (Computer Applications).
While Submission of the project, I also like to thanks to Mr. B Varghese Project Coordinator and
the all Professors of Bhilai Institute of Technology, Durg, C.G., India, for their continuous help
and guidance throughout the course of MCA.
Acknowledgement is due to our parents, family members, friends and all those persons who have
helped us directly or indirectly in the successful completion of the project work.
Anurag
Table of Content
No. Heading Page No.

1 Abstract and Type of Project (Software). 1
2 List of Tables. 1
3 List of Figures. 2
4 Project Development Process Model Used (Methodology). 2
5 Project’s Process Documentation. 2
5.1. INCEPTION PHASE. 3
5.1.1 Initial Description of Problem 4
5.1.2. Software Requirement Specification-SRS. 4
5.1.2.1. Non-Functional Requirement
● Hardware requirement.
4
● Software requirement.
● Communication interface
5.1.2.2. Functional Requirement
● Accept New User
● Manage Property 4
● Manage Broker’s
● Add Update Admins
● Remove Users
● Manage Activity Log’s
● Manage Property Types
● Manage Income Details
● User query/Enquiry
5.1.2.3. Performance Requirement

● Static performance
5
● Dynamic performance
5.1.3. Security features 6
5.1.4. Reliability. 6
5.1.5. Cost estimation using DFP. 7
5.2. ELABORATION PHASE (DETAIL DESIGN) 10

5.2.1 Object Model. 11
5.2.1.1 Object Classes. 11
5.2.1.2 Data dictionary containing description of class 11
attributes (data members, and methods) .
5.2.1.3 Association between classes. 14

5.2.1.4 Simplifying objects classes using Inheritance. 14
5.2.1.5 Group classes into module. 14
5.2.1.6 Object Diagram. 15

5.2.2. Dynamic Model 15
5.2.2.1 Scenario (Project Interaction Sequence) 16
5.2.2.2 Event Flow Diagram (EFD) 17
5.2.2.3 State Diagram (SD) for each classes 18
5.2.3 Functional Model 19
5.2.3.1 Identification of Input / Output values. 19
5.2.3.2 DFD as needed to show functional dependencies. 20
5.2.4. Database design 21
5.2.4.1 Schema definitions with Candidate key/Primary key 21
5.2.4.2 Normalization 23
5.2.4.3 E-R Diagram 24
6. CONSTRUCTION PHASE 25
6.1. CASE Tools used to design 26
6.2 Coding Language and Operating System (OS) used (Including 26
explanation).
6.3. Database connectivity procedure 26
6.4. Code description. 26
6.5. I/O Interface. 30
7. TRANSITION PHASE 37
7.1. Report of Alpha testing 38
7.2. DSLOC and Cost estimation using DSLOC 38
7.3. Cost variation between DFP and DSLOC 39
8. Limitations & Future Enhancement. 40
9. Conclusions. 40
REAL STATE PROPERTY MANAGEMENT SYSTEM 1
1. Abstract
The Real Estate Property Management System is developed under a structured software
development methodology that incorporates several key phases. During the initial phase, system
requirements and specifications are gathered and analyzed to ensure a comprehensive
understanding of the project's scope. This is followed by the design phase, where detailed technical
specifications and documentation are created, focusing on architectural, data structure, interface,
and procedural design. The implementation phase involves the actual development, testing, and
integration of software modules, accompanied by extensive user training. Finally, the system
undergoes a thorough review and acceptance testing before its operational deployment. The project
emphasizes quality through meticulous design and progressive refinement, ensuring the system
meets both functional and performance requirements. The development process is detailed and
methodical, ensuring a robust and efficient system that aligns with the project's goals and user
needs.
2. List of Tables
1 Functional point complexity weight 7
2 Complexity factor 7
3 Coefficient of Basic COCOMO 8
4 Object Class 11
5 Data Dictionary 11
6 Admin Group Class 14
7 I/O Table 19
8 Accept New User Schema 21
9 Listing Schema 21
10 Types Schema 21
11 Amenity Schema 21
12 Manage Broker Schema 22
13 Location Schema 22
14 Income Schema 22
15 ActivityLog Schema 22
16 Contact Details Schema 23
17 Code Description 26
18 Effort Adjustment factor 38
19 Coefficient of Intermediate COCOMO model 38
Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

3. List of Figures
1 The phase of life cycle process 2
2 Association between classes 14
3 Object diagram 15
4 User Scenario 16
7 Event flow diagram 17
8 State diagram 18
9 DFD 20
10 E-R Diagram 24
4. Project Development Process Model Used (Methodology).

In this Project the modern software development has been used where it is divided into two stages
Engineering stage and Production stage. Engineering stage is further divided into Inception phase
and Elaboration phase. Production stage is divided into Construction phase and Transition phase
All phase of development based on Iteration. The outcome of the Inception phase is SRS, The
outcome of Elaboration phase is detailed architecture, The outcome of the Construction phase is
Beta release, The outcome of the Transition phase is final product.
Figure 1: The Phase of life cycle process

INCEPTION PHASE

5.1.1. Initial Description of Problem

The Real Estate Property Management System website is designed to meet the needs of the
community by providing a comprehensive platform for various activities, including registration,
matrimony services, advertising, and membership management. The system is structured to ensure
a seamless user experience, with various roles and functionalities to maintain and update the site
effectively.
5.1.2. Software Requirement Specification - SRS
5.1.2.1. Non-Functional Requirements
• Hardware Requirement
o Microprocessor: Intel Processors Pentium 4 and above
o RAM: Minimum of 4GB RAM
o Storage: Minimum of 128GB
• Software Requirement
o Operating System: Windows 10 or 11
o Programming Languages: Python 3.0 to 3.10, Django 3.10.12 and above,
React JS 0.69
• Communication Interface
o Internet Protocols: HTTPS, Rest API
5.1.2.2. Functional Requirements
• Accept New User

o This subsystem provides the feature to allow activation of new
registered users. The users can register and then, after admin approval,
they can log in to the system.
• Manage Property
o This subsystem allows the admin to manage property details, including
adding, updating, and deleting property listings. The admin can also
categorize properties by type, such as residential, commercial,
agricultural, or industrial 1 .
• Manage Brokers
o This subsystem enables the admin to manage broker information. The
admin can add new brokers, update existing broker details, and remove
brokers from the system 1 .

• Add Update Admins

o This subsystem provides the functionality to add new admin users and
update the details of existing admin users. The admin can assign
different levels of access and permissions to each admin user 1 .
• Remove Users
o This subsystem allows the admin to remove users from the system. The
admin can deactivate or delete user accounts as necessary .
• Manage Activity Logs

o This subsystem tracks user and system activities. It logs actions
performed by users and admins, providing an audit trail for security and
troubleshooting purposes .
• Manage Property Types

o This subsystem allows the admin to define and manage different
property types. The admin can add new property types and update or
delete existing ones .
• Manage Income Details

o This subsystem enables the admin to manage income details related to
property transactions. It tracks payments, commissions, and other
financial details associated with property dealings .
• User Query/Enquiry
o This subsystem provides a platform for users to submit queries or
enquiries regarding properties. The admin or designated support staff
can respond to these queries, facilitating communication between users
and the property dealing company.
5.1.2.3. Performance Requirements

• Static Performance There can be 1 crore users who can access the web
application.
• Dynamic Performance This application is developed using Django for the
backend, React JS for the frontend, and SQLite for the database. All exceptions
are handled through proper error-handling mechanisms.
5.1.3. Security Features
• Django Features
o SQL Injection Prevention Django provides built-in functions to help
prevent SQL injection attacks.
o Password Hashing Django provides built-in functions to securely hash
and salt passwords.
o Session Management Django provides session management that allows
developers to securely manage sessions.
• MySQL Features
o User Authentication MySQL uses a username and password-based
authentication system, which allows database administrators to control
access to the database.
o Backup and Recovery MySQL provides backup and recovery
mechanisms that help administrators to recover data in the event of a
security breach, data loss, or hardware failure.
o Security Plugins MySQL has several security plugins, such as the
MySQL Enterprise Firewall and MySQL Enterprise Audit, which provide
additional security features, such as intrusion detection and prevention and
enhanced auditing capabilities.
5.1.4. Reliability
• User Interface: Reliability of user interface is High.

• Output Interface: Reliability of output interface is High.
• Result: Result Reliability is High

5.1.5. Cost Estimation Using DFP

The cost estimation is calculated by delivered function point and uses following complexity factor
and weight:
Table No 1: Functional Point Complexity Weight
Function Type Simple Average Complex
External Input 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface File 5 7 10
Table No 2: Complexity Factor

S.no Factor Influence Value
1 Data communications Moderate 2
2 Distributed processing Moderate 2
3 Performance objectives Strong 5
4 Operation Configuration load Moderate 2
5 Transaction rate Average 3
6 On-line data entry Moderate 2
7 End user efficiency Moderate 3
8 On-line update Average 3
9 Complex processing logic Moderate 2
10 Re-Usability Moderate 2
11 Installation case Insignificant 1
12 Operational case Insignificant 1
13 Desire to facilitate change Moderate 2
14 Multiple sites Insignificant 1
Total (N) = 30
External Inputs: 17 Internal logical Files: 14

External Output: 11 External Interface Files: 4
External Inquiries: 9
The functions use simple type factor
DFP = Count-total * [0.65 + 0.01 * ∑(fi)] = UFP * CAF

UFP= 17*3 + 11*4 + 9*3 + 14*7 + 4*5 =226

Unadjusted Function Point = 240
CAF= 0.65 + 0.01*N N= Complexity factor=30

= 0.65 + 0.01*30 = 0.95
Complexity Adjustment Factor (CAF) = 0.95
DFP= UFP * CAF = 240 * 0.95 =228

Delivered Function point = 228
To convert function points into expected Source line of code we require language factor.
The Language factor of Python is 53 per function point
Expected SLOC = Language Factor * Total Function points
= 53 * 228 = 12084 LOC = 12.84 KLOC Expected
Table no:3 Coefficient of Basic COCOMO

Software Product a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
By basic COCOMO model for organic project
Expected Effort = a(KLOC)^b = 2.4(12.84)^1.05 = 35.01 PM
Expected Duration = c(Effort)^d = 2.5(35.01)^0.38 = 9.6 Months
Expected Person = Effort / Duration = 35.01 / 9.6 = 3.64 ~ 3 Person

5.2. ELABORATION PHASE

5.2.1 Object Model

5.2.1.1 Object Classes
As per the requirement described in SRS we have following class object. Name and description
purpose as given as following table no:2
Table No 4: Object Classes
SNo. Name of Object/Class Description

To accept new
1 Accept New User property
buyers/sellers
To add, update,
2 CRUD Property Listing remove property
listings
To add, update,
3 CRUD Property Types remove property
types
To add, update,
4 CRUD Locations remove property
locations
To accept/reject
5 Manage Property Requests
property requests
To remove expired
6 Remove User
members
To Add/ Update/
7 Manage Admin
Remove Admin
All Operation
8 Activity Log
Activity Log
5.2.1.2 Data dictionary containing description of class attributes (data members, and
methods) .
As per the defined object given in the table one the dictionary of each object is shown in
following table:
Table No 5: Data Dictionary
Method
SN Name of
Data Member Valid Range Methods Descripti
o Class
on
Int userid UserId: int(11) This
String Name Name:char(20) method is
String State State:char(30) used to
1 Accept
String District District:char(30) void acceptUser() accept a
New User
user with
String Contact Contact: char(30) the details
2 Int listing_id Listing_id: int(11) void crud This

String title title: char(20) PropertyDocument method is

CRUD Date last_date last_date: date View () used to
Property String description: create/
Listing description char(90) update/
String district district: char(30) remove
DateTime time time: timestamp Property
String Listing
by_admin: char(20)
by_admin
String status status: char(20)
Int id id: int(11) This
method is
Crud void used to
3 property_ty String property_types: crudPropertyTypes( add /
pes property_types char(30) ) update/
Property
Types
Int id id: int(11) This
String amenity_name:char method is
amenity_name (50) used to
4 Crud void
String details, details: char(100) add /
Amenity crudAmentities()
update/
String delete
by_admin: char(30)
by_admin Amentity
Int broker_id broker _id: int(11) This
Double percentage: Double method is
broker_percent used to
5 Manage void
age make new
Broker ManageBroker()
Int User_id User_id: int(11) head or
String status status: char(30) change
old head
Int id Id: int (11) This
method is
String Location_name : used to
6 location_name char(50) add /
Location CrudLocation()
Boolean active Active : update/
bool(true/false) delete
Int listing_id Listing_id : int(11) Location’
s
Int id id: int(11)
This
String Property_name:
method is
7 Realstate property_name char(100) void
used to
Income DateTime date Date : Timestamp RealstateIncome ()
manage
String Sold_price:char(50) Income
sold_price
int id id: int(11)
String name name: char(50) This
method is
String email email: char(30)
used to
ContactDeta String phone phone: char(30)
8 void Enquiry() add,
ils Boolean
Is_agent: boolean delete,
is_agent
update
String query Query : char(500) enquiry
Int property_id property_id: int(11)
Int id id:int(10) This
8 AdminLog void admin_log ()
datetime action_time: method is

action_time timestamp used to

Int user_id User_id: int(11) create
String Change_msg: activity
change_msg char(300) log

5.2.1.3 Association between classes.

As per the requirement and the data dictionary given in the table no: the class diagram shown as
follows. In figure 2
Figure 2: Association between classes
5.2.1.4 Simplifying objects classes using Inheritance

No inheritance is used as per simplicity of project.
5.2.1.5 Group classes into module

The simplicity of project is single module project has been defined. In which class and object
defined as given in the table.
Table No 6: Admin Module
Admin Module
SNO. Name of Class Description
1 Accept New User To accept a user with the details
2 Crud Listing used to create/ update/ remove listing
3 Crud Property used to add / update/ delete properties
4 Crud Amenity used to add / update/ delete Amenities
5 Manage locations This method is used to manage locations
6 Crud broker used to add / update/ delete broker

7 ActivityLog This method is used to create activity log
Table No 7:Admin class module

5.2.1.6 Object Diagram
The Object diagram represents a specific instance of a class shown in the figure given below:
Figure 3: Object Diagram

5.2.2 Dynamic Model
The Dynamic model of system describes the aspect of system those concern with the time and
sequence of operation. Even that its change of event, state, that defines context of event and the
organization of event and state.

5.2.2.1 Scenario (Project Interaction Sequence)
The Scenario describes the specific use of the entire system and the working of the software
shown in the figure given below:
Figure 4: User Scenario

5.2.2.2 Event Flow Diagram (EFD)
The event flow diagram describes the entire flow of the events which occurs in the software shown
in the figure given below:
Figure 5: Event Flow

5.2.2.3 State Diagram (SD) for each classes

State diagram describes the behavior and action performed in the software described in
the diagram given below:
Figure 6: State diagram

5.2.3 Functional Model

It describes aspect concerns with transformation of data values, functions, mapping constraints and
functional dependencies. This modeling describes identification of input and output values, DFD
for functional dependencies and identification of constraints.
5.2.3.1 Identification of Input / Output values
The System has following object and their input and output given in the table.
Table No 7: I/O Table
Sno Object Info Input Details Output Details
1 AcceptNewUser UserID Registration
Name Successful after
State Admin or Super
District Admin Approves the
Contact request
2 CRUD Property Listing_id Show response
Listing message within the
Title screen of success,
Last_Date error, delete
Description
District
Time
By_admin
Status
3 Crud property_types ID Profile update of
Property_types member after
entering the details
4 Crud Amenity ID Show Response
Amenity_name Message on particular
Details operation like add,
By_admin remove, update
5 Manage Broker Broker_id Show Response
Broker_percentage Message on particular
User_id operation like change
Status head and new head
6 Location ID Show response
Location_name message on operation
Active to add / update/ delete

Listing_id Location
7 Realstate Income ID Show response
Property_name message on operation
Date to manage Income
Sold_price
8 ContactDetails ID Show response
Name message on operation
Email to add, delete, update
Phone enquiry
Is_agent
Query
Property_id
9 AdminLog ID Writes log file on
Date_time every operation
Username performed by admin
Operation or superadmin
5.2.3.2 DFD as needed to show functional dependencies.
The DFD describes the data movement in the software which is shown in the diagram given
below:
Figure 7: DFD Diagram

5.2.4 Database Design

5.2.4.1 Schema definitions with Candidate key/Primary key
The System use following schema with corresponding candidate key.
Table No 8:Accept New User Schema Table

Accept New Users
Title Type Key
userid Int Primary key
Name Char
State Char
District Char
Contact Char
Accept New User = (userid, Name, State, District, Contact)
Table No 9:Listing Schema Table

CRUD Property Listing Schema Table
Title Type Key
listing_id Int Primary key
title Char
last_date Date
description Char
district Char
time DateTime
by_admin Char
status Char
CRUD Property Listing = (listing_id, title, last_date, description, district, time, by_admin,
status)
Table No 10: Types Schema Table

Property Types Schema Table
Title Type Key
id Int Primary key
property_types Char
Crud Property Types = (id, property_types)

Table No 11: Amenity Schema Table
Amenity
Title Type Key
id Int Primary key
amenity_name Char
details Char
by_admin Char
Crud Amenity = (id, amenity_name, details, by_admin)

Table No 12:Manage Broker Schema Table

Broker
Title Type Key
broker_id Int Primary key
broker_percentage Double
User_id Int
status Char
Manage Broker = (broker_id, broker_percentage, User_id, status)

Table No 13: Remove Location Schema Table
Location
Title Type Key
id Int Primary key
location_name Char
active Boolean
listing_id Int
Location = (id, location_name, active, listing_id)

Table No 14: Income Schema Table
Income
Title Type Key
id Int Primary key
property_name Char
date DateTime
sold_price Char
Realstate Income = (id, property_name, date, sold_price)
Table No 15: ActivityLog Schema Table

ActivityLog
Title Type key
id Int Primary Key
date_time DateTime
admin_username Char
operation Char
admin_activity = (ìd`, `date_time`, àdmin_username`, òperation`)

Table No 16: ContyactDetails Schema Table

ContactDetails
Title Type Key
id Int Primary key
name Char
email Char
phone Char
is_agent Boolean
query Char
property_id Int
ContactDetails = (id, name, email, phone, is_agent, query, property_id)
5.2.4.2 Normalization
In this Project Second Normal Form (2NF) database design has been applied to ensure efficient and
normalized data storage and retrieval. By adhering to the principles of database normalization,
specifically the 2NF, the project team has organized the database schema to minimize data
redundancy and maintain data integrity.

5.2.4.3 E-R Diagram

The ER Diagram has been desired in the project given below.
Figure 8: E-R Diagram

6. CONSTRUCTION PHASE

6.1. CASE Tools used to design

There was no case tools used for designing but for coding Visual Studio Code is used
6.2. Coding Language and Operating System (OS) and (Including

explanation)
In this project Windows OS is used as operating system far as language is concern python is used
because of its property and facility given.
6.3. Database Connectivity procedure

MYSQL Database connectivity is used and required code segment as follows.
Settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
},
#'default': {
# 'ENGINE': 'django.db.backends.postgresql_psycopg2',
# 'NAME': 'realproperty',
# 'USER': 'postgres',
# 'PASSWORD': 'Realyug@8088', #postgres123
# 'HOST': 'localhost',
# 'PORT': '5432',
#}
}
6.4. Code Description

Entire system code is seen in following table.
Table No 17: Code Description
S.no File name File size Purpose Constructor LOC
1 urls.py 3kb URL routing NA 78
configuration for
Django
admin.py 4kb Admin interface NA 230
2
configuration for

Django models
auth_views.py 8kb Handle NA 376
3 authentication-
related API views
authentication.py 3kb Handle JWT NA 310
4 token creation and
decoding
models.py 15kb Define database NA 490
5 models for the
application
send_mail.py 4kb Send OTP via NA 280
6 email for user
verification
serializers.py 5kb Define serializers NA 341
7 for various models
in the application
views.py 20kb Define API views NA 823
for property
8
documents and
interactions
settings.py 3kb Configure Django NA 182
settings, including
9
CORS and email
backend
manage.py 1kb Django's NA 22
command-line
10 utility for
administrative
tasks
Demoamenity.jsx 15kb Component for NA 513
displaying
11
amenities in a
demo
Header.jsx 5kb Navigation menu NA 284
12 with links to
various pages

Loginregister.jsx 10kb Component for NA 850

13 user login and
register
Propertydetails.js 20kb Component for NA 804
14 displaying
property details
Listing.jsx 12kb Component for NA 985
15
listing properties
Root.jsx 6kb Main landing page NA 335
16
component
Services.jsx 25kb Contains service NA 382
17 functions for API
calls
Similarproperties.jsx 8kb Component for NA 357
18 displaying similar
properties
19 login.html 5kb Template for user NA 209
login form in
Django
20 index.html 2kb Main index page NA 308
template for
Django
21 base.html 5kb Base template for NA 271
Django
application
22 base-fullscreen.html 6kb Fullscreen base NA 350
template for
Django
1 PropertyType.js 15kb Component for NA 414
displaying
property types
1 Forgetpass.jsx 12kb Component for NA 556
handling password
reset
1 Contact.js 10kb Component for NA 387
handling contact

form
1 Help.js 8kb Component for NA 422

displaying help
content
TOTAL 11559

6.5. I/O Interface
Homepage
About Page

Sign In
Broker Registration

Listing
Property Listing According To Property Type

Popular Property, Property type, Other Property type
Property Detail

Similar Property
Agent’s Details and Enquiry

Property Share
Property Comment

Property Like

7.TRANSITION PHASE

7.1. Report of Alpha testing
1) Blackbox unit testing for each object input are given and required output is obtained successfully.
2) Whitebox unit testing for each object for given input entire program flow including loops and
conditional statements are tested successfully.
3) Integrated system testing All objects are linked integrated and tested by given input and desired
output
4) Whitebox integrated system testing In this test all links between object and association has been
tested successfully and obtained desired output.
7.2. DSLOC and Cost estimate using DSLOC

The cost estimation is calculated using Intermediate COCOMO model:
Table 18: Effort adjustment factor

Cost Ratings
Driver Very low Low Normal High Very high Extra high
RELY 0.75 0.88 1.00 1.15 1.40
DATA 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
ACAP 1.46 1.19 1.00 0.86 0.71
PCAP 1.29 1.13 1.00 0.91 0.82
AEXP 1.42 1.17 1.00 0.86 0.70
VEXP 1.21 1.10 1.00 0.90
LEXP 1.14 1.07 1.00 0.95
TOOL 1.24 1.10 1.00 0.91 0.82
MODP 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10
Table 19: Coefficient of Intermediate COCOMO model

Software project a b c d
Organic 3.2 1.05 2.5 0.38
Semi Detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
On the basis of KDLOC and intermediate COCOMO model the cost is calculated as follows

Total Delivered SLOC of whole project is= 11.59 KLOC

Required software reliability= Nominal = 1.00
Size of application database= Nominal = 1.00
Complexity of the product= Low = 0.85
Use of software tools= High = 0.91
Required development schedule= Nominal = 1.0
EAF= 1.0*1.0*0.85*0.91*1.0 = 0.77
Effort = a(KLOC)^b * EAF = 3.2 * (11.59)^1.05 * 0.77 = 30.50PM
Duration = c(Effort)^d= 2.5(30.50)^0.38 = 9.16 Months
Person = Effort / Duration= 30.50 / 9.16 = 3.32 ~ 3 person
7.3. Cost variation between DFP and DSLOC

The cost variation is the difference between Actual value and estimated value and cost variation is
given below:
Effort Expected by DFP = 35.01 PM
Effort By Delivered SLOC = 30.50PM
Variance = Expected cost – Actual Cost
= 35.01 – 30.50 = 4.51 PM
Expected KLOC = 12.84 KLOC

Delivered KLOC = 11.59 KLOC
Variance in KLOC = Expected KLOC – Delivered KLOC
= 12.84-11.59 = 1.25 KLOC

8. Limitation and Future Enhancement

Limitations of the Project
1. No Recovery of the Password:

o Currently, the system does not support password recovery. If a user forgets
their password, there is no mechanism to reset or recover it .
2. Cannot Make Super Admin Dynamically:
o The project lacks the functionality to create or assign super admin roles
dynamically. This limitation restricts the ability to manage administrative roles
flexibly .
3. OTP Verification Depends on API Uptime:
o The One-Time Password (OTP) verification process is dependent on the
uptime and reliability of third-party APIs. If the API service is down, the OTP
verification process will fail, affecting user authentication .
Future Enhancements
These limitations can be addressed in future updates to improve user experience and system
functionality:
1. Implement Password Recovery Mechanism:

o Introduce a secure password recovery feature that allows users to reset their
passwords through email or SMS verification. This enhancement will
significantly improve user convenience and security.
2. Dynamic Super Admin Management:
o Develop a feature to dynamically assign and manage super admin roles. This
will provide greater flexibility in administrative management and enhance the
overall control over the system.
3. Enhance OTP Verification Reliability:
o To mitigate dependency on third-party API uptime, consider implementing
fallback mechanisms or multiple API providers for OTP verification. This will
ensure higher reliability and availability of the OTP verification process.
9. Conclusions
The Real Estate Property Management System project represents a significant advancement in
addressing the accessibility issues faced by the community. The transition to a computerized
solution has been well-received and marks a departure from traditional methods, adopting modern
software practices over the conventional waterfall technique.
The development followed an organic type project approach with four distinct phases: Inception,
Elaboration, Construction, and Transition. During the Inception phase, a total of 230 function
points were identified, laying the groundwork for the detailed design and implementation phases
that followed.
Throughout the Elaboration phase, comprehensive designs were developed encompassing the
system-object model, as well as dynamic and functional models, ensuring a robust foundation for
the system. The backend implementation was carried out using Django, React, with MySQL

serving as the database system, resulting in a total of 11.59 KLOC (thousands of lines of code).
The calculated effort required for the project amounted to 30.50 person-months.
The system underwent extensive testing, ensuring that all errors were addressed and that the
system met the specified requirements. The successful testing phase confirms the reliability and
effectiveness of the system, making it a valuable tool for real estate property management.
In conclusion, this project not only resolves the accessibility issues but also provides a scalable
and efficient solution for future enhancements. The adoption of modern development practices
and thorough testing ensures that the system is both reliable and adaptable, promising a better user
experience and operational efficiency for the community.

Real State Property Final Print

Uploaded by

Copyright:

Available Formats

Real State Property Final Print

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Real State Property Final Print

Uploaded by

Copyright:

Available Formats

Realstate Property Management System

BHILAI INSTITUTE OF TECHNOLOGY, DURG

Chhattisgarh Swami Vivekanand Technical University, Bhilai (CG)

in the partial fulfillment of the requirements for the award of

MASTER OF COMPUTER APPLICATIONS

Roll No.: 500102122035

Enrollment No.: CC2742

Under the Guidance of

Dr. Vinita A Gupta

DEPARTMENT OF COMPUTER APPLICATIONS,

Signature of the Supervisor/Guide

Signature of Project Coordinator Signature of Head of Department

(Internal Examiner) (External Examiner)

No. Heading Page No.

5.1.2.3. Performance Requirement

5.2. ELABORATION PHASE (DETAIL DESIGN) 10

5.2.1.3 Association between classes. 14

5.2.1.6 Object Diagram. 15

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

4. Project Development Process Model Used (Methodology).

Figure 1: The Phase of life cycle process

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

5.1.1. Initial Description of Problem

5.1.2. Software Requirement Specification - SRS

5.1.2.1. Non-Functional Requirements

5.1.2.2. Functional Requirements

• Accept New User

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

• Add Update Admins

• Manage Activity Logs

• Manage Property Types

• Manage Income Details

5.1.2.3. Performance Requirements

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

5.1.3. Security Features

• User Interface: Reliability of user interface is High.

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

5.1.5. Cost Estimation Using DFP

Table No 2: Complexity Factor

External Inputs: 17 Internal logical Files: 14

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

UFP= 17*3 + 11*4 + 9*3 + 14*7 + 4*5 =226

CAF= 0.65 + 0.01*N N= Complexity factor=30

DFP= UFP * CAF = 240 * 0.95 =228

Table no:3 Coefficient of Basic COCOMO

By basic COCOMO model for organic project

Expected Effort = a(KLOC)^b = 2.4(12.84)^1.05 = 35.01 PM

Expected Duration = c(Effort)^d = 2.5(35.01)^0.38 = 9.6 Months

Expected Person = Effort / Duration = 35.01 / 9.6 = 3.64 ~ 3 Person

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

5.2. ELABORATION PHASE

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

5.2.1 Object Model

Table No 4: Object Classes

SNo. Name of Object/Class Description

2 Int listing_id Listing_id: int(11) void crud This

Bhilai Institute of Technology, Durg Department of Computer Application 2022-2024

String title title: char(20) PropertyDocument method is

UFP= 173 + 114 + 93 + 147 + 4*5 =226