Вы находитесь на странице: 1из 50

CHAT APPLICATION

Documentation
Team Shadow
April 11 2017

Instructor: Lamisha Rawshan

1
ACKNOWLEDGEMENT

If words are considered as a symbol of approval and token of appre-


ciation then let the words play the heralding role expressing my
gratitude. The satisfaction that accompanies that the successful
completion of any task would be incomplete without the mention
of people whose ceaseless cooperation made it possible, whose con-
stant guidance and encouragement crown all efforts with success.
We are grateful to teacher Ms. Lamisha Rawshan for the guid-
ance, inspiration and constructive suggestions that helpful us in
the preparation of this project.

2
ABSTRACT

Teleconferencing or Chatting, is a method of using technology to


bring people and ideas together despite of the geographical barri-
ers. The technology has been available for years but the acceptance
it was quit recent. Our project is an example of a chat server. It is
made up of 2 applications the client application, which runs on the
users Android Device and server application, which runs on any
Android Device on the network. To start chatting client should
get connected to server where they can do private and group chat
security measures were taken during the last one.

3
LETTER OF TRANSMITTAL

April 11 2017
Mam Lamisha Rawshan
Daffodil International University
Sukrabad, Dhaka

Dear Mam,

We would like to take the pleasure of presenting the final doc-


umentation of our project Chat Application.The purpose of the
Document is to inform you about the use, operation, maintenance,
or design of software or hardware through the use of manuals, list-
ings, diagrams, and other hard- or soft-copy written and graphic
materials. We have learnt a lot of new and unique things in the
path of completing this project. We tried our best to use the guide-
lines and counseling provided by you to make this documentation
as informative as possible. We express our heartiest gratitude, for
providing us with the opportunity to complete this documentation
on our Documentation of Software Engineering course.
We would be greatly obliged if you call us for any explanation or
any query about the report as and when deemed necessary.

Sincerely Yours,
Mourin Mondol
152-35-1298
Signature:
Date:
Ashiqur Rahman
152-35-1264
Signature:
Date:
Department of Software Engineering
Daffodil International University

Teacher’s Signature & Date

4
Contents
1 Introduction 3
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Project Scheduling
3
1.3 Business Requirement Documentation . . . . . . . . . . . . . . 5
1.3.1 AMENDMENT HISTORY
5
1.3.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.4 Business Process Affected . . . . . . . . . . . . . . . . 5
1.3.5 Appplications . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.6 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.7 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.8 Related Documents . . . . . . . . . . . . . . . . . . . . 6
1.3.9 Functional Requirements . . . . . . . . . . . . . . . . . 6
1.3.10 Non-Functional Requirements . . . . . . . . . . . . . . 6
1.4 Organization Of Document . . . . . . . . . . . . . . . . . . . . 7

2 Software Requirement Specification 7


2.0.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Project Scope & Features . . . . . . . . . . . . . . . . . . . . 7
2.2 PROJECT SUMMARY . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Project Background . . . . . . . . . . . . . . . . . . . . 8
2.3 Functional and Non Functional Requirements
8
2.3.1 Functional Requirements
8
2.3.2 Non Functional Requirements
9
2.4 Use Case Table . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Authentication System . . . . . . . . . . . . . . . . . . . . . . 11
2.6.1 Contacts Form . . . . . . . . . . . . . . . . . . . . . . 12
2.6.2 Chat Form . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.4 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i
2.7 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.1 Authentication System, Maintenance, Monitor . . . . . 16
2.7.2 Contacts Form, Chat Form . . . . . . . . . . . . . . . . 17
2.8 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . 18
2.9 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 19
2.10 METHODOLOGY . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10.1 Project Summary . . . . . . . . . . . . . . . . . . . . . 20
2.11 Project Deliverable’s . . . . . . . . . . . . . . . . . . . . . . . 20
2.12 Hardware Interface . . . . . . . . . . . . . . . . . . . . . . . . 20
2.13 Constraints and Limitations . . . . . . . . . . . . . . . . . . . 20
2.13.1 Constraints and Limitations . . . . . . . . . . . . . . . 20

3 Project Risk Management 21


3.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Analysis and evaluation . . . . . . . . . . . . . . . . . . . . . 22
3.3 Risk Registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Risk Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Implementation and Testing 24


4.1 Tools & Technology . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Test Plan Identifier . . . . . . . . . . . . . . . . . . . . 27
4.2.2 References . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.4 Test Items . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.5 Software Risk Issues . . . . . . . . . . . . . . . . . . . 29
4.2.6 Features To Be Tested . . . . . . . . . . . . . . . . . . 30
4.2.7 Features Not To Be Tested . . . . . . . . . . . . . . . . 31
4.2.8 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 User Manual 33
5.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Registration for new Member . . . . . . . . . . . . . . . . . . 33
5.3 Login Features . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Private Chatting . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Adding Friend . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6 Chat Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.7 Block Friend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ii
5.8 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.10 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.11 Frequently asked question . . . . . . . . . . . . . . . . . . . . 40
5.12 Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . 43

6 References 43

iii
List Of Tables

1. Amendment History——————–4

2. Stakeholders——————–4

3. Functional Requirements——————–5

4. Non Functional Requirements——————–5

5. Probability of Occurrence ——————–21

6. Seriousness of Impact——————–22

7. Risk Registrar——————–22

8. Risk Matrix——————–22

9. Function to be Tested——————-30

10. Functions not to be tested——————–39

1
List Of Figures

1. Work Breakdown Structure——————–3

2. Project Schedule——————–3
Use Case Diagrams:

3. Use Case Table——————–9

4. Authentication System Use Case Diagram——————–10

5. Contacts Forms——————–11

6. Chat Form——————–12

7. Maintenance——————–13

8. Monitor——————–14
Activity Diagram:

9. Authentication, Maintenance, Monitor——————–15

10. Contact Form, Chat Form——————–16

11. Entity Relationship Diagram——————–17

12. Data Flow Diagram——————–18


App Layout:

13. Registration——————–32

14. Login——————–33

15. Private Chatting——————–34

16. Add Friend——————–35

17. Chat Form——————–36

18. Block Friend ——————–37

19. Settings——————–38

2
1 Introduction
Communication is a mean for people to exchange messages. It has started
since the beginning of human creation. Distant communication began as
early as 1800 century with the introduction of television, telegraph and then
telephony. Interestingly enough, telephone communication stands out as the
fastest growing technology, from fixed line to mobile wireless, from voice call
to data transfer. The emergence of computer network and telecommunication
technologies bears the same objective that is to allow people to communicate.
All this while, much efforts has been drawn towards consolidating the device
into one and therefore indiscriminate the services. Chatting is a method of
using technology to bring people and ideas together despite of the geograph-
ical barriers. The technology has been available for years but the acceptance
it was quit recent. Our project is an example of a chat server. It is made
up of applications the client application which runs on the users mobile and
server application which runs on any pc on the network. To start chatting our
client should get connected to server where they can do Group and private
chatting.

1.1 Problem Statement


This project is to create a chat application with a server and users to enable
the users to chat with each others.
To develop an instant messaging solution to enable users to seamlessly com-
municate with each other.
The project should be very easy to use enabling even a novice person to use
it.

1.2 Project Scheduling

This document provides a scalable scheduling tool and associated schedule


development, analysis, and monitoring methods that can be used by Imple-
menting Agencies (IA) to prepare, monitor, and report project schedules.
Our Project is not that complex so we will not use very complex scheduling
method.

3
4
1.3 Business Requirement Documentation
1.3.1 AMENDMENT HISTORY

Version Prepared By Date Description


1.0 Mourin Mondol 11.04.2017 First Version

1.3.2 Overview
This Requirements Document will provide the requirements for a Chat Appli-
cation. Both functional and non requirements will be documented. functional
requirements will be documented.

1.3.3 Stakeholders
Stakeholder name Organization Role
Mourin Mondol Team Shadow President
Rajon Team Shadow Treasurer
Rajon Team Shadow Secretary

1.3.4 Business Process Affected


The following business process are in scope:

New Members

Review

Contacts

1.3.5 Appplications
Chat Applications are in scope.

1.3.6 Assumptions
n/a

1.3.7 Risks
n/a

5
1.3.8 Related Documents
n/a

1.3.9 Functional Requirements


Requirement ID Statement Must/Want
FR001 This app must have Privacy for user Must
FR002 This App Should have Friend List Must
FR003 Users shall be able to clear chat history Must
FR004 User shall be able to add friend Must
FR005 User shall be able to block or remove friend Must
FR006 User shall be able to Contacts with Maintenance team Want

1.3.10 Non-Functional Requirements


ID Statement Must/Want
NFR001 Chat App should be secure from hackers Must
NF002 All data must be backed up Must
NF003 Chat Application will be ready to launch within 60 days Want

6
1.4 Organization Of Document
Chapter 1: This Chapter include Initiation of this project where we will an-
alyze Problem, Project Schedule & Business Requirement Documentation

Chapter 2: This Chapter is all about SRS where we Design our Project.
Which include Use Case, Activity , ERD and DFD.

Chapter 3: Here, we analyze Possible Risk during the development phase


of our project.

Chapter 4: In this Chapter we discuss about Tools & Techniques we will


follow through development phase. And Our Test Plan. Here we gonna dp
Master test plan.

Chapter 5: This Chapter is a Manual or step by step guide for user about
all the features and installation of our project.

2 Software Requirement Specification


2.0.1 Purpose
However , the purpose of this project is to develop a java chat application.
The objective of this process is as follows;

1. To develop an instant messaging solution to enable users to seamlessly


communicate with each other.

2. The project should be very easy to use enabling even a novice person
to use it.

2.1 Project Scope & Features


1. Broadcasting Chat Server Application is going to be a text communi-
cation software, it will be able to communicate between two computers
using point to point communication.

7
2. The limitation of Live Chat is it does not support audio conversations.
To overcome this limitation we are concurrently working on developing
better technologies.

3. Companies would like to have a communication software wherein they


can communicate instantly within their organization.

4. The fact that the software uses an internal network setup within the
organization makes it very secure from outside attacks.

2.2 PROJECT SUMMARY


2.2.1 Project Background
The previous work of this already exists. The similar application can be
found on the project either Android market. This project will focus on pro-
viding high quality usability experiences to users mainly following Googles
user interface guideline. Experiments The application will be tested on a test
group to improve the usability quality based on the user’s feedback.

2.3 Functional and Non Functional Requirements

2.3.1 Functional Requirements

1. User Registration
User must be able to register for the application through a valid phone
number. On installing the application, user must be prompted to reg-
ister their phone number. If user skips this step, application should
close. The users phone number will be the unique identifier of his/her
account on Chat Application.

2. Adding New Contacts


The application should detect all contacts from the users phone book.
If any of the contacts have user accounts with Chat Application, those
contacts must automatically be added to the users contact list on Chat

8
Application. If any of the contacts have not yet registered on Chat
Application, user should be provided with an invite option that sends
those contacts a regular text message asking them to join Chat Appli-
cation along with a link to the Chat Application on Google Playstore.
3. Send Message
User should be able to send instant message to any contact on his/her
Chat Application contact list. User should be notified when message
is successfully delivered to the recipient by displaying a tick sign next
to the message sent.

4. Broadcast Message
User should be able to create groups of contacts. User should be able
to broadcast messages to these groups.

5. Message Status
User must be able to get information on whether the message sent has
been read by the intended recipient. If recipient reads the message, 2
ticks must appear next to the message read.

2.3.2 Non Functional Requirements

1. Privacy
Messages shared between users should be encrypted to maintain pri-
vacy.

2. Robustness
In case users device crashes, a backup of their chat history must be
stored on remote database servers to enable recoverability.

3. Performance
Application must be lightweight and must send messages instantly.

9
2.4 Use Case Table

Figure 1: Use Case Table of Chat Application

10
2.5 Use Case Diagram
2.6 Authentication System

Figure 2: Use Case Diagram of Authentication System

11
2.6.1 Contacts Form

Figure 3: Use Case Diagram of Contacts Form

12
2.6.2 Chat Form

Figure 4: Use Case Diagram of Chat Form

13
2.6.3 Maintenance

Figure 5: Use Case Diagram of Maintenance

14
2.6.4 Monitor

Figure 6: Use Case Diagram of Monitor

15
2.7 Activity Diagram
2.7.1 Authentication System, Maintenance, Monitor

Figure 7: Activity Diagram of Authentication System, Maintenance, Monitor

16
2.7.2 Contacts Form, Chat Form

Figure 8: Activity Diagram of Contacts Form, Chat Form

17
2.8 Entity Relationship Diagram

Figure 9: Entity Relationship Diagram of Chat Application

18
2.9 Data Flow Diagram

Figure 10: Data Flow Diagram of Chat Application

19
2.10 METHODOLOGY
2.10.1 Project Summary
The user interacts with the tool using GUI. The GUI Operates in two forms,
Contacts Forms and Chat forms. The contacts forms contains list of all friend
and the Chat form will be used to chat with friends.

2.11 Project Deliverable’s


1. An android app

2. Documentation

3. Readme File

2.12 Hardware Interface


• Android Phone

• 128 MB minimum RAM Required

• Internet or LAN Connections

• Processor with Speed of 500 MHz

2.13 Constraints and Limitations


2.13.1 Constraints and Limitations
The system must be connected with internet. User only can use or install
this app on android devices. This app doesnt have video and audio calling
system . We may add it in later version.

20
3 Project Risk Management
3.1 Identification
Risk identification involves determining which risks or threats are likely to
affect the project. It involves the identification of risks or threats that may
lead to project outputs being delayed or reduced, outlays being advanced
or increased and/or output quality (fitness for purpose) being reduced or
compromised. For most large/complex projects, a number of high level risks
should have been identified during the project initiation stage these should
be used as the basis for a more thorough analysis of the risks facing the
project. One of the most difficult things is ensuring that all major risks are
identified. A useful way of identifying relevant risks is defining causal cate-
gories under which risks might be identified. For example, corporate risks,
business risks, project risks and infrastructure risks. These can be broken
down even further into categories such as environmental, economic, politi-
cal, human, etc. Another way is to categorise in terms of risks external to
the project and those that are internal. See the Project Management Risk
Identification Tool for some useful prompts in identifying project risks. The
Australian Standard for Risk Management AS/NZS 4360: 2004 Appendix
D refers to generic sources of risk. The wording or articulation of each risk
should follow a simple two-step approach: 1. Consider what might be a trig-
ger event or threat (eg. poor quality materials causes costs to rise) several
triggers may reveal the same inherent risk; then 2. Identify the risk - use
a newspaper headline style statement short, sharp and snappy (eg. budget
blow out) then describe the nature of the risk and the impact on the project
if the risk is not mitigated or managed (eg. project delayed or abandoned,
expenditure to date wasted, outcomes not realised, government embarrassed
etc). Use the Risk Register (see Appendix A) to document the results. For
large or complex projects it can be beneficial to use an outside facilitator to
conduct a number of meetings or brainstorming sessions involving (as a min-
imum) the Project Manager, Project Team members, Steering Committee
members and external key stakeholders. Preparation may include an envi-
ronmental scan, seeking views of key stakeholders etc. For a small project,
the Project Manager may develop the Risk Register perhaps with input from
the Project Sponsor/Senior Manager and colleagues, or a small group of key
stakeholders. It is very easy to identify a range of risks that are outside the
project and are actually risks to the business area during output delivery,

21
transition or once operational mode has been established. These are not
project risks and should not be included in the Project Risk Register, but
referred to the relevant Business Owner. It may be appropriate to submit
an Issues Paper to the Steering Committee recommending formal acceptance
by the relevant Business Owner for ongoing monitoring and management of
specific risks. See the Project Management Fact Sheet: Developing a Risk
Management Plan and the Risk Identification Tool for more information on
how to undertake risk identification.
In this section specify:

1. Risk identification process that we followed are Brainstorm, facilitated


session, scan by Project Manager etc.

3.2 Analysis and evaluation


After identifying risks we should analyze them by determining how they
might affect the success of your project. Risks should be analyzed and eval-
uated in terms of Probability of occurrence and seriousness of impact if they
do occur. Firstly, assess the likelihood of the risk occurring and give this a
rating of scale from 1-5. The likelihood of harm occurring might be catego-
rized as:

Probability of occurrence
Certain 5 The risk is almost certain to occur (greater than 80% chance)
Likely 4 The risk is more likely to occur than not (between 51% and 80% chance)
Possible 3 The risk is fairly likely to occur ( between 21% and 50% chance)
Unlikely 2 The risk is unlikely but not impossible to occur (between 6% and 20% chance)
Rare 1 The risk is unlikely to occur (less than 5% chance)

22
Seriousness of impact

Catastrophic 5
Major 4
Moderate 3
Minor 2
Negligible 1

3.3 Risk Registrar


Risk ID Risk Description Impact Probability Risk Score
1. Inadequate funding to complete the project 4 5 20
2. Team not staffed in time 4 5 20
3. Steering Committee unavailable 5 4 20
4. Team not experienced 3 5 15
5. Available resources 2 2 4
6. Too many conflicting requirements 4 2 8
7. Competition with others 4 2 8

3.4 Risk Matrix


Probability/Impact Negligible(1) Minor(2) Moderate(3) Major(4) Catastrophic(5)
Certain (5) 4 1,2
Likely (4) 3
Possible (3)
Unlikely (2) 5 6,7
Rare (1))

23
4 Implementation and Testing
4.1 Tools & Technology
Our technical team master a comprehensive set of tools and technologies
during project development. A topic-oriented structure is provided below.

Product planning and innovation:

Quality planning:
Software-QFD

Product innovation:
Brainstorming, Mind-Map, TRIZ/ARIZ, Innovation algorithms

Software analysis, architecture and design:


Brainstorming
Mind-Map
Design patterns
UML tools and techniques
Rational Rose, Together, NetBeans, ArgoUML, MS Visio, Star UMLRequire-
ments matrix, VOCT, IDEF

Database modeling tools:


Embarcadero ER Studio, MySQL Workbench, DbVisualizer, Oracle SQLDe-
veloper, Toad

Project management:
Project planning and management:
MS Project, ScrumDesk

Effort estimation:
Top-down, PERT

Risk identification, evaluation and minimization:


Software-FMEA

24
Reporting and monitoring:
ISO 9001:2008, ArtSoft eQuality

Software development methodologies:


Agile, Scrum, Kamban, Scrum-ban, RUP, DSDM, etc.

Implementation:
Programming languages:
Java, PHP

Technologies, libraries and frameworks:


Java: JEE/J2EE, Java 2D, JSP, Apache Wicket, JMS, Swing, Spring, Struts,
Hibernate, JPA, JSF, EJB, Java Security, Velocity, JMF, PAM, i18n, Apache
Commons, GWT, JXL, JAccess, SiteMesh, Oracle Portal
PHP: CodeIgniter, CakePHP, Zend, Yii, Kohana, WordPress, Joomla, Dru-
pal, MODX, Magento, Prestashop, IPBoard, Smarty
Mobile: PhoneGap, iPhone SDK, Android SDK, JQuery Mobile, Flash Lite,
J2ME, Symbian, XMPP, SMS, WAP
Web technologies: JSON,XHTML, HTML5, XML, XSL, XSL-FO, XSLT,
CSS, XPath, XQuery, SAX, DOM, StAX, Xerces, Flash, Flex, Oauth, Om-
niauth, TinyMCE, Plupload, Retina.js, Flexpaper Adaptive UI, JW Player,
Highcharts, Modemizr, BjQS
Content Management Systems:
Stellent
Messaging Middleware:
ActiveMQ, IBM MQ Series, Fiorano, MQSonic, TIBCO rendezvous

IDE:
Intelij IDE,Android Studio.

Version Controling:
SVN, CVS, Rational ClearCase, Git/GitHub, Rational Synergy, MS Visual
Source Safe

Build tools:
Ant, Maven

Continuous integration tools:

25
Bamboo

Networking protocols and data security:


TCP/IP, HTTP/HTTPS, SMS, SMPP, MMS, MD5, POP3, SMTP, FTP,
TFTP, etc.

Databases:
Oracle, MS SQL Server, MySQL, Derby, PostgreSQL, Lucene/SOLR, LDAP
(Oracle Internet Directory, OpenLDAP, MS Active Directory), H2, Find-
Link, MongoDB, Exaled CloudView, etc.

Application and web servers:


Apache Tomcat, JBoss AS, Jetty, IBM WebShere, Oracle Application Server,
WebLogic, Windows Server IIS, Nginx, NetWeaver

Web and graphic design:


Adobe Photoshop,Illustrator, Flash, DreamWeaver

Testing:
Installation testing, Functional testing, Load testing, Performance profiling,
Data integrity testing, Sanity testing, Regression testing, Automated testing,
etc.

Testing tools and frameworks:


Ranorex, Selenium, JMeter, JBehave, Testing Anywhere, WebUI Test Stu-
dio, TestComplete, EasyMock, Mockito, jMock, Microsoft Web Application
Stress Tool, WebUI test Tool, TCMS, Deep-freez, ProjectLocker, QADB,
Mercury Quality Center, Share-net

Unit testing:
JUnit, DBUnit, utPLSQL, NUnit, PHPUnit

Issue management:
JIRA, Rational ClearQuest, Rally, Trac, ActiveCollab, Bugzilla, Bugzero,
Remedy, Rational Change, TestLink, TestTrack, etc.

26
4.2 Test Plan
4.2.1 Test Plan Identifier
ChatApplication-MTP1.0

4.2.2 References
List Of Document That Support this document:

1. IEEE 829 Test Plan FORMAT

4.2.3 Introduction
Chat Application will be the interpreter to bring people and ideas together.
We have been designing our Chat Application with well- equipped technology.
This project is now at development phase, so readers can read the Software
Requirement Specification document for details. This document presents the
Master Test Plan of IIT Website. As we know, master test plan is a living
and breathing document that summarizes the overall effort required to test
a software product. Master test plan will actually contain the details of
individual tests to be run during the testing cycle like unit test, system test,
beta test etc. However, our document will categorize and describe each test
case. It will also outline pass-fail criteria and indicate the planned run day or
week. This is a quick-reference tracking document for what has to be tested,
the priority of test items, what is left to test etc. We followed IEEE-829
format to develop our test plan. We strictly follow the instructions provided
by our respective course teacher. This is our first test plan documentation,
so we also read some sample test plan to gather knowledge about test plan
documentation. The estimated time line for this project is a semester. The
testing activities are to be done in parallel with the development process.

27
4.2.4 Test Items
Higher Level Test Items::

Items to be tested:

1. Chat Application Released version 1.0 and supporting infrastructure

2. Application runnig on different client’s device

Items Not To be Tested:

1. SRS of Chat Application

2. User Manual of Chat Application

3. Already Exist Chat Application

4. Manual process related to the application

5. Any Legacy System

Lower Level Test Items:

Items to be tested:

1. User Profile

2. Chatting

3. Group Chatting

4. Add Friend

5. Remove Friend

6. Block Friend

7. Unblock Friend

8. Find Friend

9. Registrar

28
10. Log In

11. Log Out

Items not to be tested:

1. User

2. Admin

Some more modules were included and changed during development phase,
which are not fully recognized or documented yet. So, test items of those
modules will be included in the next version of the test plan.

4.2.5 Software Risk Issues


There is several risk issues recognized which can have direct impact on the
Chat Application and need to be handled carefully.

1. Database security and safety

2. Backup of files

3. Reliability of Hosting Service

4. Lack of test tools

5. Lack of training

6. Lack of User Involvement

7. Lack of Schedule

8. Lack of Budget

9. Rapid Change in Taste

29
4.2.6 Features To Be Tested
The feature and attributes to be focused on during testing of the application.

30
4.2.7 Features Not To Be Tested
We will try to test every features. But If we cant manage Schedule. Then
we may skip those Features and attribute with low priority below:

4.2.8 Approach
Testing Levels

The testing approach for Chat Application project is Master Test Plan or
MTP. Which includes unit testing, integration testing and acceptance testing.
In this project testing is done by developer, tester and user. Unit testing will
be done by developers. Developer must provide unit testing data to tester.
Integration testing will be done by tester. After all major and critical de-
fects are solved it will go through acceptance test which will done by end user.

Test Tools

o Selenium Web Browser Automation


o Microsoft Visual Studio 2012 Load Testing
o CIUnit Unit testing for CodeIgniter
o Firebug Web development tool that facilitates debugging
o FreeMind - free mind mapping software
o JSUnit Unit testing for Javascript
o Multi-Mechanize Performance and Load Testing
o Capybara Acceptance test framework

Meetings
The test team will meet once in every weeks to evaluate the progress and
identify all problems and conduct a solution. Test team will also meet with

31
development team to merge their ideas about testing and quality of our web-
site. Addtional mettings can be called as required for emergency situation.

Measures and Metrics

The following information will be collected by the Development team during


the Unit testing process. This information will be provided to the test team
at program turnover as well as be provided to the project team on a biweekly
basis.
o Defects by module and severity
o Defect origin
o Time spent on defect resolution.
The following information will be collected by the test team during all test-
ing phases. This information will be provided on a biweekly basis to the test
manager and to the project team.
o Defects by module and severity
o Defect origin
o Time spent on defect resolution
o Number of times a program submitted to test team as ready for test.

Item Pass Fail Criteria

The test process will be completed when the project leader will be satis-
fied with the result of the test. For this, at least 90% of test cases must pass;
all functionalities must be covered in those test cases and most of all, high
and medium severity defects must be detected and fixed. Minor defects can
be ignored, but with the assurance that it does not lead to severe defect.
The project leader will decide whether the detected defects and criticality
will cause the release of Chat Application of version 1.0 to delay.

32
5 User Manual
5.1 Processes
5.2 Registration for new Member
Open Chat Application & Click on Sign Up. Then This window will pop up.
Then You have to submit valid info to Successfully register.

33
5.3 Login Features
Open Chat App then click on Log In Button. Then Submit Valid Info to
access your account.

34
5.4 Private Chatting

35
5.5 Adding Friend
Open chat app then click on more options then click on add friend. There
you will be able to search for friend.

36
5.6 Chat Forms
After Login you will automatically redirected to Chat Forms

37
5.7 Block Friend
Go to setting Edit Friend List then You will see Block Button underneath
the layout

38
5.8 Settings

39
5.9 Conclusion
There is always a room for improvements in any apps. Right now we are
just dealing with text communication. There are several android apps which
serve similar purpose as this project, but these apps were rather difficult to
use and provide confusing interfaces. A positive first impression is essential
in human relationship as well as in human computer interaction. This project
hopes to develop a chat service Android app with high quality user interface.
In future we may be extended to include features such as:

1. File Transfer

2. Voice Message

3. Video Message

4. Audio Call

5. Video Call

6. Group Call

5.10 Troubleshooting

5.11 Frequently asked question


How do I backup, restore or transfer my Chat Application data?

40
You can back up your ChatApp data using Google Drive or a local backup.
Local backups will be automatically created every day at 2am and they will
be saved as a file in your phone.

Why can’t I connect to Chat App?

Restart your phone, or turn it off and on.


Why are my incoming messages delayed?

Make sure your phone has Internet connection


Make sure background data is not restricted
How do I reinstall?

To uninstall ChatApp, go to your phone’s Settings app then Apps then Chat-
App then Uninstall.
Installing ChatApp
Please follow this link. It will navigate you to Google Play where you can
tap Install to start downloading the app.
Open ChatApp and continue to the next screen by agreeing to our Terms of
Service.
Verify your phone number.
If a backup of your chat history was found and you would like to restore it,
choose Restore. Learn more about restoring here.
Lastly, type in your name. You can also change this later in ChatApp by
going to Menu Button then Settings, and tapping on your profile name.
How do I fix the Task Manager error?

There are two main problems caused by 3rd party task managers (also called
task killers):
They can temporarily disable ChatApp. This causes ChatApp to disconnect
and reconnect to our server, which drains the battery of your phone and uses
unnecessary amounts of data.
If they close ChatApp, our server has no way of knowing that the connection
has been closed. As a result, message delivery might be delayed.
When I travel abroad, will I be charged for data roaming?

ChatApp Messenger uses the same Internet data plan as web browsing and
email on your phone. If using your cellular data while roaming will nor-

41
mally result in additional charges, you may be charged extra by your mobile
provider for using ChatApp while roaming. Contact your wireless carrier for
details about international roaming countries, SIMs, rates, and policies. If
you do not have an international data plan, we suggest you turn off data
roaming to avoid data roaming charges.
Where can I find my contacts?

Open ChatApp and go to the Contacts tab. How do I change my profile


photo, name, about and status?

Profile photo
Go to ChatApp then Menu Button then Settings.
Tap your profile photo then Camera icon.
You can choose a photo from your gallery, take a new photo with your cam-
era or remove your current photo.
Name
Go to ChatApp then Menu Button then Settings.
Tap your profile photo and then tap your name.
Note: This name will only appear for contacts who do not already have your
contact info saved in their phone’s address book.
About
Go to ChatApp then Menu Button then Settings.
Tap your profile photo and then tap your about.
You can create a custom about or select a pre-filled about.
Note: Your about cannot be empty.
Status
Go to ChatApp then Status screen.
Tap the status icon.
You can take a new photo or record a new video, or choose an existing one
from the picker, then tap the send button.
How do I save my chat history?

To export a copy of the history of an individual chat or group, use the


Email chat feature:
Open the chat for the individual or group.
Tap on the Menu Button.
Tap on More.
Tap on Email chat.

42
Choose whether to Attach Media or not.

5.12 Technical Support


For technical support Contact with following correspondent of our technical
team:

puskuuuu@gmail.com
mourins@gmail.com

6 References
1. http://www.fit.vutbr.cz/study/courses/ITS/public/ieee829.html

2. https://techwhirl.com/user-guide-template/

3. https://www.onetonline.org/search/t2/examples/43231507?s=management%20software

4. http://www.projectinsight.net/project-management-basics/project-management-
schedule

5. https://techwhirl.com/business-requirements-document-brd-template/

6. https://web.cs.dal.ca/hawkey/3130/srst emplate−ieee.dochttps : //bia.ca/risk−


management − the − what − why − and − how/

43

Вам также может понравиться