FYP Documentation Online Doctor Finder V 1.7 Online Doctor Finder - Docx ADP

Department of Computer Science
University of Gujrat
Crime Management System
Submitted By
Amtul Masawar (2019-GCUF-067405)
Maida Ijaz (2019-GCUF-067411)
Bisma Khalid (2019-GCUF-067402)
Rabia Asgher (2019-GCUF-067412)
Final Semester Project
Session: ADP (CS) 2019-2021
Supervised By
Online Doctor Finder
STATEMENT OF SUBMISSION
It is verified that this project titled Online Crime Management System by Amtul
MasawarD/O
Maida Ijaz (Roll # 2019-GCUF-067411) Rabia Asghar D/O Imtiaz Rasool (Roll #
18250819021) and Bisma D/O Nazar Hussain, Roll # (18250819-036), students of
associate degree in (Computer science) at Department of Computer Science, GC
University Faisalabad, Pakistan, contains sufficient material required for the award of
above said degree.
Project Management Office

Department of Computer Science,
Faculty of Computing & IT, GC
University Faisalabad, Pakistan.
Head of Department,
Assistant Prof. Department of Computer Science,
Project Supervisor Faculty of Computing & IT, Department of Computer Science, GC University
Faisalabad, Punjab
Pakistan.
© Department of Computer Science, Faculty of C& IT i

ACKNOWLEDGEMENT
Start with the name of Allah, who is most benevolent and most generous. All praises to
Allah almighty, who gave us strengths and ability to complete this project. We truly
acknowledge the cooperation and help made by Head of Department, Computer Science
Dept. University of Gujrat. He has been a constant source of guidance throughout the
course of this project We would also like to thank our honorable supervisor Assistant
Prof. Najeeb Ur Rehman for his help and guidance throughout this project. His valuable
help, constructive comments and suggestions contributed to the success of this project.
We are also thankful to our families whose unflinching faith in us has driven us forward.
Finally, we want to say thanks to our friends who were there to support us.
Date: 22 August 2020
© Department of Computer Science, Faculty of C& IT ii

Abstract
The “Crime Management System” is a web based application for online complaining and
computerized management of crime records. Here in this website a person who wishes to file a
complaint or report an incident must register before log-in and once the admin authenticates
the user he or she can login into the website and file a complaint. This complaint will be
received by police and police can send a message regarding status of the complaint to the user
who filed the complaint. Police can use this software to manage different crimes and some of
the works which is done in police station manually. Police gets their login password from
admin directly. Some of the modules like unidentified dead bodies, missing persons, and most
wanted criminals can be viewed through the website without logging in. So this website helps
police to find out the problems in the society without them actually coming to the police
station. Key Words: FIR-First Information Report
TABLE OF CONTENTS
CHAPTER 1: PROJECT FEASIBILITY...............................................................................1
1.1. INTRODUCTION.................................................................................................................1
1.2. PROJECT/PRODUCT FEASIBILITY REPORT.........................................................................1
1.2.1. Technical Feasibility.................................................................................................1
1.2.2. Operational Feasibility.............................................................................................2
1.2.3. Economic Feasibility.................................................................................................2
1.2.4. Schedule Feasibility..................................................................................................2
1.2.5. Specification Feasibility............................................................................................2
1.2.6. Information Feasibility..............................................................................................2
1.2.7. Motivational Feasibility............................................................................................2
1.2.8. Legal & Ethical Feasibility.......................................................................................2
1.3. PROJECT/PRODUCT SCOPE.................................................................................................2
1.4. PROJECT/PRODUCT COSTING.............................................................................................3
1.4.1. Project Cost Estimation By Function Point Analysis................................................3
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)...........4
1.5. TASK DEPENDENCY TABLE...............................................................................................5
1.6. CPM - CRITICAL PATH METHOD.......................................................................................6
1.7. GANTT CHART...................................................................................................................7
1.8. INTRODUCTION OF TEAM MEMBERS AND SKILL-SET........................................................7
1.9. TASK AND MEMBER ASSIGNMENT TABLE.........................................................................8
1.10. TOOLS AND TECHNOLOGY WITH REASONING...................................................................8
1.11. VISION DOCUMENT........................................................................................................10
1.12. RISK LIST......................................................................................................................10
1.13. PRODUCT FEATURES/ PRODUCT DECOMPOSITION.........................................................10
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATIONS (SRS)......................11
2.1 INTRODUCTION.................................................................................................................11
2.2 EXISTING SYSTEM............................................................................................................11
© Department of Computer Science, Faculty of C& IT iii

2.3 PROJECT SCOPE................................................................................................................11

2.4. SUMMARY OF REQUIREMENTS: (INITIAL REQUIREMENTS)..............................................11
2.4.1. Manage Doctors......................................................................................................11
2.4.2. Manage Appointments.............................................................................................11
2.4.3. Manage Patients......................................................................................................11
2.4.4. User Registration....................................................................................................11
2.5 IDENTIFYING EXTERNAL ENTITIES...................................................................................12
2.6 "SHALL" STATEMENTS.....................................................................................................12
CHAPTER 3: DESIGN DOCUMENT (FOR STRUCTURED APPROACH)..................13
3.1. INTRODUCTION:...............................................................................................................13
3.2. ENTITY RELATIONSHIP DIAGRAM....................................................................................13
3.3. DATA FLOW DIAGRAM (FUNCTIONAL MODEL)...............................................................14
3.4. STATE TRANSITION DIAGRAM.........................................................................................15
3.5. ARCHITECTURAL DESIGN................................................................................................16
3.6. COMPONENT LEVEL DESIGN............................................................................................18
CHAPTER 4: USER INTERFACE DESIGN.......................................................................19
4.1. INTRODUCTION................................................................................................................19
4.2. SITE MAPS.......................................................................................................................19
4.2.1 Homepage View.......................................................................................................19
4.2.2 Admin Login Side.....................................................................................................20
4.3. STORY BOARDS...............................................................................................................20
4.3.1 Home Page...............................................................................................................20
4.3.2 Search Doctor..........................................................................................................21
4.3.3 Contact:....................................................................................................................21
4.3.4 Blog:.........................................................................................................................21
4.3.5 Admin Login:............................................................................................................22
4.3.6 Doctor Login:...........................................................................................................23
4.3.7 Patient Login:...........................................................................................................23
CHAPTER 5: SOFTWARE TESTING................................................................................24
5.1 INTRODUCTION.................................................................................................................24
5.2. TEST PLAN.......................................................................................................................24
5.2.1. Purpose...................................................................................................................24
5.2.2. Outline.....................................................................................................................24
5.3. TEST DESIGN SPECIFICATION...........................................................................................28
5.3.1. Purpose...................................................................................................................28
5.3.2. Outline.....................................................................................................................28
5.4. TEST CASE SPECIFICATION..............................................................................................31
5.4.1. Purpose...................................................................................................................31
5.4.2. Outline....................................................................................................................31
5.5. TEST PROCEDURE SPECIFICATION....................................................................................32
5.5.1. Purpose...................................................................................................................32
5.5.2 Outline......................................................................................................................32
5.6. TEST ITEM TRANSMITTAL REPORT..................................................................................34
© Department of Computer Science, Faculty of C& IT iv

5.6.1. Purpose...................................................................................................................34
5.6.2. Outline.....................................................................................................................34
5.7. TEST LOG.........................................................................................................................35
5.7.1. Purpose..................................................................................................................35
5.7.2. Outline.....................................................................................................................35
5.8. TEST INCIDENT REPORTS..................................................................................................36
5.8.1. Purpose...................................................................................................................36
5.8.2. Outline.....................................................................................................................36
5.9. TEST SUMMARY REPORT.................................................................................................37
5.9.1. Purpose...................................................................................................................37
5.9.2. Outline.....................................................................................................................37
TABLE OF FIGURES
Figure 1:Network Diagram ................................................................................................. 6
Figure 2:Gantt Chart ........................................................................................................... 7
Figure 3: ERD - Online Doctor Finder ............................................................................. 13
Figure 4: Context Level DFD ........................................................................................... 14
Figure 5: Level-1 DFD...................................................................................................... 15
Figure 6: Level-2 DFD...................................................................................................... 15
Figure 7: State Transition Diagram................................................................................... 16
Figure 8: Architecture Diagram ........................................................................................ 17
Figure 9: Component Diagram ......................................................................................... 18
Figure 10: Homepage View .............................................................................................. 19
Figure 11: Admin Login Side ........................................................................................... 20
© Department of Computer Science, Faculty of C& IT v

Chapter 1: Project Feasibility

1.1. Introduction
2. Online crime management system will help in storing records related to the criminals, cases,
complaint record, and case history and so on. It will allow a person to enter or delete his/her
own complain. All these records will be maintained in a single database. Security of record
will be maintained so only the authorized users will access to the system.
3. This website will be one of the useful projects that the police can rely on. It can help in
getting the information of the criminals of many years back. Officers can also add the details
about the different guards that are on duty. Jailors can change attributes like time-shift duty
hours of guards. Jailor can also write the First Information Report and can save it. FIR’s
date, time, number, and details can be seen any time if required by the registered user. This
system gives a unique id to every FIR as required and the prisoner number will also be
unique.
4. This system has one more user which is admin. Admin can add the user (jailor) and delete
the user. All other attributes can only be changed by the user. This system talks about any
crime that is done and if any complaint is made to the police or if any FIR is done and if the
criminal gets caught and we can update the information about the case and one other benefit
is that if the complaint is registered online then it can be checked by all the registered users
and if there is any update about any complaint then it can be added online.
5. It increases the efficiency of the police to caught criminals. The crime management system
can be implemented in every prison without any problem. This system has the capability to
maintain an infinite number also updated automatically when any change is made in any
record.
6. The other important function given is postmortem, if any dead body is found in any case,
then the postmortem report will also be updated online with the case. There are two types of
users but only limited privileges are given to both the users according to the need. There is
no option to delete a prisoners’ record because it may be required later by the government to
know any details about the person and can help in the tracking of the prisoner.
7. Admin can verify and add users but cannot see the complaints that are saved by users in the
database because these files must be kept secret and only the required person could check
the files. Some other features are criminals’ details, checking records, registering users, etc.
Moving on Further we will see the designing of the system and attributes of it on the
principles of which our system does work properly. The features that can be included in this
website are as follows:
7.1. 1.1crime category:
8. There will be categories of crime so that the people can report easily about the particular
crime.
9. 1.2Criminal record:
10. This website will contain the details related to the criminals in the particular case.
11. 1.3 Complaint registration:
12. The details of the complaints that are registered can also be stored through this website.
13. 1.4 Police database management:
14. The details of the police in the particular police station can be maintained through this
website
© Department of Computer Science, Faculty of C& IT 1

15. of records. It is very useful as the written papers have a limited time period and can get lost
but in the crime management system, this is not possible as a backup file will be created
automatically and Abstract
1.2. Project/Product Feasibility Report

When a project is started the first matter to establish is to assess the feasibility of a project or
product. Feasibility means the extent to which appropriate data and information are readily
available or can be obtained with available resources such as staff, expertise, time, and
equipment. It is basically used as a measure of how practical or beneficial the development of
a software system will be to you (or organization). This activity recurs throughout the life
cycle.
There are many types of feasibilities:
• Technical
• Operational
• Economic
• Schedule
• Specification
• Information
• Motivational
• Legal and Ethical
1.2.1. Technical Feasibility

This project is for reporting crime according to the crime. After discussing and finalizing the
project, we conclude that much of the online crime management websites are made in PHP
that is a programming language and MYSQL that is a database technology. So, the
technology we are using to achieve this goal is PHP and MYSQL. This technology works
great and makes our users satisfy and all their needs. We are more familiar with the web-
based projects and the requirements of technology to achieve the project’s goals. Also, we
are more familiar with PHP technology rather than .NET or else. Therefore, it would be less
risky for us to understand and to use the development tool and hardware environment. Also,
on the user’s side, the more users familiar with the systems development process, the more
likely they understand the need for their involvement and this involvement can lead to the
success of the project. There are also some core tool and technologies that will be a part of
this project.
• HTML, CSS & Bootstrap
• PHP
• JavaScript
• Dream Weaver
• XAMPP

1.2.2. Operational Feasibility
Our team ensures victims that the project will be operationally successful as it is a web-
based project specifically designed to help in reporting crime as soon as possible. The user
interface is very simple and minimalistic which is easily understandable for almost all the
users.
1.2.3. Economic Feasibility
Development cost is very minimal as the tools used in project are available online. There are
no specific personal costs. The companies purchasing the system will be provided with a
manual for training purposes. Another reason for this project’s economic feasibility is that
no new hardware would be required to run the system as current hardware can fully support
it.
1.2.4. Schedule Feasibility

Time is an important factor. The project’s status is exactly according to the planned goals.
Meeting deadlines and milestones are properly kept in check.
1.2.5. Specification Feasibility
In online crime management system the specifications are suitable for both the end users
and the system administrator. The requirements are clear and definite.
1.2.6. Information Feasibility
This portal should be reliable in term of usage. User can easily report crime at the spot. We
will provide the reliable system to user with a beautiful interface, guide user for error and
provide a suitable solution for that. The system shall provide Review section to the user to
add his reviews about our website and report working in both cases i.e. satisfied or
unsatisfied. There will also be an option available for the user to contact with admin about
any query. It will be Complete User Manual. It Contains Complete Documentation how to
use the Development tool.
1.2.7. Motivational Feasibility

The website is designed in such a way that it encourages its clients to take further actions
such as signing up for reporting crime.
1.2.8. Legal & Ethical Feasibility

There are no illegal and immoral issues that would take place after completion of the
project. The project is absolutely a legal one, as it would not create any problem for others.
1.3. Project/Product Scope

This is computerized system that reduces manual work. Users can interact easily with this
system. In the online system, it is an overhead to keep the records related to crime reporter,
officers, and police station on the papers. It is a very time-consuming process and it costs
much more. So, the idea of online crime management system is formed in order to
computerize the crime management by allowing the victims to report crime through an online
crime management system. Including information about the crime, area, time of crime.
1.4. Project/Product Costing

A metric is some measurement we can make of a product or process in the overall
development process. Metrics are split into two broad categories:

• Knowledge oriented metrics: these are oriented to tracking the process to evaluate,
predict or monitor some part of the process.
• Achievement oriented metrics: these are often oriented to measuring some product
aspect, often related to some overall measure of quality of the product.
Most of the work in the cost estimation field has focused on algorithmic cost modeling. In
this process costs are analyzed using mathematical formulas linking costs or inputs with
metrics to produce an estimated output. The formulae used in a formal model arise from the
analysis of historical data. The accuracy of the model can be improved by calibrating the
model to your specific development environment, which basically involves adjusting the
weightings of the metrics.
1.4.1. Project Cost Estimation By Function Point Analysis
Following are the Information domain values of our project:
Number of user inputs: 25 user inputs

Number of user outputs: 20 user outputs
Number of user inquiries: 10 user inquiries
Number of files: 10 internal files
Number of external interfaces: 7 interface files
Using average values of Complexity of components

Unadjusted Function Points (UFP) = (25*4) + (20*5) + (10*4) + (10*10) + (7*7) = 389
To compute function points (FP), the following relationship is used:
FP est. = Count Total (UFP) * [ 0.65 + 0.01 * (Fi)]
1.Data communications = 3 8.On-Line update = 5

2.Distributed data processing = 2 9.Complex processing = 3
3.Performance = 3 10.Reusability = 5
4.Heavily used configuration = 2 11.Installation ease = 0
5.Transaction rate = 3 12.Operational ease = 2
6.On-Line data entry = 5 13.Multiple sites = 0
7.End-user efficiency = 2 14.Facilitate change = 2

FP est. = 389 * [ 0.65 + 0.01 * (37)] = 389 * [1.02] = 396.78
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)

LOC = 67055
Total LOC/FP = 67055/396.78
KLOC (Kilo lines of code) = FP * (LOC/FP) /1000
KLOC = 513.06 * 169 / 1000
KLOC = 86.707
Basic COCOMO:
Type Effort Schedule

Organic PM=2.4(86.707)1.05=260.11 TD=2.5(260.11)0.38=20.68
Semi-Detached PM=3(86.7)1.12=444.36 TD=2.5(444.36)0.35=21.12
Embedded PM=2.4(86.7)1.20 =508 TD= 2.5(508)0.32=18.35
PM= person-month (effort)

KLOC= lines of code, in thousands
TD= number of months estimated for software development (duration)
Intermediate COCOMO: Cost

Driver Categories:
• Product Attributes o RELY --- Required Software
Reliability (1.15) o DATA --- Data Base Size (1.00)
o CPLX --- Software Product Complexity (0.85)
• Computer Attributes o TIME --- Execution Time
Constraint (-) o STOR --- Main Storage Constraint (-)
o VIRT --- Virtual Machine Volatility (-) o TURN ---
Computer Turnaround Time (0.7)
• Personnel Attributes o ACAP --- Analyst Capability
(0.7) o AEXP --- Applications Experience (1.00) o
PCAP --- Programmer Capability (1.00) o VEXP ---
Virtual Machine Experience (-) o LEXP ---
Programming Language Experience (1.00)
• Project Attributes o MODP --- Modern Programming
Practices (1.15) o TOOL --- Use of Software Tools
(1.65) o SCED --- Required Development Schedule
(1.30)
Cost Drivers (M) = 1.15 x 1.00 x 0.85 x 0.7 x 1.00 x 1.00 x 1.00 x 1.15 x 1.65 x 1.30 = 1.69
Type Effort
Organic PM= 2.4 (86.707)1.05 x 1.69 = 439.59
Semi-Detached PM= 3.0 (86.707)1.12 x 1.69 = 750.9

Embedded PM= 2.4 (86.707)1.20 x 1.69 = 858.54
PM= person-month
KLOC= lines of code, in thousands
M.- reflects 15 predictor variables, called cost drivers
The schedule is determined using the Basic COCOMO schedule equations.
People Required = 260.11 / 20.68 = 12.5
1.4.3. Activity Based Costing

Pre-determined overhead rate (POHR)=Estimated Overhead cost(A) / Estimated cost driver
Activity
Estimated Estimated cost

Activity Overhead Cost Driver driver POHR=A/B
cost(A) Activity
Creating the Software

25000 10 2500
system systems (IDE, s)
Implementing the Steps for
2000 20 100
system implementation
Required time
Running the
1000 for running the 8 125
System
system
Inspecting the
10000 Inspection time 100 100
system
1.5. Task Dependency Table
Activity Immediate Predecessor Duration Week

A. SRS & DD NONE 3W
B. Interface design A 13 W
C. Database design A 13 W
D. Admin account management B, C 2W
E. User account management B, C 2W
F. Web Integration B 2W
G. Contact A 1W
H. Record Insertion C, D 4W
I. Testing B, C, D, E, F, G, H 1W
J. Final Documentation I 3W
1.6. CPM - Critical Path Method
Required
Index Activity Description Duration week
Predecessor

A SRS & DD NONE 3W

B Interface design A 13 W
C Database design A 13 W
D Admin account management A 2W
E User account management A 2W
F Web Integration A 2W
G Contact A 1W
H Record Insertion C, D 4W
I Testing F, G, H, E 1W
J Final Documentation I 3W
1. Draw the Network Diagram
Figure 1:Network Diagram
2. Identifying the Critical Paths
Activity Duration ES EF LS LF TS FS
A 3 0 3 0 3 0 0
B 13 3 16 0 13 3 3
C 13 3 16 -1 12 4 4
D 2 3 5 10 12 7 7
E 2 3 5 0 2 3 3
F 2 16 18 14 16 2 2
G 1 3 4 2 3 1 1

H 4 16 20 12 16 4 4
I 1 20 21 20 21 0 0
J 3 21 24 21 24 0 0
The critical path is:

A, I, J
1.7. Gantt Chart
Figure 2:Gantt Chart
1.8. Introduction of Team Members and Skill-Set
Roll No. Name Skillset
• Frontend Designing Logo

2019-GCUF- Amtul Masawar • designing
• Animations
• Server implementation
2019-GCUF-073063 Maida Ijaz Documentation
•
• Server implementation
18250819-036 Tayyaba Nazar Documentation
•
1.9. Task and Member Assignment Table

Task Duration (Days) Dependencies

T1 21 None
T2 91 T1(M3)
T3 91 T1(M2)
T4 14 T3(M1)
T5 14 T2(M4)
T6 10 T2(M4)
T7 10 T3(M2)
T8 5 T3(M4)
T9 14 T1,T2,T3,T4(M1, M2,M3,M4)
T10 7 T2(M1)
T11 28 T3,T4(M4)
Allocation of People to Activities:
Task Engineer
T1 Tayyaba Nazar
T2 Sundus Imtiaz
T3 Ghashia Rashid
T4 Sundus Imtiaz
T5 Tayyaba Nazar, Ghashia Rashid
T6 Tayyaba Nazar
T7 Sundus Imtiaz
T8 Tayyaba Nazar, Ghashia Rashid, Sundus Imtiaz
T9 Tayyaba Nazar, Ghashia Rashid, Sundus Imtiaz
T10 Tayyaba Nazar
T11 Ghashia Rashid
1.10. Tools and Technology with reasoning
Software Requirements:
• Microsoft Windows 7/8/10 or Linux.
• XAMPP (MySQL, Apache, PHP).
• Notepad++ or any other text editor.
• Chrome or any other browser. Hardware Requirements:
• Intel Processor 2.0 GHz or above.
• 2 GB RAM or more.
• 160 GB or more Hard Disk Drive or above.
There are different tools and technologies that are used to make a complete website. We will
use the following technologies to make our website.

PHP
PHP is a hypertext preprocessor which is a server scripting language, and a powerful tool for
making dynamic and interactive Web pages. The PHP script is executed on server side. We
are using PHP over other languages because of following benefits.
• Unbeatable Speed
• Simple and Easy to Learn
• Number of frameworks and libraries
• Performance
MYSQL
MySQL is a database system used on the web to store data in the database. MYSQL is
widely used with PHP, also both are free and open source. The combination of PHP and
MySQL gives lot of options to create just about any kind of website from small website to
big project. Also, there are some core languages that are most important for website
development. It is the building block of any website.
HTML 5.0
Most widely used language that is used to make the structure of the website.
CSS 3.0
It describes how the HTML elements are to be displayed on the screen.
JavaScript
The behavior of our website will be controlled by the JavaScript.
Bootstrap
It used to develop the responsive and mobile-first website.
JQuery
Its JavaScript libraries to make it much easier to use JavaScript on website
• The size of the development effort.
Android Studio IDE:

It is use to develop the mobile application of this website.
1.11. Vision Document
This project will provide a safe and trustworthy environment for online doctors as well as
hospitals searching with appointments. There is always a need of a system that will perform
online searching of doctors and apply for appointments. This system will reduce the manual
operations required to maintain all the records. It generates the various reports for analysis.
The main vision of this project is to manage the records of patients, doctors, and
appointments. Its objective to enable the patients to search and view doctors’ profiles and
also apply for appointment. This project is also become useful for doctors for viewing
patient’s details and write prescriptions to patients.

1.12. Risk List
1. Executive Support:
Wavering, inconsistent or weak executive commitment is often a project's biggest
risk.
2. Scope:
The quality of your estimates, dependencies, and scope management. If an estimate is
just a guess, that is a risk.
3. Stakeholders:
Stakeholders with a negative attitude towards a project may intentionally throw up
roadblocks every step of the way.
4. Resources & Team:

Resource issues such as turnover and learning curves are common project risks.
5. Design:
Low quality design is a risk. You might want to highlight the design of complex or
experimental components as separate risks.
6. Integration:
Whatever you're delivering needs to integrate with the processes, systems,
organizations, culture and knowledge of the environment. Integration risks are
common.
7. Requirements
Garbage in, garbage out. If requirements aren't feasible or are detached from business
realities, your project may fail.
1.13. Product Features/ Product Decomposition

• Available timing of the doctors will be viewable.
• Available doctors can be searched according to location using map.
• Register yourself as a user.
Chapter 2: Software Requirement Specifications (SRS)
2.1 Introduction
A software requirements specification (SRS) is a description of a software system to be
developed. The software requirements specification lays out functional and non-functional
requirements, and it may include a set of use-cases that describe user interactions that the
software must provide to the user for perfect interaction. Software requirements specification

is a rigorous assessment of requirements before the more specific system design stages, and
its goal is to reduce later redesign. It also provides a realistic basis for estimating product
costs, risks, and schedules.
2.2 Existing System

Existing systems does not contain any facility to search a doctor in local area as well as
online appointments. This system helps to patients to find doctors details and take
appointment online without visiting the doctors and hospitals. This system also helps doctors
such as keep information of patient and appointment reservation and confirmation as well as
it helps in given prescriptions to patients.
2.3 Project Scope

The project is general in its scope as it is not intended to a specific-organization. This project
is going to develop generic portal, which can be applied by any business’s organization.
Moreover, it provides facility to its users. Also, the portal is going to provide a huge amount
of factual data with analytics.
2.4. Summary of Requirements: (Initial Requirements)

The purposed system must fulfill following requirements as follow:
2.4.1. Manage Doctors

Doctor management is crucial for the success of a website. This system should provide
Search and sort to easily find doctors in certain categories or with specific attributes.
Managing and editing appointments to related doctors should be unique. Only admin can add
a doctor.
2.4.2. Manage Appointments

This system provides management and updating of Appointment status. Patient can view
appointment status and all information to related doctor. He can add his description in the
appointment. The system should include Creation and management of Appointment booking
statuses.
2.4.3. Manage Patients

A patient can search and easily find doctors in certain categories or with specific attributes.
He must be sign-up first, then he can login to take appointments. Patients can view their
appointment status in their profile.
2.4.4. User Registration

In order to make an appointment, users register with the site, providing all the information
needed for it. System should manage user accounts. User can create accounts and reset
password. Every customer who signs up can choose a personal login and password for future
access.
2.5 Identifying External Entities

The Identification of External Interfaces is done in two phases.

Over Specify Entities from Abstract:
External Entities based on the Abstract from this E-commerce system are:
• Admin
• User (Doctor, Patient)
• Search Doctor (Name, Location, Specialty)
• Customer
• Book Appointment
• Prescription
Perform Refinement:
Based on our Business Logic, external entities are:
• Admin
• Appointment Status (Accepted, Rejected)
• Clinics
• Doctor/Patient
• Blog
• User/Visitor’s Activity
2.6 "Shall" Statements

Para Initial Requirements
1.0 A patient “shall” see/search all the doctors according to need.
1.0 A user (Doctor/Patient) “shall” register himself to the system
1.0 A user (Doctor/Patient) “shall” login to the system.
2.0 A patient “shall” book appointment with login
A patient “shall” select the doctor, book appointment, and then view his all
2.0
appointments
3.0 A doctor “shall” Add prescription to the patient
4.0 The admin “shall” add/update the new doctors and categories
4.0 The admin “shall” update the appointment status(accept/reject/pending)
4.0 The admin “shall” delete the appointment, doctor and categories
5.0 The system “shall” provide Contact feature for customer support.
Chapter 3: Design Document (For Structured Approach)
3.1. Introduction:
Analysis & Design Model for structured approach must contain following artifacts:
1. Entity Relationship Diagram

2. Data Flow Diagram (Functional Model)
3. State Transition Diagram (Behavioral Model)
4. Architecture Design

5. Component Level Design
3.2. Entity Relationship Diagram
Figure 3: ERD - Online Doctor Finder
Cardinality o From the description of the problem we see that: o

Each doctor can work in none or one hospital. o Each hospital can
have one or many doctors. o Each doctor can have one or many
appointments. o Each appointment can be reserved with one and
only one doctor. o Each appointment can be reserved by at least
one patient.
o Each patient can reserve one or many appointments. o Each patient
can have one or many diseases. o Each disease may affect one or many
patients. o Each patient is admitted in only one hospital.
o Each hospital admits one or many patients.
Identify Attributes
User: [user-id, name, address, login-id, pw]
Doctor: [doc-id, name, specialization]
Appointment: [app-id, pat-id, doc-id, date, time, status]

Patient: [pat-id, name, address]
Disease: [dis-id, name, symptoms, cure]
Hospital: [hos-id, name, type, address, no. of wards, location]
3.3. Data Flow Diagram (Functional Model)

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
Information System. A data flow diagram can also be used for the visualization of Data
Processing. It is common practice for a designer to draw a context-level DFD first which
shows the interaction between the system and outside entities. This context-level DFD is then
"exploded" to show more detail of the system being modeled.
Context Level DFD:
Figure 4: Context Level DFD
Level 1 DFD:

Figure 5: Level-1 DFD
Level 2 DFD:
Figure 6: Level-2 DFD
3.4. State Transition Diagram

State Transition Diagram is developed to represent the behavior of the system under
consideration. The constructs of STD are as follows:
State Transition Diagram for Doctor Finder

Figure 7: State Transition Diagram
3.5. Architectural Design

The Focus of architecture design is the Mapping of Requirements into Software Architecture.
DFD prepared in analysis model is analyzed to do it.
Two major structural patterns or two major alternatives are Transform (Flow) Analysis and
Transaction (Flow) Analysis.

Beginning the Design Process
• Review the fundamental system model i.e. DFD and Software Requirement
Specification document.
• Review and refine data flow diagrams for the software
• Determine whether DFD exhibits transform or transaction characteristics
Figure 8: Architecture Diagram
3.6. Component Level Design

Every component, which is appearing in program structure/design architecture, is logically
analyzed and pseudocode or flow chart is prepared for each module. This flow chart is then
given to programmer who translates it into a machine-readable code. The options available
for component level design are:
• Flow chart
• Box Diagram
• Decision Table
• Pseudocode

Figure 9: Component Diagram
Chapter 4: User Interface Design

4.1. Introduction
A user interface design consists of three main parts:

Page elements should be visualized on paper before building them in the computer. Just as
you draw a site map to plan the site, use cartoons and storyboards to begin blocking out the
site’s appearance and navigational scheme.
1. Site maps
2. Storyboards
3. Navigational maps
4. Traceability Matrix
4.2. Site Maps

A site map's main benefit is to give users an overview of the site's areas in a single glance by
dedicating an entire page to a visualization of the information architecture.
4.2.1 Homepage View

Figure 10: Homepage View
4.2.2 Admin Login Side
Figure 11: Admin Login Side

4.3. Story Boards

A storyboard is a sequence of single images, each of which represents a distinct event or
narrative.
4.3.1 Home Page
4.3.2 Search Doctor

4.3.3 Contact:
4.3.4 Blog:

4.3.5 Admin Login:
4.3.6 Doctor Login:
4.3.7 Patient Login:

Chapter 5: Software Testing

5.1 Introduction
Software testing is a process of running with intent of finding errors in software. Software
testing assures the quality of software and represents final review of other phases of software
like specification, design, code generation etc. Testing is the process of executing the
program with the intention of finding out errors. During testing, the program to be tested is
executed with a set of test cases and the output of the programs for the test case is evaluated
to determine if the program is performing as it is expected to be. The success of testing in
revealing errors in program depends critically on the test cases. In software system the use of
testing is not limited to the testing phase. The results of testing are used later on during
maintenance also. Following are standard artifacts, which must be included in this
deliverable:
1. Test Plan
2. Test Design Specification
3. Test Case Specification
4. Test Procedure Specification
5. Test Item Transmittal Report
6. Test Log
7. Test Incident Report
8. Test Summary Report
5.2. Test Plan

Test plan is the first step in testing. Test plan of the system includes following contents:
5.2.1. Purpose
The purpose of this test plan is including performance testing to ensure that the website loads
properly and quickly, there are no broken links and that the website is accessible and to
ensure that the website loads properly across web browsers such as Safari, Google Chrome,

Mozilla Firefox, Opera Browser, Internet Explorer 7,8, 9, 10 and 11. This test plan will
ensure that all features of website are working properly.
5.2.2. Outline
A test plan shall have the following structure:
a. Test plan identifier

b. Introduction
c. Test items
d. Features to be tested
e. Features not to be tested
f. Approach
g. Item pass/fail criteria
h. Suspension criteria and resumption requirements
i. Test deliverables
j. Testing tasks
k. Environmental needs
l. Responsibilities
m. Staffing and training needs
n. Schedule
o. Risks and contingencies
p. Approvals
5.2.2.1. Test plan identifier

Test plan document identifier of Doctor Finder Web Portal TP_ID_1.0
5.2.2.2. Introduction
The goal of this document is to develop a test plan for the status of all test items. All the test
items are in working state and functioning properly. The actual result is same as expected in
test plan. The required system is achieved and there are not any pending items. This
document defines all the procedures and activities required for testing of the functionalities of
this website which are specified in Vision document. The main objectives of this test plan are
to define the activities to perform testing, define the test deliverables documents and to
identify the various risks and contingencies involved in testing. E-commerce supports the
following objectives:
• To define the tools which will be used in the testing process

• To communicate with the responsible parties, the items to be tested
• To define which items or features are to be tested • To define which items or features
are not to be tested
• To define environmental needs.
• To define how the tests will be performed

5.2.2.3. Test items
The items which are to be tested in this include the front-end user/admin facing website along
with the back-end admin platform. These sites should be tested in Google Chrome 74.0,
Mozilla Fire Fox 45.0 and Internet Explorer 10 & 11. The systems should be tested on
Windows machine.
5.2.2.4. Features to be tested

The following list describes the features to be tested:
User:
• Login successfully
• Registered Successfully
• Search Doctors
• Apply search filters
• Change Password
• View appointment
• Take appointment
• View prescription
• View profile
• Update profile
Doctor:
• Login Successfully
• View reserved appointments
• Add prescription
• View profile
• Update profile
Admin:
• View & change appointment status
• View, add & delete doctors
• View & add patient
• View & add clinic
• Update Blog
5.2.2.5. Features not to be tested

• User Query in Admin panel: it will not be tested because admin will respond to user’s
query manually so this feature doesn’t need to be tested
• Network Security: Testing network security is out of our scope
5.2.2.6. Approach
Test will be conducted as per documented test cases. Each member will test each feature and
mark each case as Pass/Fail. Each test person will observe the actual results and all relevant

details. As, when all the tests will be completed then the test manager will analyze the test
report.
5.2.2.7. Item pass/fail criteria

The system should satisfy all the functional requirements, described in the vision document.
Each feature to be tested will be evaluated against its requirement as stated in the vision
document. The pass or fail of a test depends on whether the system meets with all the
particular post conditions. 95% of all test cases should pass and user must be able to
complete a purchase cycle successfully and initiate a refund without any errors.
5.2.2.8. Suspension criteria and resumption requirements Suspension

criteria and resumption requirements are as follow:
5.2.2.8.1. Suspension Criteria

If the system contains one or more critical defects like the defects in the GUI, database
locking, unlocking and sharing features which provide the environment for multiple users to
work in parallel, login issues or failure in any basic CRUD (Create, Read, Update and Delete)
actions, the entire system should be suspended. The testing may also be suspended if the
hardware and software components required are not available on time.
5.2.2.8.2. Resumption Requirements:

After a suspension of testing has occurred, a new version of the system is transmitted to the
test group. All previous tests will be rerun to ensure that program changes have not
inadvertently effect on other parts of the program.
5.2.2.9. Test deliverables

Identify the deliverable documents. The following documents should be included: a.
Test plan.
b. Test design specifications.
c. Test case specifications.
d. Test procedure specifications.
e. Test item transmittal reports.
f. Test logs.
g. Test incident reports.
h. Test summary reports.
Test input data and test output data should be identified as deliverables. Test
tools (e.g., module drivers and stubs) may also be included.
5.2.2.10. Testing tasks

The following activities are included in testing tasks: a.
Prepare test plan
b. Write down functional specifications
c. Functional specifications delivered to the testing team

d. Ready the environment for testing
e. Make environment ready for testing (test data, test logins, test payment information, etc.).
f. Perform the tests.
g. Prepare test summary report
5.2.2.11. Environmental needs

Environment should be ready for testing. Test mode should be enabled for the backend doctor
finder platform. The site which must be tested must have the test data including logins,
appointment information and doctors fee. According to hardware specifications it is suitable
for all the current systems. Any web browsers will be provided.
5.2.2.12. Responsibilities
Each member is responsible for designing, preparing, executing and documentation of the
system properly. The test manager is responsible for testing, managing and resolving the
issues of the whole system.
5.2.2.13 Staffing and training needs

Testing team needs to be selected carefully. Two or three members of a team can conduct
testing of his doctor finder system. Each tester should conduct the testing of all features of
the system which are required for the completion of testing. Each tester should be trained and
have basic knowledge of doctor finder website. Each tester should be familiar with the
technology, the business and the customer requirements. The tester should have an
understanding of the different browsers, such as Microsoft Internet Explorer, Google
Chrome, Firefox Mozilla Netscape and Opera.
5.2.2.14. Schedule
Testing will have to be done in 3 weeks.
Sr# Testing Phase Duration

1 Unit Testing 1 week
2 Integration Testing 5 days
3 System Testing 6 days
4 Acceptance Testing 3 days
5.2.2.15. Risks and Contingencies

If the first component testing is not completed within a day, it could delay bug fixes and final
testing. If the tester does not have the basic understanding of software development, testing
could be delayed or not be conducted properly.
5.2.2.16 Approvals
The team member who manages the testing process and the team leader who manages the
whole product must approve this plan.
Name: Mr. Najeeb Ur Rehman
Title: Project Supervisor
Signature:
Date: 23-08-2020

5.3. Test design specification

Test design specification ensures all Functional and Design Requirements are implemented as
specified in the documentation. Test Plan is also made to provide a procedure for testing, to
identify the documentation process for testing and to identify the test methods for testing.
5.3.1. Purpose
To prescribe the scope, approach, resources, and schedule of the testing activities. To identify
the items being tested, the features to be tested, the testing tasks to be performed, the
personnel responsible for each task, and the risks associated with this plan.
5.3.2. Outline
A test plan shall have the following structure:
a. Test plan identifier

b. Introduction
c. Test items
d. Features to be tested
e. Features not to be tested
f. Approach
g. Item pass/fail criteria
h. Suspension criteria and resumption requirements
i. Test deliverables
j. Testing tasks
k. Environmental needs
l. Responsibilities
m. Staffing and training needs
n. Schedule
o. Risks and contingencies
p. Approvals.
The sections shall be ordered in the specified sequence. Additional sections may be included
immediately prior to Approvals. If some or all of the content of a section is in another
document, then a reference to that material may be listed in place of the corresponding
content.
The referenced material must be attached to the test plan or available to users of the plan.
Details on the content of each section are contained in the following sub-clauses.
5.3.2.1 Test Plan Identifier

Test plan identifier is Doctor Finder Web Portal TD_ID_1.0.
5.3.2.2. Introduction
The test plan is for testing the whole system including modules and their features. The testing
of modules of the application will be conducted manually within 3-4 days.

5.3.2.3. Test items
The items which are to be tested in this include the front-end user/admin facing website along
with the back-end admin platform. These sites should be tested in Google Chrome 74.0,
Mozilla Fire Fox 45.0 and Internet Explorer 10 & 11. The systems should be tested on
Windows machine.
5.3.2.4. Features to be tested

The following list describes the features to be tested:
User:
• Login successfully
• Search Doctors
• Apply search filters
• Change Password
• View appointment
• Take appointment
• View profile
• Update profile Doctor:
• Login Successfully
• View reserved appointments
• Add prescription
• View profile
• Update profile
Admin:
• View & change appointment status
• View & add doctors
• View & add patient
• View & add clinic
• Update Blogs
5.3.2.5. Features not to be tested • User Query in Admin panel: it will not be tested because
admin will respond to user’s query manually, so this feature doesn’t need to be tested
• Network Security: Testing network security is out of our scope
5.3.2.6. Approach
Test will be conducted as per documented test cases. Each member will test each feature and
mark each case as Pass/Fail. Each test person will observe the actual results and all relevant
details. As, when all the tests will be completed then the test manager will analyze the test
report.

5.3.2.7. Item pass/fail criteria
The system should satisfy all the functional requirements, described in the vision document.
Each feature to be tested will be evaluated against its requirement as stated in the vision
document. The pass or fail of a test depends on whether the system meets with all the
particular post conditions. 95% of all test cases should pass and user must be able to
complete a purchase cycle successfully and initiate a refund without any errors.
5.3.2.8. Suspension criteria and resumption requirements

Testing should be paused immediately if system experience any issue at start up or failure in
basic e.g. any problem in searching the relevant doctor.
5.3.2.9. Test deliverables

When the test results are completed, the results will be saved and the test manager then
should circulate the complete test report to the whole team.
5.3.2.10. Testing tasks

The following activities must be completed:
• Test plan should be prepared
• Functional specifications written and delivered to the testing team
• Perform the tests
• Prepare test summary report
5.3.2.11. Environmental needs

Environment should be ready for testing. Test mode should be enabled for the backend doctor
finder platform. The site which must be tested must have the test data including logins,
appointment information and doctors fee. According to hardware specifications it is suitable
for all the current systems. Any web browsers will be provided.
5.3.2.12. Responsibilities
Each member is responsible for designing, preparing, executing and documentation of the
system properly. The test manager is responsible for testing, managing and resolving the
issues of the whole system.
5.3.2.13. Staffing and training needs

All team members should do testing and all members should have knowledge of particular
field.
5.3.2.14. Schedule
The testing will take 3-4 days. Some components and their features will be testing in a day.
Sr# Testing Phase Duration

1 Unit Testing 1 week
2 Integration Testing 5 days
3 System Testing 6 days
4 Acceptance Testing 3 days

5.3.2.15. Risks and Contingencies

If the first component testing is not completed within a day, it could delay bug fixes and final
testing. If the tester does not have the basic understanding of it, testing could be delayed or
not be conducted properly.
5.3.2.16. Approvals
Signature:
Date: 23-08-2020
5.4. Test Case Specification
5.4.1. Purpose
Test design specification ensures all Functional and Design Requirements are implemented as
specified in the documentation. Test Plan is also made to provide a procedure for testing, to
identify the documentation process for testing and to identify the test methods for testing.
5.4.2. Outline
A test case specification shall have the following structure:
a. Test case specification identifier
b. Test items
c. Input specifications
d. Output specifications
e. Environmental needs
f. Special procedural requirements
g. Inter case dependencies
5.4.2.1. Test case specification identifier
Test plan identifier is Doctor Finder Web Portal TC_ID_1.0.
5.4.2.2 Test Cases
5.4.2.2.1 Test Case for Doctor panel:
Test Case for Doctor panel

Test Engineer Ghashia Rashid
Test Case ID TC-001
Test Item Doctor Panel
Input Specification Log in, check appointment & add prescription
Output Specification Logged in, checked appointment & added prescription
successfully

Test Environment Need Software: Any Browser Hardware: Phone/Laptop/Tablet etc.

Special procedural None
requirement
Inter-case dependencies None
5.4.2.2.2 Test Case for Patient panel:
Test Case for Patient panel

Test Engineer Sundus Imtiaz
Test Case ID TC-002
Test Item Patient Panel
Input Specification Log in and reserve appointment after searching
Output Specification Logged in and reserved appointment successfully
requirement
5.4.2.2.3 Test Case for Admin panel:

Test Case for Patient panel
Test Engineer Tayyaba Nazar
Test Case ID TC-003
Test Item Admin Panel
Input Specification Log in, add doctors, clinics, patients and perform relevant
operations
Output Specification Logged in and performed all operations successfully
requirement
5.5. Test procedure specification
5.5.1. Purpose
The purpose of Test Procedure Specification is to specify the steps for executing a set of test
cases or, more generally, the steps used to analyze a software item in order to evaluate a set
of features.
5.5.2 Outline
A test procedure specification shall have the following structure:
a. Test procedure specification identifier
b. Purpose
c. Special requirements

d. Procedure steps
5.5.2.1. Test procedure specification identifier
Test plan document identifier of Doctor Finder Web Portal TPro_ID_1.0

Test procedure specification for Doctor panel
Test Engineer Ghashia Rashid
Purpose To allow doctors to register on this online portal and be
accessible to patients
Special requirement Laptop & Internet Availability
Procedure Step • Open Browser
• Open website
• Register
• Log in
• check appointment
• add prescription
Test Identification TC-001
Status Passed
Test procedure specification for Patient panel

Test Engineer Sundus Imtiaz
Purpose To allow patient to register on this online portal and access
various suitable doctors
• Open website
• Register
• Log in
• Search Doctor
• Reserve appointment
• see prescription
Status Passed
Test procedure specification for Admin panel

Test Engineer Tayyaba Nazar
Purpose To allow admin to manage the availability of doctors to
patients and approve or decline the appointment requests
• Open website
• Log in

• Manage Doctor
• Manage patient
• Manage appointment
• see feedback
Status Passed
5.6. Test item Transmittal Report
5.6.1. Purpose
To identify the test items being transmitted for testing. It includes the person responsible for
each item, its physical location, and its status. Any variations from the current item
requirements and designs are noted in this report.
5.6.2. Outline
A test item transmittal report shall have the following structure:
a. Transmittal report identifier

b. Transmitted items
c. Location
d. Status
e. Approvals
5.6.2.1. Transmittal report identifier

The identifier for Transmittal report is TT-001
5.6.2.2. Transmitted items The whole system of ‘Doctor Finder Web Portal’ is transmitted
to the targeted person for use. All team members are responsible for its transmittal and they
ensure this.
5.6.2.3. Location
Identify the location of the transmitted items. Identify the media that contain the items being
transmitted. When appropriate, indicate how specific media are labeled or identified.
5.6.2.4. Status
The status of all test items being transmitted is passed. All the test items are in working state
and functioning properly. The actual result is same as expected in test plan. The required
system is achieved and there are not any pending items.
5.6.2.5. Approvals

Signature:
Date: 23-08-2020
5.7. Test log
5.7.1. Purpose
To provide a chronological record of relevant details about the execution of tests.
5.7.2. Outline
A test log shall have the following structure:
a. Test log identifier;
b. Description;
c. Activity and event entries.
5.7.2.1. Test log identifier Identifier

for test log is TL-001.
5.7.2.2. Description
All the items are tested for the ‘Doctor Finder Web Portal’. The testing of this web portal is
conducted manually. While testing the website, a peculiar event was occurred but later on it
has been fixed and now it started working properly.
5.7.2.3. Activity and event entries

Activity Authorization Date and Time
Doctor Panel Ghashia Rashid 22-08-2020
Patient Panel Sundus Imtiaz 22-08-2020
Admin Panel Tayyaba Nazar 22-08-2020
5.7.2.3.1 Execution description
Every member (Ghashia Rashid, Sundus Imtiaz & Tayyaba Nazar) of the team tested each
function. The testing was done exactly in 3-4 days and then tested the website by them.
Ghashia Rashid tested the Doctor Panel TP-001 of website on 22-08- 2020. Sundus Imtiaz
tested the Patient Panel TP-002 of website on 22-08-2020 And Tayyaba Nazar tested the
Admin Panel TP-003 of the website.
5.7.2.3.2 Procedure results
Test Case Test Case ID Results Status

Doctor Panel was
Doctor Panel TC-001 Pass
working smoothly
Patient Panel was
Patient Panel TC-002 Pass
working smoothly
Admin Panel TC-003 Admin Panel was Pass

working smoothly
5.7.2.3.3 Environmental information

There is no any specific environment condition is required for this entry.
5.8. Test incident reports
5.8.1. Purpose
The purpose of the Test Incident Report is to document any event that occurs during the
testing process that requires investigation.
5.8.2. Outline
A test incident report shall have the following structure:
a. Test incident report identifier

b. Summary
c. Incident description
d. Impact
5.8.2.1. Test incident report identifier Test

incident report identifier is TIR-001.
5.8.2.2. Summary
When testing the admin panel, the updating feature of clinics was problematic
Test Item: Admin Panel
ID: TC-003
Test Procedure Specification: User have Laptop & Internet connectivity.
5.8.2.3. Incident description

Provide a description of the incident. This description should include the following items: a.
Inputs
b. Expected results
c. Actual results
d. Anomalies
e. Date and time;
f. Procedure step;
g. Environment;
h. Attempts to repeat;
i. Testers;
j. Observers.
Incident description
Inputs Open admin panel
Expected results Smooth updating of clinics
Actual Results Updating problem

Anomalies Whole record becomes same

Date & Time 22-08-2020
Procedure Step • Log in
• Open clinics
• Add clinic
Environment Hardware: Laptop/phone & Internet Connectivity
Attempts To Repeat 3 to 5 times
Testers 3
Observers 3
5.9. Test Summary Report
5.9.1. Purpose
To summarize the results of the designated testing activities and to provide evaluations based
on these results.
5.9.2. Outline
A test summary report shall have the following structure:
a. Test summary report identifier
b. Summary
c. Variances
d. Comprehensive assessment
e. Summary of results
f. Evaluation
g. Summary of activities
h. Approvals
5.9.2.1. Test summary report identifier Test

summary report identifier is TSR-001.
5.9.2.2. Summary
All components were tested, there were some bugs as expected but later they were fixed.
Now, each component is working properly.
5.9.2.3. Variances
Some of the errors come out from testing of web portal from underlying environment. We
have issues regarding the updates in clinics table.
5.9.2.4. Comprehensiveness assessment

The testing process is done exactly like described in the test plan. All the features described
in the test plan are tested.
5.9.2.5. Summary of results

Testing is made of all the modules and their feature. Some of the bugs found in result from
the underlying environment.

5.9.2.6. Evaluation
Testing process was simple and sufficient for this phase.
5.9.2.7. Summary of activities

Unit testing was completed on following dates:
• Test for Doctor Panel 22-08-2020

• Test for Classification 22-08-2020
• Test for Patient Panel 22-08-2020
• Test for Admin Panel 22-08-2020
• System test was completed on 23-08-2020
• Acceptance test 23-08-2020
5.9.2.8. Approvals
Signature:
Date: 23-08-2020

FYP Documentation Online Doctor Finder V 1.7 Online Doctor Finder - Docx ADP

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

FYP Documentation Online Doctor Finder V 1.7 Online Doctor Finder - Docx ADP

Uploaded by

Copyright:

Available Formats

Department of Computer Science

Crime Management System

Project Management Office

© Department of Computer Science, Faculty of C& IT i

Date: 22 August 2020

© Department of Computer Science, Faculty of C& IT ii

© Department of Computer Science, Faculty of C& IT iii

2.3 PROJECT SCOPE................................................................................................................11

© Department of Computer Science, Faculty of C& IT iv

© Department of Computer Science, Faculty of C& IT v

Chapter 1: Project Feasibility

© Department of Computer Science, Faculty of C& IT 1

1.2. Project/Product Feasibility Report

1.2.1. Technical Feasibility

© Department of Computer Science, Faculty of C& IT 2

1.2.4. Schedule Feasibility

1.2.7. Motivational Feasibility

1.2.8. Legal & Ethical Feasibility

1.3. Project/Product Scope

1.4. Project/Product Costing

© Department of Computer Science, Faculty of C& IT 3

1.4.1. Project Cost Estimation By Function Point Analysis

Following are the Information domain values of our project:

Number of user inputs: 25 user inputs

Using average values of Complexity of components

To compute function points (FP), the following relationship is used:

FP est. = Count Total (UFP) * [ 0.65 + 0.01 * (Fi)]

1.Data communications = 3 8.On-Line update = 5

© Department of Computer Science, Faculty of C& IT 4

1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)

Type Effort Schedule

PM= person-month (effort)

Intermediate COCOMO: Cost

© Department of Computer Science, Faculty of C& IT 5

The schedule is determined using the Basic COCOMO schedule equations.

People Required = 260.11 / 20.68 = 12.5

1.4.3. Activity Based Costing

Estimated Estimated cost

Creating the Software

Activity Immediate Predecessor Duration Week

1.6. CPM - Critical Path Method

© Department of Computer Science, Faculty of C& IT 6

A SRS & DD NONE 3W

1. Draw the Network Diagram

Figure 1:Network Diagram

2. Identifying the Critical Paths

© Department of Computer Science, Faculty of C& IT 7

The critical path is:

1.7. Gantt Chart

Figure 2:Gantt Chart

1.8. Introduction of Team Members and Skill-Set

Roll No. Name Skillset

• Frontend Designing Logo

1.9. Task and Member Assignment Table

© Department of Computer Science, Faculty of C& IT 8

Allocation of People to Activities:

© Department of Computer Science, Faculty of C& IT 9

• The size of the development effort.

Android Studio IDE:

© Department of Computer Science, Faculty of C& IT 10

1.12. Risk List

4. Resources & Team:

1.13. Product Features/ Product Decomposition