Complet Documnetation for Smart Assistant Application for Disabled Person

SMART ASSISTANT APP FOR
DISABLED PEOPLE
Project Advisor:
DR. FURQAN TAHIR
HMFTJ.COM
Submitted by:
Name
AHMED
Roll#
42346237
____________________________________________________________________
University Name
Department of Computer Sciences

Statement of acceptance
This is to certify that these students have submitted their final year project, which the department
of computer science has accepted and evaluated. The final year project completion is one of the
mandatory requirements to be fulfilled by the students towards the conclusion of their degree of
BS in Computer Science (BSCS).
SMART APP
________________________ ________________________
Advsior Name Advisor Name
Project Advisor Projects' Convener
Department of Computer Science Department of Computer Science
_____________________________
Ilyas Butt
Dean Department of Computer Science.
University Name.

Proofreading Certificate
It is to certify that I have read the document meticulously and circumspectly. I am convinced that
the resultant project does not contain any spelling, punctuation or grammatical mistakes. As
much as expected from the graduating students at the bachelors’ level. All in all I find this
document well organized.
_____________________________________________
Advsior Name
Lecturer, University Name.

Acknowledgement
Most of all we thank Allah our creator and Sustainer. Above all we thank Allah our Creator and
Sustainer, for enabling and letting us to be what we are now. We truly acknowledge the
cooperation and help given by our supervisor Mr. Advsior Name, Lecturer of University
Name. He has been a constant source of guidance throughout the course of this project. We
would also like to thank Sir Advisor Name, Project Convener of University Name for their
help and guidance throughout this project. We are also thankful to our friends and families
whose silent support led us to complete our project.

Abstract
The 'Smart Assistant' app is a unique tool focused on aiding disabled people and linking them to
people who work as assistants who can offer a real-time follow-up on several issues. The aim of
app is to help blind individuals including deaf and blind people to get the every day help they
require. Not only does it give a power to individuals with disabilities by enabling them to be
more independent but also enables assistants to find employment with a sense of purpose. With
its easy-to-use features and real time connectivity the Smart Assistant aims to offer a platform
for the user to meet the assistants who can provide necessary help no matter where the user is
(Abel et al., 2013). Through exploiting the technology, the app will promulgate the independence
of disabled people and as well as create job opportunities for the assistants and consumers the
general public at the same time.

CHAPTER 1
INTRODUCTION
Project Background
In today's digital age, mobile applications play a crucial role in enhancing accessibility and
convenience for various user groups. However, individuals with disabilities often face unique
challenges in utilizing technology to its full potential. The Smart Assistant Mobile Application
for Disabled Persons aims to bridge this gap by providing a comprehensive solution tailored to
their specific needs.
Project Purpose
The purpose of this documentation is to provide a detailed overview of the Smart Assistant
Mobile Application project, outlining its objectives, functional requirements, design
considerations, development approach, and deployment strategy.
Project Scope
The scope of the project encompasses the development of an Android mobile application
equipped with features designed to assist individuals with disabilities in various aspects of their
daily lives, including navigation, communication, task management, and emergency assistance.

1.1 Introduction
The "Smart Assistant" app provides a solution for individuals with physical disabilities, utilizing
technology and real-time connectivity to create a linking platform between trained helpers and
disabled individuals. It offers voice-based support for visually impaired and text-based
communication for hearing impaired.
1.2 Project Background
People with disabilities, particularly those who are blind or deaf-blind, face challenges in daily
tasks and data access, leading to dependence and lack of independence
Our Goals
The primary goal of the Smart Assistant Mobile Application project is to develop a userfriendly
and inclusive mobile application that empowers individuals with disabilities to overcome barriers
and lead more independent lives. The key goals include:
• Provide assistance in navigation, communication, and task management.
• Enhance accessibility and inclusivity for individuals with disabilities.
• Improve quality of life by enabling greater independence and autonomy.
Our Objectives
To achieve the project goals, the following objectives have been identified:
•
• Implement voice recognition functionality for handsfree interaction.
• Integrate navigation tools with realtime assistance and accessibility features.
• Facilitate communication through text and voice messages, with support for assistive
technologies.
• Incorporate features for task organization and reminders to aid in daily planning and
management.

• Enable onetouch emergency assistance with GPS location sharing and predefined
contacts for quick response.
Deliverables
The deliverables for the Smart Assistant Mobile Application project include:
• A fully functional Android mobile application developed according to the specified
requirements and design guidelines.
• Comprehensive documentation covering all aspects of the development process,
including functional specifications, design considerations, and testing procedures.
• Testing reports and quality assurance documentation to ensure the reliability,
performance, and accessibility of the application.
The solution is to develop an Android application that offers an intelligent assistants with
various functionalities, including, message transformation, alarm, Bing translator, Search support
for equipment and other related problems.
1.3 Non – Functional Requirements
In addition to the obvious features and functions that we will provide in your system, there are
other requirements that do not actually DO anything, but are important characteristics
nevertheless. These are called "non-functional requirements" or sometimes "Quality
Attributes." For example, attributes such as performance, security, usability, compatibility are
not a "feature" of the system, but are a required characteristic.
1.3.1 Portability:
Our system is very efficient and portable. You must have internet connection and you can run it
on your android phones anywhere. In our case the project mobile app as well as the admin side
can be run on any device. Android device is for the mobile app and web platform for the admin
side.
1.3.2 Reliability:
We have tested our application and remove all the bugs and errors which we face during the
testing. Now our application is error free and accurate. Our application is also very responsive
and user friendly.
1.3.3 Security:
• Our system needs to control the user access and session.

• Our system needs to store the data in a secure location, stored in a secure
format.
• Our system requires a secure communication channel for the data.
1.3.4 Concurrency and Capacity:
• Our system going to be able to handle multiple computations executing
simultaneously, and potentially interacting with each other.
• There is no minimum average and maximum number of concurrent users.
• Our system can save data of hundreds of users for long time.
• After a specific time period of 40 years the data will be removed from data
base for the betterment of database.
1.3.5 Performance:
• Our application is error free and accurate. Our application is also very
responsive and user friendly.
1.3.6 Maintainability:
• Our system is meant to be up and running for long time. So it will regularly
need preventive and corrective maintenance.
• Maintenance might signify scalability to grow and improve the system
features and functionalities.
1.3.7 Usability:
End user satisfaction and acceptance is one of the key pillars of our application. Taking the user
experience requirements into account from the project conception we have developed this
application.
1.3.8 Documentation:
Last but not least, we have completed a minimum of documentation at different levels. In many
cases the users might even need training on it, so keeping our documentation practices and
standards will do this task spread along the project development.
1.3.9 Legal:
We have followed all the legal issues involving privacy of information, intellectual property
rights, export of restricted technologies, etc.
1.3.10 Operating constraints:
we have listed run-time constraints. This could include system resources, people, and needed
software.
1.3.11 Platform constraints:
we have discussed the target platform. Be as specific or general as the user requires. If the user
doesn't care, there are still platform constraints.
1.3.12 Accuracy and Precision:
Requirements about the accuracy and precision of the data. (Do you know the difference?)
Beware of 100% requirements; they often cost too much.
1.3.13 Modifiability:
Our system can easily be modified and adopt all changes easily.

1.4 Software Development Life Cycle
The Agile software development life cycle is the structured series of stages that a product goes
through as it moves from beginning to end. It contains six phases: concept, inception, iteration,
release, maintenance, and retirement.
The Agile life cycle will vary slightly depending on the project management
methodology chosen by a team. For example, Scrum teams work in short time periods known
as sprints, which are similar to iterations. They also have clearly defined roles, such as Scrum
master. On the other hand, Kanban teams have more of a continuous flow with no required roles.
Another example is Extreme Programming, where teams tend to work in shorter iterations and
place an extra focus on engineering practices.
However, the goal of all software development teams is the same: to deliver working software to
users on time.
The six phases of the agile life cycle
As mentioned, the agile software development life cycle consists of six phases. Let’s examine
each of these agile phases in more detail.
1. Concept
First up is the concept phase. Here, a product owner will determine the scope of their project. If
there are numerous projects, they will prioritize the most important ones. The product owner will
discuss key requirements with a client and prepare documentation to outline them, including
what features will be supported and the proposed end results. It is advisable to keep the
requirements to a minimum as they can be added to in later stages. In the concept stage, the
product owner will also estimate the time and cost of potential projects. This detailed analysis
will help them to decide whether or not a project is feasible before commencing work.
2. Inception
Once the concept is outlined, it is time to build the software development team. A product owner
will check their colleagues’ availability and pick the best people for the project while also
providing them with the necessary tools and resources. They can then start the design process.
The team will create a mock-up of the user interface and build the project architecture. The
inception stage involves further input from stakeholders to fully flesh out the requirements on a
diagram and determine the product functionality. Regular check-ins will help to ensure that all
requirements are built into the design process.
3. Iteration
Next up is the iteration phase, also referred to as construction. It tends to be the longest phase as
the bulk of the work is carried out here. The developers will work with UX designers to combine
all product requirements and customer feedback, turning the design into code. The goal is to
build the bare functionality of the product by the end of the first iteration or sprint. Additional
features and tweaks can be added in later iterations. This stage is a cornerstone of agile software
development, enabling developers to create working software quickly and make improvements to
satisfy the client.

4. Release
The product is almost ready for release. But first, the quality assurance team needs to perform
some tests to ensure the software is fully functional. These Agile team members will test the
system to ensure the code is clean — if potential bugs or defects are detected, the developers will
address them swiftly. User training will also take place during this phase, which will require
more documentation. When all of this is complete, the product’s final iteration can then be
released into production.
5. Maintenance
The software will now be fully deployed and made available to customers. This action moves it
into the maintenance phase. During this phase, the software development team will provide
ongoing support to keep the system running smoothly and resolve any new bugs. They will also
be on hand to offer additional training to users and ensure they know how to use the product.
Over time, new iterations can take place to refresh the existing product with upgrades and
additional features.
6. Retirement
There are two reasons why a product will enter the retirement phase: either it is being replaced
with new software, or the system itself has become obsolete or incompatible with the
organization over time. The software development team will first notify users that the software is
being retired. If there is a replacement, the users will be migrated to the new system. Finally, the
developers will carry out any remaining end-of-life activities and remove support for the existing
software.

Figure 1.1: Agile Development Life Cycle
1.4.1 Why We Used Agile
During the project, end-user involvement is encouraged, providing visibility and transparency.
There is continuous planning and feedback throughout the process, delivering value to the
business from the beginning of the project. We embrace this idea of delivering project value
early in the process making it easier to lower risks associated with development. Some of the
main benefits of agile project management are:
• High Product Quality
• Regular testing to see that the product is working during the development
• Defining and elaborating requirements just in time
• Incorporating continuous integration and daily testing into the development process
• Sprint retrospectives to continuously improve processes and work
• Software is developed in incremental, rapid cycles.
• Higher Customer Satisfaction
• Demonstrating working functionalities to customers

• Delivering products to market quicker and more often with every release
• Keeping customers involved and engaged
• Increased Project control
• Daily Sprint meetings
• Transparency though information radiators
• Reduced Risks
• Developing in sprints, ensuring a brief time between feature development
• Agile gives freedom when recent changes need to be implemented
• Adaptation to the client's needs and preferences through the development process
• Faster ROI
• Focusing on Business value allowing the client to determine the priority of features
• A functional 'ready to market' product after few iterations
• Agile means fast product releases and ability to gauge customer reaction
1.5 System Architecture Diagram
A system architecture is the conceptual model that defines the structure, behavior, and more
views of a system. A system architecture consist of system components and the sub-systems
developed, that will work together to implement the overall system. There have been efforts to
formalize languages to describe system architecture, collectively these are called architecture
description languages.

Figure 1.2: System Architecture
1.6 Functional Requirements
1.6.1 Project Scope:
• First we will make the prototype of our application.
• Then we will design database.
• Then we will make graphics and will design the layout of our app.
• Afterword’s we will build the mobile application using water fall methodologies.
• Final result will be a publish file which will run on server side (live hosting)

• And will be used as android APK file which will be on android devices have
android version 5.0 and later.
1.6.2 Product Scope:
Sell:
Scope:
The scope of this process is vast comparing to manually selling purchase systems
Some of the key features are:
• This process can be used in corporate world
• There are no restrictions to customer when selling mobile
Feature Scope:
• Being web-based application can be used from any where
• It is reliable and provides accurate results
• Easier to get buyers
• Get cash immediately
• Time-saving process
The other major advantages of selling phones online are:
• You can compare phone prices online; it will help you to know the current value of your
phone
• It is more convenient as no need to visit various physical phone retailers
• Selling phones online is secure and hassle-free
• Reading reviews help you to get the reputation of website. You can read reviews on given
site and by visiting their social media pages
• Getting instant cash is far easy at online phone buying shops as compared to other local
or individual buyer.

Repair: Collect the obsolete and undesired products from the users and companies, and returned
goods from e-commerce portals. (Products may or may not contain any defects)
• Sort them
• Repair them
• Repack them
• Make sure that these products work properly
• Sell them on Reverse Marketplaces or to the companies directly
Recycle:
Various metals like copper, lead, gold, etc. are used for making a mobile device. Recycling is
when these components are extracted from the phone and are used again for manufacturing new
devices.
Mobile recycling in our project:
• Customer can recycle his / her phone by filling the form that available at our website.
• Customer simple enter model, its storage type IEMI and the Recent pictures.
• After verification of model customer enter date, time his/her choice.
• Our technical person goes and gets the phone. And verify all things.
• After getting phone they send confirmation.
• Our inspection team check phone and remove usable parts and at the end of all procedure
• The generate reports according to point and send report to admin.
• After all process admin send coupon to the customer according to their points.
• We take field from government for plant growing.
• We growing plant in this field and send location of this field to the customer, and also
send row number and plant number.
• Other than our inspection team check the phone, if phone repair in the cost 30 to 50
• percent of the actual phone price, then we repair it and sale as refurbished otherwise
• We consider as recycled product.
Why should someone recycle his devices?
It is ideal to recycle devices that are no longer in use. Idle devices are usually dumped in
landfills or kept unused, resulting in more e-waste and increased carbon footprint.
1.7.3 List of Product Deliverables:
• Web Application.
• Source code.
• UI/UX design, prototype & mockups.
• Documentation.
1.8 Platform & Technologies
• Photoshop
• We will use devexpress reports for reporting.
• Application of our project will be a web based application. (Mostly mobiles will be able
to run the application easily.
1.9 Intended Users
The application/portal is mainly intended for children 15+ years that also are referred to as users
Users Intended users for the application

Project Advisor Responsible for project evaluation
Team Members Responsible for system development
Table 1.1: Intended Users.
1.10 Look and feel
Main focus in the designing is the human interaction with the system. As user can stay more time
in the application. The designing of the project is also focus on the user design satisfaction as the
user should never feel bothered during the usage of the application. All the material related to the
users are easy to access, user can navigate easily from one screen to another. Each screen is
designed by keeping in mind the user interaction.
First part of the project is all about planning and scheduling of project. This part contains
following artifacts:
• Project Feasibility
• Project Scope
• Project Costing
• Critical Path Method Analysis (CPM Analysis)
• Gantt Chart
• Introduction to team members
• Tools and Technologies
• Vision Document
• Risk List

Market Analysis
Overview of the Market
The market for assistive technologies aimed at individuals with disabilities is rapidly expanding,
driven by advancements in technology and increasing awareness of accessibility issues.
However, there remains a significant gap in the availability of comprehensive solutions that
address the diverse needs of this user group.
Target Audience
The target audience for the Smart Assistant Mobile Application includes individuals with various
disabilities, including but not limited to:
Mobility impairments (e.g., wheelchair users, individuals with limited dexterity)
Visual impairments (e.g., blind or low vision individuals)
Hearing impairments (e.g., deaf or hard of hearing individuals)
Cognitive disabilities (e.g., individuals with intellectual or developmental disabilities)
Competitor Analysis
While there are existing mobile applications that offer some functionalities catering to the needs
of disabled individuals, such as navigation aids, communication tools, and task management
apps, there is a lack of comprehensive solutions that encompass all these aspects within a single
application. Some notable competitors in this space include:
XYZ Assist: Provides navigation assistance and communication tools for disabled individuals.
ABC Access: Offers accessibility features and task management functionalities.
DEF Helper: Focuses on emergency assistance and communication aids for individuals with
disabilities.

Chapter 02
REQUIREMENT ENGINEERING
2.1 Introduction
“Smart Assistance App” Functional Requirements
User Authentication
Description Implement a secure authentication mechanism to verify the identity of users before
granting access to the application.
Requirements
User registration with email or phone number.
Passwordbased authentication with options for biometric authentication (e.g., fingerprint or
facial recognition).

Password recovery functionality through email or SMS verification.
Voice Recognition
Description Enable voice recognition functionality to allow users to interact with the application
using voice commands.
Requirements
Integration with a speech recognition API for accurate voicetotext conversion.
Support for natural language processing to interpret user commands.
Customizable voice commands for various functionalities (e.g., navigation, messaging, task
management).
Navigation Assistance
Description Provide realtime navigation assistance to help users navigate their surroundings
safely and independently.
Requirements
Integration with mapping services (e.g., Google Maps) to provide accurate location data and
directions.
Wheelchairaccessible routes and points of interest marked on the map.
Turnbyturn navigation guidance with audible directions and haptic feedback.
Option to customize navigation preferences based on user preferences and accessibility needs.
Communication Tools
Description Facilitate communication between users through text and voice messages, with
support for assistive technologies.
Requirements
Messaging feature with support for both text and voice messages.
Integration with screen readers and texttospeech engines for accessibility.

Group messaging functionality to allow multiple users to communicate simultaneously.
Compatibility with external communication platforms (e.g., SMS, email) for seamless
communication with nonapp users.
Task Management
Description Enable users to organize and manage their tasks effectively, with reminders and
notifications to help them stay on track.
Requirements
Task creation, editing, and deletion functionalities.
Prioritization of tasks based on urgency and importance.
Reminder notifications for upcoming tasks or deadlines.
Integration with calendar applications to synchronize tasks and events.
Emergency Assistance
Description Provide users with quick access to emergency assistance in case of emergencies or
urgent situations.
Requirements
Onetouch emergency button on the application interface for immediate activation.
Automatic GPS location tracking to provide accurate location information to emergency
services.
Predefined emergency contacts that can be contacted automatically in case of emergency.
Integration with emergency response services (e.g., 911) for rapid assistance.
Accessibility Features
Description: Incorporate accessibility features to ensure that the application is usable by
individuals with various disabilities.
Requirements:

Customizable accessibility settings, including font size, color contrast, and screen reader support.
Alternative input methods for users with mobility impairments (e.g., gesture controls, switch
access).
High-contrast user interface with clear visual indicators and tactile feedback options.
Compatibility with external accessibility devices and assistive technologies (e.g., Braille
displays, switch controllers).
System Architecture
Overview
The system architecture of the Smart Assistant Mobile Application follows a client-server model,
with the mobile application serving as the client that interacts with backend services hosted on a
cloud platform. The architecture is designed to ensure scalability, reliability, and security.
Main Components
Mobile Application (Client): The user-facing interface of the application, running on Android
devices and providing access to the application's features and functionalities.
Server Application (Backend): Backend services responsible for processing user requests,
managing data storage, and implementing business logic. This includes authentication services,
navigation APIs, messaging servers, and task management systems.
Database Management System (DBMS): A centralized database system for storing user data,
application settings, and other relevant information. The DBMS ensures data integrity, security,
and scalability.
External APIs (Maps, Speech Recognition): Integration with external APIs, such as mapping
services (e.g., Google Maps) and speech recognition services (e.g., Google Speech-to-Text), to
provide additional functionalities and enhance the user experience.
Data Flow Diagram
[Insert Data Flow Diagram illustrating the flow of data and interactions between the application
components]

2.2 Existing System
An Existing system refers to the system that is being followed till now is manual. The current
system is time consuming and also it is not reliable, because it involves a lot of paperwork. To
manually handle the system was very difficult task, but now-a-days computerization made easy
to work.
The following are the reasons why the current system should be computerized:
• To increase efficiency with reduced cost.
• To reduce the burden of paper work.
• To generate required data easily
2.3 Scope of the System
2.3.1 Project Objective:
This application is improvement in control and performance. The system is developed to cope up
with the current issues and problems in seeking assistance in exam preparations.
After computerized system is implemented less human force will be required to maintain the
application thus reducing the overall cost & efforts. It will save time.
2.4 BENEFITS/MAIN FEATURES OF THE PROPOSED SYSTEM
2.4.1 Features of the Proposed System:
Identifying External Entity:
Our intended audience will includes:
• Amin who wants to provide their services.
Users who wants facilities and assistance from the application.
Accessibility Considerations
In designing the user interface and user experience of the application, careful consideration is
given to accessibility principles and guidelines to ensure that the application is usable by
individuals with various disabilities. This includes:
• Providing alternative text for images and icons to assist users with visual impairments.
• Using high-contrast color schemes and clear visual indicators to improve visibility for
users with low vision.
• Ensuring keyboard navigation support and compatibility with screen readers for users
with mobility impairments.
• Offering customizable font sizes, color contrast settings, and other accessibility options to
cater to individual user preferences.

2.5 Capture “shall” statement and identify external entities
User and System:
External entity Initial Requirements
User User “shall” launch application.
System System “shall” allow the user to
launch the app.
User User “shall” signup to the
application.
System Software shall allow a user to sign
up into the application.
User User “shall” login to the
application.
System System “shall” allow the user login
to the application.
User User “shall” build his profile.
build his profile.
User User “shall” search from the
application.
search in the application.
User User “shall” check the features.
check and see the features.
User User “shall” logout from the
application.
logout from the system.
Table 2.1: User and System shall statement
User:
launch the app.
User User “shall” signup to the

application.
System Software shall allow a user to sign
up into the application.
User User “shall” login to the
application.
System System “shall” allow the user
login to the application.
build his profile.
application.
logout from the system.
Table 2.2: User shall statement.
User:
System System “shall” allow the user to launch
the app.
User User “shall” signup to the application.
System Software shall allow a user to sign up
into the application.
User User “shall” login to the application.
System System “shall” allow the user login to
the application.
System System “shall” allow the user to build
his profile.
User User “shall” check his previous posted
project status.
System System “shall” allow the user to check

the previous project status.
User User “shall” edit his personal
information.
System System “shall” allow the user to edit
personal information.
application.
System System “shall” allow the user to logout
from the system.
Table 2.3: User shall statement
2.6.1 Allocate Requirements:
Users:
Initial Requirements Requirement
User “shall” launch application. Launch app.
User “shall” signup to the application. Signup into the app.
User “shall” login to the application. Login into the system
User “shall” build his profile. Profile management
User “shall” logout from the application. Logout
Table 2.4: User shall statement
2.6.2 Priorities Requirements:
Admin:
Initial Requirements Requirement Priorities
User “shall” signup to the
application.
User can signup Normal/Medium
User “shall” login to the
application.
User can sign-in Normal/Medium
User “shall” build his profile. User can set his/her profile High
User “shall” logout from the
application.
Logout or exit from the app Normal/Medium
Table 2.5: Admin shall statement

2.6.3 Requirement Traceability Matrix:
Admin:
application.
User can signup Business
application.
User can sign-in Business
User “shall” build his profile. User can set his/her profile Business
User “shall” edit company
information.
Manage profile Business
User “shall” check the
applicant’s profile.
See users Business
application.
Logout or exit from the app Business
Table 2.6: Admin shall statement
Users:
User “shall” launch application. Launch app Business
application.
Signup into the app Business
application.
Login into the system Business
User “shall” build his profile. Profile management Business
User “shall” edit his
information.
Manage profile Business
application.
Logout Business
Table 2.7: users shall statement

CHAPTER 03
USE CASES
3.1 Introduction (Use Cases)
In software and systems engineering, a use case is a list of actions or event steps typically
defining the interactions between a role (known in the Unified Modeling Language (UML) as an
actor) and a system to achieve a goal. The actor can be a human or other external system.
• Design class diagram.
• Sequence diagrams.
• Operation contracts.
• ERD model.

3.1.1 Use Case Descriptions
Launch Application:
Description:
User intends to launch the application in his android device, this use case specifies about what
steps the user has to take to launch the application. Because all the other use cases are enabled
when the user launches the app.
Figure 3.1: Launch Application Use Case
Primary Actor :
Users
Stakeholders and interests :
User: User is interested in launching application.
Pre-conditions :
• User must have a device to launch application.
• User must have an internet connection to download our application or to browse.
Post-condition(Success Guarantee) :
• User successfully downloads our application into his/her device.
• User successfully launches our application into his/her device.
Main Success Scenario(Basic Flow) :
• User goes to app store where our application is uploaded.
• User browses application relating the application from app store.
• User navigates to our application.
• User clicks on the download button.
• User accepts the license agreement for download.
• User downloads our application.
• User launches our application after download.
• User opens web browser enter web name will be opened.
Alternative Flow(Extensions) :
• User is unable to go to App store due to System UI of his/her device crashing.
1a. System asks the user to restart his/her device.
1b. System asks the user to clear the cache of his/her device.
• User can’t browse application.

2a. System asks the user to check the internet connection in his/her device.
2b. System asks the user to reload the site.
• User can’t navigate to application.
3a. User reloads the site and request again.
• The download button is not working.
4a. System asks the user to check the internet connection in his/her device.
• User clicks on the cancel button of license agreement for download.
5a. System asks the user to request again with accept button being clicked.
• If download does not starts.
6a. User retry and request again.
6b. System asks the user to check the internet connection of his/her device.
6c. System asks the user to release some space to download the application.
Frequency of Occurrence :
Could be nearly continuous.
Signup
Description:
User intends to sign up into the application, this use case specifies about what steps the user has
to take to sign up into the application.

Figure 3.2: Sign Up Use Case
Primary Actor :
Users
User: User is interested in sign up into the application.
Pre-conditions :
• User must have install the application.
• User must have an internet connection to connect the server.
• User successfully sign up into the application.
• User ready to sign in into the application.
• User goes to application/ opens.
• User navigates to sign up form.
• User fill the sign up form to sign up into the application.
• User clicks on the sign up button.
• User accepts the privacy policy of the application.
• User successfully sign up the application.
• User is unable to sign up.
1a. if any field contains incorrect data.
1b. any field is empty device.
Login
Description:
User intends to sign in into the application, this use case specifies about what steps the user has
to take to sign in into the application.

Figure 3.3: Sign In Use Case
Primary Actor :
Users.
User: User is interested in sign in into the application.
Pre-conditions :
• User must have signup in the application.
• User successfully sign in into the application.
• User ready to use the application.
• User goes to application.
• User navigates to sign in form.
• User fill the sign in form to sign in into the application.
• User clicks on the sign up button.
• User successfully sign in the application.
• User is unable to sign in.
1a. if any field contains incorrect data.
1b. any field is empty.
Build Profile
Description:
User intends to build his profile in the application, this use case specifies about what steps the
user has to take to build the profile into the application.

Figure 3.4: Build Profile Use Case
Primary Actor :
Users
User:
User is interested in building the profile into the application.
Pre-conditions :
• User must have sign-in in the application.
• User successfully build profile into the application.
• User ready to use the application from this step.
• User goes to application.
• User navigates to update profile form.
• User fill the required form field to build the profile into the application.
• User clicks on the build profile button.
• User successfully build profile in the application.
• User is unable to build profile.
1a. if any field contains incorrect data type.
1b. any required field is empty.
Register
Description:
User intends to build his profile in the application, this use case specifies about what steps the
user has to take to build the profile into the application.
Figure 3.5: Register Use Case

Primary Actor :
Users
User: User is interested in registering the profile into the application.
Pre-conditions :
• User must have sign-up in the application.
• User request is sent to admin for approval for the sake of authentication
• Admin allow user to register.
• User sign in in the application.
• User goes to application..
• User navigates to fill profile form.
• User fill the required form field to register the profile into the application.
• User clicks on the submit button.
• User successfully submitting profile in the application.
• Admin will approve the request and allow the user to access the application.
• User is unable to submit profile.
Sell phone
Description:
User intends to sell their cell phones using this application, this use case specifies about what
steps the user has to take to sale phone through the application.
Figure 3.6: Sale phone Use Case
Primary Actor :
Users

User: User is interested to sell phone using the application.
Pre-conditions :
• User goes to application
Donate dead phone
Description:
User intends to donate dead cell phones using this application, this use case specifies about what
steps the user has to take to donate dead cell phones through the application.
Figure 3.7: Donate Dead Cell Phones Use Case
Primary Actor :
Users
User: User is interested to donate dead cell phones using the application.

Pre-conditions :
• User goes to application
Logout
Description:
User intends to exit from the application, this use case specifies about what steps the user has to
take to log out from the application.
Figure 3.8: Logout Use Case
Primary Actor:
Users
User: User is interested in exiting the application.

Pre-conditions :
• User must have sign in in the application.
• User successfully logout from the app
1. User goes to application.
• User navigates to logout option.
• User click on the logout menu.
• User logout from the app successfully
Could be nearly continuous as every time when the user want to logout from the app.
3.2 Use Case Diagram
Use case diagrams consists of actors, use cases and their relationships. The diagram is used to
model the system/subsystem of an application.

CHAPTER 04
SYSTEM PROCEDURAL DIAGRAMS

4.1 System Sequence & Sequence Diagrams
Sequence Diagrams are interaction diagrams that detail how operations are carried out.
Figure
4.1: Login Sequence Diagram

Figure 4.2: Admin Sequence Diagram

Figure 4.3: Logout Sequence Diagram

4.2 Data Flow Diagram level 0
Figure 4.4: Data Flow Diagram

4.3 Class Diagram
Class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among objects.
Figure 4.5: Class Diagram

CHAPTER 05
TOOLS & TECHNOLOGIES
5.1 Tools and Technologies with Reasoning
Tools and technology section includes all the tools and technology that are used in development
process of the project, Following are the Tools and technologies we use in our project:
• Javascipt, XML
• We will use devexpress reports for reporting.
• Mobile app of our project will be an android base application. (Mostly mobiles will be able
to run the application easily.

5.2 Vision Document
You can compare phone prices online; it will help you to know the current value of your phone.
It is more convenient as no need to visit various physical phone retailers. Selling phones online is
secure and hassle-free. Reading reviews help you to get the reputation of website. You can read
reviews on given site and by visiting their social media pages. Getting instant cash is far easy at
online phone buying shops as compared to other local or individual buyer.
5.3 Positioning
5.3.1 Problem Statement:
The problem of Providing platform for the people
who want sell their cell phones
Affects Users
The impact of which Providing platform for the people
who want sell their cell phones
A successful solution would be SMART APP app
Table 5.1: Problem Statement
5.3.2 Product Position Statement:
For Users
Smart
Assistance App
A platform for the people who want sell their cell phones
That People who want sell their cell phones
Unlike No other software of application in Pakistan who provides
these facilities that we provide.
Table 5.2: Product Position Statement
5.3.3 References:
• Use case model.
• UCD.
• Domain Model.
5.3.4 Stakeholder/User Summary:
Name Description Responsibilities
Admin This stakeholder
works with all the
actors.
Its check all the work flow
of the application
This actor includes all the
users who want services
online.

Users Person who wants
assistance.
They can create their
profile on the application
by signing in to the app.
On the creation of profile
the applicant has to upload
his/her personal data in the
form of text, images, and
description.
Table 5.3: Stakeholder/User Summary
5.3.5 Responsibilities:
Name Description Responsibilities
Requirement
Engineer
This stakeholder
works with users.
Specifies domain, non-
functional, and functional
requirements. Refines
requirements as needed.
Project
Manager
This stakeholder
leads the
development of
Accessible
application.
Plans, manages and allocates
resources, decides priorities,
coordinates interactions with
customers and users, and keeps
the project team focused
Users Primary End User of
the system
Use the acceding to his/her
role as there are three type of
users
Table 5.4: Responsibilities
5.3.6 Risk List:
• If Scope is not explained well.
• The general risk of an error.
• Estimation is not correct.
• Inaccurate estimates lead to project risk directly.
• Dependencies are inaccurate.
• Dependencies dramatically impact the project schedule.
• Activities are missing from the scope.
• Required activities are missing from the scope definition.
• Stakeholders have alternate requirements.
• Lead to project disruption.
• Stakeholders became disengaged into our system/project.

• Leads to inaccuracy in project due to less attention.
• Misunderstanding of the requirements by the stakeholders.
• When requirements are misinterpreted by the project team there develops a
gap between the expectations and the requirements.
• User have inaccurate information necessary to complete the project.
• Does not have required information for development is a serious risk in
project.
• Poor staffing
• Lack of perfection in project occurs due to unavailability of experienced
staff.
• Low collaboration in team or project members
• Age gap exists between team members.
• Training is not so good
• Training is often a poor substitute for professional experience.
• Low team motivation
• Team lack motivation.
• Process inputs are of low quality
• Like requirements etc. are of low quality.
• Stakeholder’s conflict
• Disagreement between stakeholders over project issues and planning.
• Lack of Management experts
• Lack of experienced experts lead to issue in project’s development
Table 5.5: Risk List

CHAPTER 06
PRODUCT COSTING
6.1 Project/Product Costing
6.1.1 Project Cost Estimation by Function Point Analysis:
Type of
Components
Complexity of Components Weighting factors Count=
S *W
Simple Average Complex Simple Average Complex
No. of inputs 14 6 3 3 4 10 90
No. of
outputs
14 6 2 9 4 6 95
No. of
Inquiries
0 3 0 3 4 5 10
No. of Files 0 0 0 5 6 8 15
No.
of Interfaces
1 0 0 6 8 12 5
Count
Total
215

Frequency(Fi)
Data communications. 5
Distributed data
processing
1
Performance 5
Heavily used
configuration
3
Transaction rate 4
On-Line data entry 0
End-user efficiency 6
Backup 3
Complex processing 4
Reusability 3
Installation ease 1
Operational ease 1
Multiple sites 0
Facilitate change 5
Sum = 42
Table 6.1: Project Cost Estimation by Function Point Analysis
6.1.2 Frequency Table:
Table 6.2: Frequency Table
Total Function Point
FP = Count Total * (0.65+ (0.01*∑Fi))
FP = 191*(0.65+ (0.01*32)
FP EST = 185
Cost / FP
Labor Rate = 16000 Rs
Cost / FP = Labor Rate / Productivity
Cost/FP = 16000/32=500
Total Cost
T. Cost = (Cost / FP) * FP EST
T. Cost = 500 * 185
Result = 92,870 Rs.
Effort Calculation
E = FP EST / Productivity
E = 185/ 32
E = 5.78 PM
6.2 Project Cost Estimation by using COCOMO (Constructive Cost Model)

The effort size estimate is the total of module size in KDSI:
Project level: Intermediate
Project is intermediate.
Organization Level: Organic
Organization is organic.
Cost Drivers:
Product Attributes:
Attribute Name Scale Value
Reliability High 1.15
Database Very High 1.08
Complexity Normal 1
Hardware Attributes:
Attribute Scale Value
Time Normal 1
Storage Normal 1
Virtual Machine Low 0.87
Turn Around Time Normal 1
Personal Attributes:
Analyst Capability High 0.86
Software Engineer Capability Very High 0.82
Application Experience Normal 1
Virtual Machine Experience Low 1.21
Programming Language Experience Normal 1
Project Attributes:
Use of Tool High 0.91
Modern SE Methods Normal 1
Required Development Schedule Low 1
Calculating Source Lines of Code
SLOC
= FP * LF
Assume Language Factor for Application
Programming is 50
SLOC
= 195*50
SLOC
= 9750

Source Lines of Code = 9750
Delivered Source Instructions (DSI)
As
SLOC = DSI
So
DSI = 9750
1K = 1000.00
KDSI = 9750/1000
KDSI = 7.8
KDSI = 9.7
K Delivered Source Instructions = 9.7
Person Moths (PM or MM)
As project mode is organic we’ll use
intermediate COCOMO effort equation
PM or MM = a X (KDSI)b X EAF
Where
a = 3.2
b = 1.05
PM or MM
= 3.2*(9.7)^1.05*0.87
>7 Man Months
Person Months or Man Months >7
Duration (Time for development)
Tdev = c X (MM)d

Where
c = 2.2
d = 0.32
so duration is
2.2*(24)^0.32
6.072
Total Duration for development is 7 Months
Team Size (No of People)
MM / Tdev
19/7
2.7
Thus Team Size is 2 or 3 People
Two or Three Team Members are needed for this project
Development Cost
1 MM = 8h/day * 5 (working days) * 4
(weeks)
1 MM =
160 Hours
So
If we pay 200 RS per hour to each member
Development Cost Per Month = 160*2*100
64000
Project Cost =
32000
*10
Project Cost = 320,000.
Total Development Cost Using COCOMO Model is = 320,000 PKR

6.3 CPM –Critical path Method
Activity Immediate
predecessor
Duration
A-Planning None 10 days
B-proposal defend A 7 days
C-Estimation for
cost and time
B 5 days
D-scheduling phase C 6 days
E-Requirements
gathering by
surveying and
analysis
D 8 days
F-Requirements
analysis
C,D,E 7 days
G-Requirements
specification by
seniors and
supervisor
F 6 days
H-Modeling for
execution
G 16 days
I-Interface
Designing for app
and admin portal
H 30 days
J-Interface Coding H,I 35 days
K-Backend Coding
for functionalities
of system
J 155 days
L-Testing after
development
K 10 days
M-Deployment
process
K,L 7 days
N-Maintenance for
removal of bugs.
M 7 days
Table 6.3: Critical Path Method
The above diagram has following paths.
• S->A->B->C->D->E->F->Finish
10+7+5+6+8+7=43 DAYS
• S->A->B->C->F->G->H->I->Finish
10+7+5+7+6+16+30=81 DAYS
• S->A->B->C->D->F-> G->H->I->Finish
10+7+5+6+7+6+16+30= 87 DAYS
• S->A->B->C->D->E-> F-> G->H->I->Finish
10+7+5+6+8+7+6+16+30=99 DAYS
• S->F->G->H->I->Finish
7+6+16+30=59 DAYS

• S->J->K->L->Finish
35+155+10=200 DAYS
• S->M->N->Finish
7+7=14 DAYS
• S->J->K->M->N->Finish
35+155+7+7=204 DAYS
• S->I->J->K->L-> M->N->Finish
60+65+155+10+7+7=304 DAYS (<10 months)
Figure 6.1: Critical Path method
The duration of the 9th
path is longest and is 214 days so it is the critical path.
We can calculate the float on the other paths as well.
Float for the 1st
path is 186-41=145 days
Float for the 2nd
Float for the 3rd
Float for the 4th
Float for the 5th
Float for the 6th
Float for the 7th
Float for the 8th
path is 186-186= 0 days
6.4 Project Scheduling
We have schedule our project using different tools. Gantt chart is one of them. We have divided
our project in different part and give time durations to them. We created different milestones and
completed them one by one according to our schedule dates.
We have decided a start date and an end date and between them there are many milestones which
are completed accordingly. We have keep in mind all the holidays and working days and at the
end we have completed our project in time which we have decided. We have divided our project
in different parts or tasks and also have given start and end date to these tasks and completed
these tasks in time.
We keep in mind the following three question and have answers of all the following questions
before starting the project.
• What needs to be done?
• When will it be done?
• Who will do it?
Once we got answers to these questions, then we begin to plan dates, link activities, set the
duration, milestones and resources. The following are the steps needed to schedule a project.

6.5 Gantt chart
Figure 6.2: Gantt chart

CHAPTER 7
PROJECT/PRODUCT FEASIBILITY

7.1 Project/Product Feasibility
Our product satisfies all the needs of the user and completely fulfills its purpose. The product is
according to the emerging technologies and new techniques. The objective of the Smart
Assistance App is to establish the explanations for emerging the software that is satisfactory to
consumers, adaptable to modification and conformable to recognized morals. According to our
conducted survey it is proved that this kind of application/portal is needed to be developed. This
application is developed on practical grounds and it will benefit to the society and industry.
There are many types of feasibilities named as follows:
• Technical
• Operational
• Economic
• Schedule
• Specification
• Information
• Motivational
• Legal and Ethical
7.1.1 Technical Feasibility
As we have developed an android application, we have discussed the technical feasibilities. Our
application will run on simple android mobile phone having 2 GB Ram. Our application used an
online server, so it will need internet connection. Everybody have internet connection now a
days, so it will not be a big hurdle for the users. As our CMS (admin panel) will need a PC to
run which is easily available.
According to the technical feasibility, the compatibility between the front end and back end is
very important. The compatibility between the both is excellent in our system. Android
application has simple XML and in backend we used Java to code for our project. We use My
SQL as our database. These both worked excellent and we never had to face a problem regarding
compatibility of both software.
We used Android Studio, adobe tools for the development and design of our application.
Reason why we use Objective Language in our Project development?
As we are developing this application in Android Studio and it will run on android operating
system and for developing there is a famous language used which is:
• Java
Java at the application side had more built-in features and commands for develop the software so
we have used Java language for the back end development of our android application.
Reason why we use Adobe tools?
We have used adobe tools like adobe Photoshop for logo designing and for designing of other
pages and screens of the project.

7.1.2 Operational Feasibility:
Our application is built after doing a survey and it solves a major problem faced by many
patients & doctors. To make the system smooth and efficient we have used the latest
technologies.
7.1.3 Performance:
Our project is easy to use and implement, and should respond to the user’s request in a minimal
time. During our test run we did not face any bugs and system failures in any user panel.
7.1.4 Services & Support:
It was our main goal to train our users that how to use this app from initial level to end, to all
types of users. If a user has any difficulty in the software, he/she can contact our team to seek
any type of support from the team.
7.1.5 Economic Feasibility:
The project is economically feasible because we just have no need of any special hardware to
run. It just need an android device/tablet with internet available on it to run for users and a
simple laptop or computer system for the admin to manage the software with internet connection
and a web browser.
7.1.6 Schedule Feasibility:
The time scheduling of this project is a paramount. We use the latest tools like Android Studio
and adobe tools for time efficiency. We also create Gantt chart which helps us planning our
project timelines.
• Gantt chart
7.1.7 Specification Feasibility:
This project is different from other conventional health facilitation systems available in market.
In this system we have not only completed our android application/portal but we also developed
a CMS on web platform for the administrator which will help to manage the system.
7.1.8 Motivational Feasibility:
It is not just an interesting or working app/portal but also a source of earning for the owner which
is acting as a third party. Also there is a large scope for this type of applications and android
developers, as Pakistan is currently growing in technology field and there are no major android
developments yet from Pakistan.
7.1.9 Legal and Ethical Feasibility:
We are ensuring that there should be no infringements or liabilities arising from this project. We
have made sure that it must not have destructive effects on our ethical values and also our society
laws, personal data and medical information of all the stakeholders and users will be kept
confidential.
7.2 Project/Product Scope
7.2.1 Project Scope:
Project management deliverables:
There will be number of project management deliverables for our application:
• Requirement Documentation.
• Design.

• Source Code.
• Project testing reports (App will be tested repeatedly and bugs that were reported
and terminated will be reported).
• Project instruction manual.
7.2.2 Road map:
• Requirement document.
• Graphics.
• Coding for different functions of the app.
• App using instructions.
• Adding application menus.
7.2.3 Product scope
7.2.3.1 List of product deliverables
SPLASH SCREEN (Android):
Service:
Splash screen comes up with logo of “Application for Exam Preparation (Pak Quiz)” for few
seconds when the app will start.
Output:
Display splash screen.
Login/Sign up:
Service:
After the flash screen display there will be a login screen which will provide an interface for
login and sign up for user if he/she isn’t registered yet.
Output:
Because of this procedure we will about to authenticate user by getting their personal
information and keeping it hidden from other users.
Category list:
Service:
User can look at the category list for the available facilities at home page.
Output:
By using this feature user will be able to get facilitated by the features.
Main Page:
Service:
Main page comprises of different categories.
Output:
Through this page user can register themselves and see the other features of the system.
Notifications:
Service:
In this feature register users will be notified if there is any notification from any administrator.
Output:
If any user gets added in the list of users respectively. The system will generate a notification
which will be received by all the respective user.

Attractive GUI:
Service:
User friendly graphical user interface.
Output:
User can interact with the system through a very interactive user interface.

CHAPTER 08
PLATFORM
&
TECHNOLOGIES

8.1 Platform and technologies
• Java script, XML
• Android Studio.
• Mobile app of our project will be an android base application. (Mostly mobiles
will be able to run the application easily.
8.2 Hardware
A laptop with dual core processor and 1 GB of RAM will be able to run admin side to manage
the project on their PC.
Android device with updated hardware and software are able to run this application.
Laptop/pc with any sort of old or latest technology will be able to run this portal online.
8.3 Design Rules
One of the goals of this project is to ensure a well-designed user interface that is easy to learn
and use. Although the current design is fairly simple, it is still necessary to correct any usability
issues to avoid user frustration. Therefore, the design of the user interface will be prototyped,
tested, and redesigned as necessary.
Time constraints do not allow for formal usability testing outside the team, which will require
that user interface evaluation be primarily carried out by team members. To strive for a more
accurate evaluation of the user interface, two team members will test each revision to the user
interface and give feedback to each other, then make changes as appropriate.
The “main menu” portion of the interface will be an extremely simple menu-style user interface
that will consist primarily of choosing a command button that matches the desired action.
Designing the user interface in this way will minimize learning time of users that have
experience with other apps/portals.
8.4 Specific User Interface Goals
• Intuitive (easy to learn).
• Consistent.
• Intuitive Icon Images (if no text labeling is included).
• Intuitive Labeling for UI Components.
• Simple (focus on helping the user).

CHAPTER 09
Testing and Quality Assurance
Test Cases
Functional Testing: Ensure that each feature and functionality of the application performs as
expected and meets the specified requirements. This includes testing user interactions, input
validation, error handling, and system responses.
Compatibility Testing: Verify that the application is compatible with various Android devices,
screen sizes, resolutions, and operating system versions, ensuring a consistent and reliable user
experience across different configurations.
Usability Testing: Gather feedback from disabled users through usability testing sessions,
interviews, surveys, and focus groups to identify usability issues, accessibility barriers, and areas
for improvement in the application's design and functionality.

Performance Testing: Evaluate the application's performance, responsiveness, and resource
usage under different conditions and usage scenarios, identifying any bottlenecks, latency issues,
or performance degradation that may impact the user experience.
User Acceptance Testing
Involve disabled individuals as well as representatives from disability organizations and
advocacy groups in the testing process to ensure that the application meets their needs,
preferences, and expectations. This may include conducting beta testing programs, pilot studies,
or field trials in real-world settings to gather feedback and validate the application's effectiveness
and usability.
Bug Tracking
Utilize bug tracking and issue management tools to log, track, and prioritize reported issues,
defects, and enhancement requests throughout the development lifecycle. This includes assigning
ownership, tracking status, and resolving issues in a timely manner to ensure the application's
reliability, stability, and overall quality
CHAPTER 10

Deployment and Maintenance
Release Plan
Plan regular updates and releases to introduce new features, enhancements, bug fixes, and
security patches, addressing user feedback, emerging requirements, and technological
advancements. This includes following a release management process to manage deployment
schedules, versioning, and release notes, as well as communicating updates and changes to users
through release announcements, notifications, and changelogs.
Support and Maintenance Plan
Provide ongoing technical support and maintenance services to address user inquiries,
troubleshoot issues, and resolve technical problems. This includes establishing communication
channels for user support, such as email, forums, and help documentation, as well as monitoring
system performance, uptime, and availability to proactively identify and mitigate potential issues
or disruptions. Additionally, regular maintenance activities, such as database backups, server
updates, and security audits, are conducted to ensure the application's reliability, security, and
compliance with regulatory requirements.
Feedback Mechanisms
Incorporate feedback mechanisms within the application to encourage user engagement, gather
feedback, and capture user insights, preferences, and suggestions for improvement. This includes
providing feedback forms, rating prompts, and suggestion boxes within the application interface,
as well as actively soliciting user feedback through surveys, polls, and user research activities.
Additionally, establishing community forums, user groups, and social media channels facilitates
ongoing communication, collaboration, and community building among users, developers, and
other stakeholders.

CHAPTER 11
Conclusion
Summary of Achievements
The Smart Assistant Mobile Application for Disabled Persons represents a significant
achievement in the field of assistive technology, providing a comprehensive and user-friendly
solution for individuals with disabilities to overcome barriers and lead more independent lives.
By incorporating advanced features, intuitive design, and accessibility considerations, the
application aims to empower users to navigate their surroundings, communicate with others,
manage their tasks, and access emergency assistance with ease and confidence.
Future Enhancements
While the current version of the application addresses many of the needs and requirements of
disabled individuals, there are opportunities for future enhancements and improvements to

further enhance the application's functionality, usability, and impact. Some potential areas for
future development include:
• Integration with wearable devices and IoT technologies for seamless connectivity and
enhanced accessibility.
• Expansion to other platforms, such as iOS and web applications, to reach a broader
audience of users and provide a more integrated user experience.
• Incorporation of artificial intelligence and machine learning algorithms for personalized
assistance, predictive analytics, and adaptive user interfaces.
• Collaboration with disability organizations, advocacy groups, and academic institutions
to conduct research, gather feedback, and co-design future iterations of the application
with input from disabled individuals and stakeholders.
• By continuing to innovate, iterate, and collaborate, the Smart Assistant Mobile
Application has the potential to evolve into a powerful tool for empowerment, inclusion,
and accessibility, making a meaningful difference in the lives of individuals with
disabilities and contributing to a more inclusive and equitable society.

Complet Documnetation for Smart Assistant Application for Disabled Person

Recommended

Recommended

More Related Content

Similar to Complet Documnetation for Smart Assistant Application for Disabled Person

Similar to Complet Documnetation for Smart Assistant Application for Disabled Person (20)

Recently uploaded

Recently uploaded (20)

Complet Documnetation for Smart Assistant Application for Disabled Person