Online Complaint Portal - TutorialsDuniya
Online Complaint Portal - TutorialsDuniya
Online Complaint Portal - TutorialsDuniya
COM
Online Complaint
Portal
Software Engineering Project
om
.c
COUrSe – BSC (H) COmpUter SCienCe
i ya
un
SemeSter - 4tH
prepared By
D
mOSeSBOU marenmai(1234)
SaUraBH (1234)
ia
HANSRAJ COLLEGE
University of Delhi
CERTIFICATE
This is to certify that the project entitled, “ONLINE COMPLAINT PORTAL” has been done by:
AKASH DWIVEDI,MOSESBOU,SAURABH,ADITYAof Bachelor of Science in Computer Science
om
during semester IV from Hansraj College(Day) University of Delhi under the supervision of
TutorialsDuniya.
.c
i ya
un
D
ls
ia
t or
Tu
DECLARATION
I hereby declare that this Project Report titled “ONLINE COMPLAINT PORTAL”
submitted to the Department of Computer Science , Hansraj College(Delhi University) is a
record of original work done by the team under the guidance of TutorialsDuniya.
om
The information and data given in the report is authentic to the best of the team knowledge.
This Project Report is not submitted to any other university or institution for the award of
any degree, diploma or fellowship or published any time before.
.c
i ya
un
D
ls
ia
t or
Tu
ACKNOWLEDGEMENT
The contentment that is achieved on the successful completion of any task is incomplete
om
without mentioning the names of the people who made it possible with their consistent
guidance, support and indispensable encouragement.
.c
supervision of TutorialsDuniya.com. Our primary thanks to her , who poured over every inch
of our project with painstaking attention and helped us throughout the working of the project.
ya
It’s our privilege to acknowledge our deepest sense of gratitude to her for her inspiration
which has helped us immensely. We are extremely grateful to her for unstilted support and
encouragement in the preparation of this project.
i
un
D
ls
ia
t or
Tu
Process Model
INCREMENTAL MODEL
The incremental model combines elements of the waterfall model applied in an iterative
fashion. Referring to the figure, the incremental model applies linear sequences in a staggered
fashion as calendar time progresses. Each linear sequence produces deliverable “increments” of
the software.
om
When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed, but many supplementary features (some known, others
unknown) remain undelivered. The core product is used by the customer (or undergoes detailed
evaluation). As a result of use and/or evaluation, a plan is developed for the next increment.
The plan addresses the modification of the core product to better meet the needs of the
.c
customer and the delivery of each increment, until the complete product is produced.
i ya
un
D
ls
ia
t or
Tu
The reason for using this that the concept of our software is vast and there are a lot of modules that are
required to be built. This increases the chances of an error. Use of an increment model will allow us to
analyze our project after completion of each module. Thus we can change our requirements at the
start of each module.
Moreover after our first increment, we can launch our core product for the users. After use,
evaluation and feedback by the users we can modify our software and take it to a more advanced
level.
TABLE OF CONTENTS
om
1.1.2 User Characteristics ..................... .
.c
1.2 External Interface Requirements .......
ya
1.2.1 User Interfaces ............................. .
2. Estimations ........................................... .
2.1 Function Points .................................................................................... 8
ls
3. Scheduling ............................................ .
ia
6. TESTING ............................................. .
6.1 PSEUDOCODE ……………………………………………….....12
7. References
om
Through this a citizen can file complaint regarding any area in Delhi. Then the complaint is
forwarded to the government officer. The officer then can resolve that compliant and then give a
confirmation to the citizen through our site.
Thus it will act as an interface between the government and the citizens.
.c
1.1.1 Product Functions
ya
Initial functional requirements will be:-
Registration for both citizen and officer.
Login and logout mechanism for both citizen and officer.
i
Complaint filing window allowing citizens to file complaints.
un
Mechanism to assign complaints to an officer.
Mechanism to allow citizen to check complaints.
Mechanism to allow officers to update complaint status.
Mechanism to inform citizen about complaint status.
D
the website.
Mechanism for updating citizen and officer record on successful filing of complaint and
ia
Section 2 gives an overall description of the software. It gives what level of proficiency is
Tu
expected of the user, some general constraints while making the software and some
assumptions and dependencies that are assumed.
Section 3 describes the analysis model of the software. It includes data flow diagram (DFD),
data dictionary, entity relationship diagram (ERD), use cases, sequence diagram, state
transition diagram and activity diagram.
Section 4 gives the planning phase of the software. It includes project scheduling,
cost estimation and risk management strategy that are adopted in this project.
Section 5 contains the design phase of the software. It includes structured design
methodology (SDM) for the software.
om
having to face big queues of a government office. Thus this project envisages bridging the gap
between the citizen and the officer. OCP should be user-friendly, ‘quick to learn’ and reliable
software for the above purpose. OCP is intended to be a stand-alone product and should not
depend on the availability of other software.
.c
Product Functions
ya
User: Citizen
Functions:
i
1. Citizen can sign up with the website.
un
2. Citizen can file a complaint through this application provided that he is registered with this
application.
3. The Citizen can also check the status of the complaint by giving the complaint id of the
complaint.
D
4. The Citizen also gives confirmation about the resolution of the complaint. Only then a
complaint is considered to be closed.
ls
Functions:
or
1.1.3Constraints
No multilingual support.
Complaints for Delhi are filed only.
Screens
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
ia
t or
Tu
om
.c
1.3 Data Flow Diagram (DFD)
i ya
un
1.3.1 LEVEL-0
0 DFD.
D
ls
ia
t or
Tu
om
.c
i ya
un
D
ls
1.3.3 LEVEL-2
2 DFD (LOGIN PROCESS)
ia
t or
Tu
1.3.4 LEVEL-2
2 DFD (FEEDBACK PROCESS)
om
.c
i ya
un
1.3.5 LEVEL-2 DFD (COMPLAINT PROCESS
PROCESS)
D
ls
ia
t or
Tu
1.3.6 LEVEL-2
2 DFD (COMPLAINT STATUS)
om
.c
ya
1.3.7 LEVEL-2
2 DFD (COMPLAINT MANAGEMENT)
i
un
D
ls
ia
t or
Tu
om
Citizen Details=C_ID+Cname
Update record=Filed_Complaints
Area details= Area_ID+AreaName+O_ID
Officer Details=O_id+Area+Complaints_pending
.c
Comp Details=comp_id+area
Update comp record=comp_id+o_id
Status = Pending|Resolved|Closed
ya
Citizens = [C_ID + Firstname + Lastname + Username + Password + Email + Mobile + Filed_Complaints]*
Officers = [O_ID + Firstname + Lastname + Username + Password + Email + Mobile + Area +
Complaints assigned + Resolved_complaints]*
i
Area = [Area_ID + Name + [O_ID]*+ Total_Comp]*
un
Complaints = [Comp_ID + Date + Title + C_ID + O_ID + Area + Photo + Comment + Status]*
D
ls
ia
t or
Tu
Area
O_ID
C_ID
Photo
Title
Comment
om
Date
COMPLAINTS Status
.c
Comp_ID
N N
ya
O_id
FILES ASSIGNED Resolved
Filed_Comp i
un
N
Fname
1
Mob 1
D
Pwd Email
Pwd
OFFICERS
ls
N
Lname
or
C_id Uname
Uname
Assigned
Fname
t
Lname
IN CHARGE
Tu
1
Total_comp from
M
to
Area_ID
AREA
Name O_ID
Use cases
Use Case 1: File a Complaint
Primary Actor: Citizen
om
Precondition: Citizen has logged in
1. Citizen files a complaint by uploading a photo and giving details of the complaint.
2. System checks citizen’s details and then updates citizen’s record.
.c
3. Complaint ID is returned to the citizen.
Exception Scenario:
ya
1. The photo exceeds the maximum size.
System prompts the citizen to upload another photo of adequate size.
i
un
Use Case 2: Assign Complaint
Primary Actor: System
D
1. System checks the area in the complaint and looks for the officer of that area.
ia
2. System assigns the complaint to that officer and update the complaint as well.
3. Message is sent to officer’s account.
or
Exception Scenario:
System assign the complaint to the officer with the least no. of unresolved complaints.
Tu
om
2. System searches for the complaint ID and displays the details of the complaint.
Exception Scenario:
.c
System informs the citizen and asks to reenter the complaint ID.
ya
Use Case 4: Update complaint status
Primary Actor: Officer
Exception Scenario:
Citizen notifies the officer and changes the complaint status from ‘Resolved’ to
‘Pending’.
File a Complaint
om
Assign a Complaint
.c
CITIZEN
ya
Check Complaints
i
un
Update Complaint
Status
D
ls
ia
System Boundary
SYSTEM
om
Invalid passwords/ID
.c
Valid passwords/ID
Complaint filed
Exit
om
area name
.c
ya
Officer ID found Multiple Officer IDs found
Assign Complaint to
ia
the officer
t or
Tu
Exit
om
Invalid passwords/ID
.c
Valid passwords/ID
Give complaint ID
ia
or
Exit
om
.c
Wait for feedback
i ya
un
Positive reply Negative reply
D
ls
Exit
2. Estimation
2.1 Problem Based Estimation
FUnCtiOn pOint metriCS
Our DFD contains the following things:
om
External inputs = 5
External outputs = 1
.c
External Inquiries = 1
ya
External Interfaces = 0
External Inputs = 5 X 3 4 6 = 18
D
External Outputs = 1 X 4 5 7 = 4
External Inquiries = 1 X 7 10 15 = 7
ia
External Interfaces = 0 X 5 7 10 = 0
Count Total 42
or
1. Data Communications 0
2. Distributed Data Processing 0
3. Performance 2
4. Heavily Used Configuration
om
2
5. Transaction Rate 0
6. Online Data Entry 0
7. End-User Efficiency 1
.c
8. Online Update 2
9. Complex Processing 1
ya
10. Reusability 3
11. Installation Ease 2
12. Operational Ease i 1
un
13. Multiple Sites 0
14. Facilitate Change 1
Total Degree of Influence (TDI) 15
D
Degree
0 = Not present
1 = Insignificant Influence
ia
2 = Moderate Influence
3 = Average Influence
or
4 = Significant Influence
5 = Strong Influence
t
Tu
om
Taking the values from the given tables:
.c
i ya
un
D
ls
ia
PROD=4
3.Scheduling
3.1.1 TIMELINE SCHEDULING.
om
.c
i ya
un
D
ls
ia
t or
Tu
om
Larger number of users than
PS 30% 3
planned.
.c
End-users resist system BU 40% 3
ya
Delivery deadline will be tightened.
BU 50% 2
expectations.
DE 80% 3
ls
Staff inexperienced.
PD 40% 2
or
om
Less reuse than planned. Development time Develop efficient SRS.
will increase.
Customer will change Might lead to start of Choose an efficient
requirements. development from model that can cope
.c
scratch. with sudden changes
in requirements.
ya
Staff Inexperienced. Might lead to Choose the project
development of team efficiently with
i
incomplete software. proper mix of
un
Completed project experiences
may receive poor
reviews.
D
om
incomplete. May get rejected by be carefully
the customer. understood and
documented.
.c
Confusion among the Incomplete and Pseudo code should
developers regarding inefficient software. be
ya
the pseudo code. kept simple and easy
to understand.
Lack of training on tools. Inefficient software
i Developers should be
product with chances well trained and
un
of defects. comfortable with the
development tools.
D
situations.
t
Tu
5. Design
5.1 Structured Design Methodology
om
.c
Get
Complaint ID
ya
Get
Login Complaint
User Database
Title, comment, Details
Uname & i photo, area
un
passwd
userID
Title,
Validat
ls
comm Valida
ed
ent, ted
uname Validat uname,
Validated
photo unam
ia
ed cID
Validate
oID,
, area e,
d uname
compI
CompID
D
or
Update
Check
t
Check
File Complaint
Tu
Complaint User
Complaint Status Status Details
oID, cID,
cname, oname,
comp st
cemail, oemail,
_ID at st
tcomp, ccomp, System Database
us at
System Database us rcomp, pcomp
Response Print
Download FREE Software Engineering Projects from TutorialsDuniya.com
Download FREE Software Engineering Projects from TutorialsDuniya.com
Most Abstract Inputs (MAI): uname, comp_id, title, comment, photo, area
om
Most Abstract Output (MAO):
cID,oID,cname,oname,cemail,oemail,tcomp,ccomp,rcomp
,pcomp,comp_id,status
.c
Step 3: First Level Factoring
i ya
un
Login cID, oID, cname, oname, cemail, oemail, tcomp,
uname ccomp,rcomp, pcomp Print Details
comp_id
Get Complaint
D
Main
ID cID,
Title, comment, photo, area
Tit comp_id, status
oID,
ls
le, cnam
Response
Get Complaint e,
oID,cID co
onam
Details m co
ia
oI e,
co
m m D,
m cema
en p_ cI
p_ il,
or
t, D oema
Get UserID ph st
co st il,
ot at
m at tcom
us
us p,
t
p_
ccom
Tu
p,rco
Check Update Status
File Complaint mp,Check Details
Complaint pcom
p
om
Get
Login Complaint ID
Co
un
.c
mp
am
_id
e
Check
ya
Check
un
passwd Co
am
e
i mp
un
_id
Get Get Password
Get Password
Username
D
ls
Tiltle Details
use comment
rID Ph
or
oto
Title Comment
Check ,
are
t
oID Check
Tu
cID
File Complaint
om
Co
Title, comment, photo, area
m oI
p_i co D
d m
.c
p_i
d
Generate ComplaintID Assign Complaint
ya
co
m
an
i p_i
am oI
un
d aname
e D
Get oID
D
Get AreaID
ls
ia
or
co
co mp
mp sta _id fla
_id tus , g
sta
tus
Get Status Set Status
Check Details
om
userI cID, oID, cname, oname, cemail, oemail, tcomp,
D ccomp,rcomp, pcomp
.c
Get details
oID,
ya
cnam oID,
e, oname,
userI
cemai oemail,
D
l, i userI rcomp,
un
tcomp D pcomp
,
ccom
p
D
6. Testing(White Box)
Procedure file
om
1. Output ‘Title :’
2. Input title
3. Output ‘Photo :’
.c
4. Input photo
1
5. Output ‘Area :’
ya
6. Input area
7. Output ‘Comment :’
8. Input comment i
un
9. If(user clicks on ‘submit’) 2
10. Search area name in database 3
11. If(area name equals area) 4
D
6
14. endif 7
15. Search oID from area_id in database 8
ia
20. Endif 13
21. Endif 14
22. Increment comp_id by 1 15
23. Update complaints database with comp_id and officer details
24. Endif 16
om
ensure that all statements have been executed at least once.
Cyclomatic complexity has a foundation in graph theory and is computed in one of the three
ways:
.c
1. The number of regions corresponds to the cyclomatic complexity.
2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V (G) = E-N+2
ya
Where E is the number of flow graph edges, and N is the number of flow graph nodes.
3. Cyclomatic complexity, V(G), for a flow graph, G, is also defined as
V (G) = P+1
i
Where P is the number of predicate nodes contained in the flow graph G.
un
Referring to flow graph in section 6.2, the cyclomatic complexity can be computed using each of
D
8.References
Books:
[1] R.S. Pressman, Software Engineering: A Practitioner’s approach, sixth edition, McGraw Hill, 2006
[2] P. Jalote, An Integrated Approach to Software Engineering, third edition, Narosa Publishing House, 2003
om
[3] P. Jalote, A Concise Introduction to Software Engineering
Websites:
[1] https://www.tutorialsduniya.com
.c
[2] https://www.tutorialsduniya.com
ya
[3] https://www.tutorialsduniya.com
[4] https://www.tutorialsduniya.com
i
un
D
ls
ia
t or
Tu