Society Maintenance Companion: Android Based Application

  ABSTRACT

The Society Maintenance Companion is an Android based application developed with Java language. The main function of this app is to provide an online maintenance report within app that people living in particular society can pay maintenance of their house online. It features monthly or yearly maintenance report. This app also has separate login credentials and the most secured for the security guard. The reason behind this is a member can request to permission their guest before their visit and get a status of visitors. Members can complain to society committee as well as send a feedback for society and my application. User get a news of a society and notifications of society events.

 

Table of Contents

 

TITLE
CERTIFICATE PAGE		I
DECLARATION OF ORIGINALITY		II
ACKNOWLEDGEMENT		III
TABLE OF CONTENT		IV
List Of Figures		VII
List Of Table		IX
ABSTRACT		X
CHAPTER-1
Introduction
1.1	Project Summary	1
1.2	Aim and Objective of Project	1
1.3	Problem Specification and scope	1
1.4	Technology and Literature Review	3
1.5	Materials/ Tools are Required	3
CHAPTER-2
Project Management
2.1	Project Planning and Scheduling	4
2.1.1	Project Development Approach and Justification	4
2.1.2	Project Plan	4
2.2	Project Scheduling	5
2.2.1	Prototype model	5
2.3	Risk Management	7
2.2.1	Risk Identification	7
2.2.2	Risk Analysis	7
2.2.3	Risk Planning	8
CHAPTER-3
System Requirement
3.1	User Characteristics	11
3.2	Hardware And Software Requirements	11
3.3	Constraints	12
CHAPTER-4
System Analysis
4.1	Study Of Current System	14
4.2	Problem And Weakness Of Current System	14
4.3	Requirement of new system	14
4.3.1	Functional Requirements	14
4.3.2	Non-functional Requirements	14
4.4	Feasibility study	15
4.4.1	Technical Feasibility	15
4.4.2	Economic Feasibility	15
4.4.3	Operational Feasibility	16
CHAPTER-5
System Design
5.1	Function of System	17
5.5.1	Use Cases	17
5.5.2	Data Flow Diagram	18
5.5.2.1	Context Level	18
5.5.2.2	First Level	19
5.5.2.3	Second Level	23
5.5.3	Class Diagram	25
5.5.4	Activity Diagram	26
5.2	Data modelling	29
5.2.1	ER Diagram	29
5.3	Data dictionary	30
CHAPTER-6
Implementation Details and Planning
6.1	Implementation Environment	39
6.1.1	Implementation planning	39
6.1.2	Database implementation	39
6.1.3	Administration module implementation	39
6.1.4	User components implementation	39
6.2	Security Features	40
6.3	Coding Standards	40
6.4	Input and Output Design / screen shots of designing pages	41
CHAPTER-7
Testing
7.1	Testing Plan	58
7.2	Testing Strategy	60
7.3	Testing Methods	61
CHAPTER-8
Limitation and Future Enhancement
8.1	Limitation	63
8.2	Future work	63
8.3	Conclusion	63
REFERENCES

LIST OF FIGURES

Figure No	Figure Description	Page No
2.1	Android Architecture	4
2.2	Agile Development Model	10
5.1	Time line	13
5.2	Use Case Diagram: Society and committee members	22
5.3	Use Case Diagram: Admin and Security guard	22
5.4	DFD-Context Level	23
5.5	DFD-First Level: Admin	23
5.6	DFD-First Level: Society	24
5.7	DFD-First Level: End-user	24
5.7	Class diagram	25
5.7	Activity Diagram: Committee members	25
5.7	Activity Diagram: Admin	26
5.8	Activity Diagram: Society members	26
5.9	Activity Diagram: security Guard	27
5.10	ER Diagram	28
6.1	Launching page	48
6.2	Login page	48
6.3	Logout page	49
6.4	Authentication page	49
6.5	Registration Page	50
6.6	Navigation Drawer for members	50
6.7	Transaction page	51
6.8	Notice page	51
6.9	Notice in Detail	52
6.10	News page	52
6.11	News in detail	53
6.13	Visitor etry page	54
6.14	Visitor log page	54
6.15	Loading page	55

 

LIST OF TABLES

Table No	Table Description	Page No
Table 1.1	JSON	6
Table 1.2	XML	7
Table 2.1	Project Plan	11
Table 2.2	Milestone	12
Table 2.3	Risk Type – Possible Risk	15
Table 2.4	Risk Planning	15
Table 3.1	Hardware requirements	16
Table 3.2	Software requirements	17
Table 5.1	Manage company owner	36
Table 5.2	Society list	36
Table 5.3	Transaction Detail	37
Table 5.4	Visitor Log	38
Table 5.5	Guest List Request	38
Table 5.6	Push Notification	39
Table 5.7	Fault Reporting	39
Table 5.8	Emergency Contact	40
Table 5.9	Notice	41
Table 5.10	Events	41
Table 5.11	Complain/Feedback	42

 

 

CHAPTER 1: INTRODUCTION

1.1 Project Summary

The Society Maintenance Companion android application is intend to provide complete solutions for Society through online platform as android application. It will enable society members to pay maintenance as well as check maintenance status; members get security from security guard as a guest verification. User complain and feedback regarding to application and society. In addition, members get a news, notifications and event details from this application.

 

1.2 Goals and Objectives

The objective of the project is to achieve the goals listed below which will help user interact with the system and make maximum benefit out of it.

• Easy Manage of member’s profile by admin.

• Members can solve most off society problems at here

• Design of application mad as an easily use any person.

• Easy Up gradation of maintenance reports and bills.

• Reduce time and space Complexity

• Better performance for notification, communication between members with privacy.

• Easily understandable Application for members, admin and also for developer

• Usable by non-technical users easily

1.3 Problem Specification and Scope

• This project provides online Society maintenance and services for society members.

• The main benefit of this application is members can do request for guest permission to security guard.

• It helps to all society members and they can save their most of times related to society problems.

• This application use for particular one member in one house.

• In this project, members have complained box for complains related to society and gives their opinion in feedback box.

Administrator:

• Can login as Administrator.

• Can add/remove members.

• Can set user-id and password of members.

• Can manage complain and feedback.

• Can generate maintenance reports.

• Send reminders to residents for bill

• Can generate Guest verification.

• Can update news of notice, meetings, events, etc.

• Manage staff, facilities, inventory,

• Send reminders to residents for bill

Members:

• Can download this application.

• Can login through user-id and password given by admin

• Can check their maintenance bill and pay.

• Can do complain and give feedback.

• Can do request for permission to security gard then guest can enter in society.

 

Security guard:

• Can login be using their id and password which given by admin.

• Members can verification of registered guest then allow visiting.

Advantages:

Members gets maintenance bill and also can pay anytime and anywhere and get online receipt so a maintenance service is very fast and secure and member also feel secure using application because was put a best feature guest verification by security guard and member as well as member get notification for meeting, events etc.

Members can complain and gives feedback, read Daily newspaper, and communicate other members like a social media. Members can complain and gives feedback, read Daily newspaper, and communicate other members like a social media.

1.4 Technology Used

Programming language Framework Front End

: XML, Core JAVA, PHP, JSON

: Hibernate

: HTML5, CSS, CSS3, JavaScript, JSP,

JQuery.

Database

Server

Tools

: SQLite

: XAMPP

: Android Studio, PHP.

Documentation

:MS Office 2013, MS Visio 2013.

1.5 Materials/Tools required

• Android Mobile/ tablet
• Internet
• ATM

CHAPTER 2: Project Management

2.1 Project planning and scheduling

Effective management of a software project depends on thoroughly planning the process of project. A well planned strategy leads to the best and optimal use of the resources available and ensures completion of project on time.

Project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out work. The project needs a lot of research and thus scheduling was a difficult task as there was a need for carrying out a lot of study about various techniques and testing them at various stages, thus maintaining the schedule was also difficult.

2.1.1 Project Development Approach (Process Paradigm) and Justification

I have chosen the Agile Development Model for this system development. In any other development model, initially developers have to identify requirements fully. If requirement changes then they have to change their methods of development, or if some requirements have to be removed then, after each iteration they can do modification in requirements.

While in Agile model, customer can change their requirements any time. While coding is going on, parallel testing is simultaneously going on. Henceforth, the modification in code is easy and the team can work faster.

In software application development, agile software development (ASD) is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they are ready.

The goal of ASD is to build upon small client-approved parts as the project progresses, as opposed to delivering one large application at the end of the project.

 

 

 

 

 

 

 

 

 

 

 

2.1.2 Project Plan

 

	Table 2.1 Project Plan
	Task Description	Month	Time Taken
	Requirement gathering and analysis	August	2016
	Define Objectives	September	2016
	System Design	October	2016
	Partial documentation	November, December	2016
	Implementation	January, February,	2017
		March
	Testing	April	2017
	Final Documentation	May	2017

2.2 Project Scheduling

Project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out work. The project needs a lot of research and thus scheduling was a difficult task as there was a need for carrying out a lot of study about various techniques and testing them at various stages, thus maintaining the schedule was difficult.

2.2.1 Prototype model

The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements.This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing.But each of these phases is not done very formally or thoroughly. This prototype is developed based on the currently known requirements. By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the Requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client “plan” with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach.

This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

In addition, the cost of testing and writing detailed documents are reduced. These factors helps to reduce the cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing the final system. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system.

Diagram of Prototype mode

	Advantages of Prototype model:
	  Users are actively involved in the development 
	  Since in this methodology a working model of the system is provided, the users
	get a better understanding of the system being developed. 
	  Errors can be detected much earlier. 

	  Quicker user feedback is available leading to better solutions. 


• Missing functionality can be identified easily 

 Confusing or difficult functions can be identified

Requirements validation, Quick implementation of, incomplete, but functional, application.

Disadvantages of Prototype model:

• Leads to implementing and then repairing way of building systems. 



• Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. 

• Incomplete application may cause application not to be used as the full system was designed

• Incomplete or inadequate problem analysis. 





2.3 Risk Management

The following is the Risk management study report, which is taken for the requirement traceability tools.

2.3.1 Risk Identification

A risk is any unfavourable event or circumstances that can occur while a project is underway. Software is difficult to understand as lots of things can go wrong. So the objective to include this section is to identify risk that can be helping us to understand and manage uncertainty during the development of the project. The following are the possible risks, associated with the project mainly technical and project risks.

Technical Risks:

 

• It may not work properly if there is any problem in Database connectivity.
• It may not work properly if there is any problem in Database connectivity.
• It cannot transact money if you don’t get an OTP.
• It cannot proceed transaction if somehow the users detail is not filled properly.

2.3.2 Risk Analysis

During the risk analysis process, each identified risk is considered in turn and a judgment made about the probability and the seriousness of the risk. It relies on the judgment and experience of the project manager.

 

Table 2.3 Risk Type – Possible Risk

Risk	Probability		Effects
Organizational financial problems force reductions	Low		Catastrophic
in the project budget.
Key staffs are ill at critical times in the project.	Moderate		Serious
Software components which should be reused	Moderate		Serious
contain defects which limit their functionality.
Changes to requirements which require major	Moderate		Serious
design rework are proposed
The organization is reconstructed so that different	High		Serious
management are responsible for the project
The database cannot process as many transactions	Moderate		Serious
per second as expected
The time required to develop the software is	High		Serious
underestimated.
Customers fail to understand the impact of	Moderate		Tolerable
requirements changes.
Required training of staff is not available	Moderate		Tolerable
The rate of defect repair is underestimated	Moderate		Tolerable
The size of the Application is underestimated	High		Tolerable

2.3.3 Risk Planning

The risk that might be uncounted after setting up the server is shown in the table below. All the applications have different internal and external risks. Internal risks basically comprise with hardware failure, power interruption for which the solution is specified. External risks are associated with the application like virus, hacking and the corruption of files. The solution is mentioned in the table below, which is again not much difficult to handle if proper risk planning is done.

Avoidance strategies: Following these strategies means that theprobability that the risk will arise will be reduced. Risk avoidance strategy is the strategy with defective components.

CHAPTER: 3 SYSTEM REQUIREMENT

System requirements study involves a clear and thorough understanding of the product to be developed with the view of removing all ambiguities from customer perception.

3.1 User Characteristics

There are four types of users in these application Society members, Committee members, Security guard and Admin. Admin can manage application and database and account of maintenance bills, receipt, and vendor list, etc. society members check and pay their maintenance bill. In others, members can do complains and als can give their suggestion and also search vendor and committee members contacts, can read daily newspaper as per their requirements. Committee members manage a society member and handle them complains as well as send a notification for meetings, events, notice, etc. Security guard do a guest verification for society and their member’s security by unwanted guest and he can read newspapers.

3.2 Hardware and Software Requirements

Hardware and Software Requirements:

Requirements	Description
Processors	Core i3 or higher
RAM	4 GB or higher
Monitor	800×600 or larger
Hard disk	512 GB or Above
Camera	3 MP and above

Table 3.1 Hardware requirements

 

 

 

 

 

Software Requirements:

Requirements	Description
Platform	Windows XP/7/8/10 or Linux
Database	MySQL 5.0
Tool	Android studio
Server	Apache tomcat 5.0 or higher

Table 3.2 Software requirements

10. Constraint

 

• Hardware constraints:

I have used HIBERNATE framework to build the application and for that Minimum 4 GB RAM is required with 512 MB of Hard Disk Space with minimum 1 GHz processor. This is one-time hardware requirement. Because after hosting the application, users does not need extra hardware specification.

• Design constraints:

To avoid duplication in the database I have used primary key as well as some times also used unique key. To establish relationship between columns of multiple tables, I have used foreign key constraints.

• Reliability

This application must be reliable means it should not be crashed during the execution. I have cared properly no to crash the software. I have used unlimited bandwidth to give high performance in the heavy traffic on the application site.

• Availability

I have considered all the basic requirements of the users before developing the application. So I have provided most of the features to be useful in the application, like submit requirements, update in requirements, analysis of requirements, project management.

•    Security

Security is also a prime requirement of any application. For the security purpose I have used Login authentication before using any feature of the application. I have also encrypted the password of the user in the database to make more secure database.

•    Maintainability

The application is online when I want to maintain anything I have to put application offline. The maintainability of application will be little bit hard but I have designed the application in a way that it will be easy to maintain the application.

•    Portability

I have used JAVA, PHP, HIBERNATE as a back end language and XML as front end. For user’s login, JAVA compiler compiles any of the syntaxes written in JAVA language.

CHAPTER 4: SYSTEM ANALYSIS

4.1 Study of Current Systems

To update any content or any part of application it requires privacy for all users and changing the content manually.

4.2 Problems and Weakness of Current System

In the current scenario of developing android application, I can see that the basic functionalities are poor and time consuming. There are many developers in market and too much cheating with price and quality of product is taking place. Sometimes, the user does not get satisfaction with the developer for get a project as per their requirement. So, this project is made with the solution to provide online functionality and make the work faster and easier.

 

4.3Requirements of new System

developing this application, it allows used anytime and anywhere to solve their society solutions for this application I required online transaction between banks for maintenance bill payments and for security guard he also want to android device and the performance of this application as their side is better because a process of guest verification is need a sometimes by security guard and members.

4.3.1 Functional Requirement

• Admin can create account for users.
• Admin can approve request and track for maintenance payment.

• Members can save their maintenance status.

• Easy maintenance bill payment using paypal integration

• User will able to give feedback.

 

4.3.2 Non-Functional Requirements

• Should work efficiently even on slow internet connections.

• Secure Database.

• Secure Payments.

• Communication between admin and users.

• Allow profile changes and can request for updation

• Provide detailed sitemap.

• Users satisfaction



4. Feasibility Study

A feasibility study is a preliminary study undertaken to determine and document a project’s viability. The results of this study are used to make a decision whether to proceed with the project, or table it. It is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative.

Four types of project feasibility have been considered:

• Technical Feasibility

• Economic Feasibility

• Operational Feasibility

4.4.1. Technical Feasibility:

• The following factors suffice for considering the given project as Technically Feasible.
• The system developed in Java technology, which is well known, and today Ican easily get the technical help of Java technology from the internet.
• I have used this technology and similar types of tools that can be useful to develop this system.
• The project is required to be implemented using Android Studio2.2, and Microsoft SQL Server 2008, which are readily available for the development environment.
• Also use PHP for SL4A (Android Scripting Environment) is a Google-maintained project which “brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device”.

 

4.4.2. Economic Feasibility:

Economic feasibility is most important in development of the software application for any company and projects Because it gives an idea, whether the project going to be developed can be completed at a cost affordable both by the client and developer. The availability of the required hardware and software used to develop our project makes it economically very feasible and Also the company is having all the other required resources needed for the project hence the project is feasible with respect to economy.

4.4.3 Operational Feasibility:

Proposed System is beneficial only if they are turned into Information Systems that will meet the organization’s operating requirements. This test of feasibility asks if the system will work when it is developed and deployed. Are there any major barriers to implementation? The following factors suffice for considering the given project as operational Feasible.

CHAPTER 5: SYSTEM DESIGN

5.1 Function of System

 

5.1.1 Use cases

Figure 5.1 use case diagram for society and committee members

Figure 5.2 use case diagram for admin and security guard

 

 

 

 

 

 

5.1.2 Data Flow Diagrams

5.1.2.1 Context Level

Figure 5.3 context level

5.1.2.2 DFD First Level

Figure 5.4 level-1 for Admin

Figure 5.5 level-1 for Society

Figure 5.6 level-1 for End-user

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.1.3 Class Diagrams:

 

 

Figure 5.7 Class diagram

 

 

5.1.4 Activity Diagrams:

Activity diagram for Committee member:

 

Figure 5.8 Activity diagram for Committee members

 

 

 

 

 

Activity diagram for Admin:

Figure 5.9 Activity diagram for Admin

 

Activity diagram for Society member:

Figure 5.10 Activity diagram for Society members

 

 

 

 

 

 

 

Activity diagram for Security Guard:

Figure 5.11 Activity diagram for Security guard

 

5.2 Data modelling

 

5.2.3 Entity-Relationship Diagrams:

Figure 5.12 ER-Diagram

Table 1: MANAGE MEMBER

 

Column Name	Data Type	Constraint	Description
home_Id	Varchar(5)	Not Null	This field contain information of home block.
Owner_FirstName	Varchar(30)	Not  Null	This field contain store member first name.
Owner_LastName	Varchar(30)	Not  Null	This field contain store member last name.
Owner_MiddleName	Varchar(30)	Not  Null	This filed contain store member middle name.
Contact_No	Varchar(10)	Not  Null	This field contain contact number.
Update	Varchar(15)	Not  Null	This field contain update for member information.
Status	Varchar(10)	Not  Null	This field contain member status.

 

 

 

 

Table 2: MEMBER LIST

 

Column Name	Data Type	Constraint	Description
Home_no	Varchar(5)	Not Null	This field contain information of house number.
Contact_no	Varchar(10)	Not Null	This field contain information of user contact number.

 

Table 3: TRANSACTION

 

Column Name	Data Type	Constraint	Description
user_id	Varchar(10)	Not  Null	This field contain detail maintenance of month wise.
Owner_Name	Varchar(30)	Not  Null	This field contain resident id.
Type	Varchar(5)	Not  Null	This field contain resident name.
Date	Int(10)	Not  Null	This field contain information of amount.
Amount	int(10)	Not  Null	This field contain pay amount.
Type_of_Payment	Varchar(10)	Not Null	This field contain type of payment information.
Bank_name	Varchar(20)	Not Null	This field contain bank name.
Account_Number	Int(16)	Not Null	This field contain bank number.
Month	Varchar(10)	Not Null	This field contain your ATM card expire month.
Year	Int(4)	Not Null	This field contain your ATM cart expire year.

Table 4: VISITOR LOG

 

Column Name	Data Type	Constraint	Description
Visitor_Name	Varchar(30)	Not  Null	This field contain information of visitor name.
member_Name	Varchar(30)	Not  Null	This field contain a member name.
Block_Name	Varchar(5)	Not  Null	This field contain block name.
Home_No	Varchar(5)	Not  Null	This field contain home number..
Gender	Varchar(6)	Not  Null	This field contain gender information.
Number_Visitor	Int (20)	Not  Null	This field contain how many number of visitor for visited.
Vehicle_Number	Int(20)	Not  Null	This field contain number of vehicle.
In_Time	Varchar(10)	Not  Null	This field contain information of in time.
Out_Time	Varchar(10)	Not  Null	This field contain information of out time.
Purpose	Varchar(20)	Not  Null	This field contain information of purpose of visit.
Status	Varchar(10)	Not  Null	This field contain check status.

Table 5 : GUEST LIST REQUEST

 

Column Name	Data Type	Constraint	Description
Guest_Name	Varchar(5)	Not  Null	This field contain guest name.
Home_No	Varchar(5)	Not  Null	This field contain home number.
Number_Guest	Int(20)	Not  Null	This field contain number of guest.
Visiting_Date	Varchar(10)	Not  Null	This field contain information of visiting date.
Purpose	Varchar(10)	Not  Null	This field contain information of visiting purpose.
Mobile_Number	Varchar(10)	Not  Null	This field contain guest mobile number.
Status	Varchar(10)	Not  Null	This field contain check status.

Table 6: PUSH NOTIFICATIONS

 

Column Name	Data Type	Constraint	Description
Message_Title	Varchar(20)	Not  Null	This field contain notification for message.
Content_Type	Varchar(20)	Not  Null	This field contain information of contain type.
Date	Varchar(15)	Not  Null	This field contain information of date
Time	Varchar(10)	Not  Null	This field contain information of time.

Table 7: FAULT REPORTING

 

Column Name	Data Type	Constraint	Description
home_No	Varchar(5)	Not  Null	This field contain home number.
Fault_Name	Varchar(20)	Not  Null	This field contain information of fault name.
Description	Varchar(50)	Not  Null	This field contain information of fault description.
Action	Varchar(50)	Not  Null	This field contain information of action.
Status	Varchar(10)	Not  Null	This field contain check status.
Mobile_Number	Varchar(10)	Not  Null	This field contain member mobile number.

Table 8: EMERGENCY CONTACT

 

Column Name	Data Type	Constraint	Description
Name	Varchar(30)	Not  Null	This field contain person name
Mobile_Number	Varchar(10)	Not  Null	This field contain person mobile number.
Status	Varchar(10)	Not  Null	This field contain check status.

Table 9: NOTICE

 

Column Name	Data Type	Constraint	Description
Name	Varchar(30)	Not  Null	This field contain information name.
Date	Varchar(10)	Not  Null	This field contain notice date.
On_Time	Varchar(10)	Not  Null	This field contain start time.
Off_Time	Varchar(10)	Not  Null	This field contain end time.
Status	Varchar(10)	Not  Null	This field contain check status.

Table 10: EVENT

 

Column Name	Data Type	Constraint	Description
Event_Title	Varchar(20)	Not  Null	This field contain event name.
Event_Type	Varchar(10)	Not  Null	This field contain information of event type.
Date	Varchar(10)	Not Null	This field contain event date.
Contact_Number	Varchar(10)	Not  Null	This field contain event management contact number information.
Event_Description	Varchar(50)	Not  Null	This field contain information of event description.
Start_Time	Varchar(10)	Not  Null	This field contain start event time.
End_Time	Varchar(10)	Not  Null	This field contain end event time.
Charges	Int(5)	Not  Null	This filed contain information of event fees for per person.
Status	Varchar(10)	Not  Null	This field contain check status.

Table 9: Complain/Feedback

 

Column Name	Data Type	Constraint	Description
Home_id	Varchar(30)	Not  Null	This field contain information of user.
Complain_or_ to_Feedback	Varchar(20)	Not  Null	This field complain and feedback to who
Subject	Varchar(30)	Not  Null	This field contain Subject of complain or feedback.
description	Varchar(200)	Not  Null	This field contain description of complain or feedback.
Status	Varchar(10)	Not  Null	This field contain check status.

CHAPTER 6: Implementation Planning And Detail

6.1 Implementation Environment

The project is multi-user as it is launch on the Google play-store ; users whom society is registered in my database can access it simultaneously. The project is a making for a society members and their security guard. The team structure depends on the management style of the organization, the number of people in the team, their skill levels and the problem difficulty.

6.1.1 Implementation Planning

Implementation phase requires precise planning and monitoring mechanism in order to ensure schedule and completeness. I developed the application in various sub phases in Implementation Phase.

6.1.2 Database Implementation

This phase involved creation of database. As I am using XAMMP server to create a database in my project, I was only need to code the PHP Web services concepts and specify their relationships in it.

6.1.3 Administration Module Implementation

This Subsystem involves administration specific services like managing Society members, Security guard, newsletter, transaction charges, transaction type and event notification, solution of fault report and complains.

6.1.4 User Components Implementation

In these phase I have developed user interface components like requesting to guest, registration for this application, changing password, posting complaint or feedback and fault, pay online maintenance and other charges.

6.2 Security Features

Security means protecting the data from accidental or intercepting events. The data and programs must be protected from the threats, theft, disk corruption and any other destruction. Data is secured by password and many constraints have been applied before the user can access the data. The passwords provided by the users are passed in encrypted format. The facility of making password stronger is also provided like combinations of characters, symbols and numbers will create a strongest password which cannot be breached.

• Security to move on different pages of the system is also provided.
• Unauthorized users cannot access to the administrator panel. When user of this application was log out from the web application, it will navigated to the login page and by getting back to that page will not log in the user.
• When user is proceeding transaction as a online, an security is required to allow the transaction to Society members. This makes the transaction committed effectively.

6.3 Coding Standards

Coding standards keep the code consistent and easy for future to read and re-factor. Code must be formatted to agree coding standards. A coding standard should serve two primary purposes. It should preclude those practices that are likely to cause bugs and prescribe those that avoid them. Habit of using coding standards is a sign of good programmer.

Naming Convention

Use of full word descriptors that accurately describe the variable, functions, Id and control names. Keeping underscore between two words in file names. and naming the XML Code  as e.g : User_ID, login_image_smclogo, email, login.

Function Naming

Function and methods naming are applied as per their function in JAVA Code .

Ex  .setOnClickListener()

.OnPreExecute()

.OnItemClickListener

Variable Naming

The name or Id of any input variable starts with a lower case letter and if there comes another word, it should have the first letter as capital. The name will have a value attached „name‟ with it and the Id will have along an „id‟ with it.

Ex: forrgotpass, foultName, description, mobileNo.

Indentation

If else structure, for Next, While and, Do while constructs have been properly intended.

General Code Clean:

1. Removed unused & disposable code.
2. Removed unused variables.
3. Code which useful in future is commented

 

6.4 Input and Output Design / screen shots of designing pages

Launching Page

 

Fig. 6.1 launching page

• This Screen displays as a Splash Screen of this application.

 

Fig. 6.1 login Page

• This Screen displays login for registered members.

 

              

Fig. 6.2 Authentication checker

• This Screen displays checking an authentication user.

 

 

 

Fig. 6.3 Fragment Registration Page

• This Screen displays registration for new user to get a demo.

 

Fig. 6.4 Registration successfully message

• This Screen displays after registration give a message to New user

Fig. 6.5 Loading for database connectivity

• This Screen displays registration for company owner.

Fig. 6.6 Society Member’s profile

• This Screen displays Profile of Society member.

Fig. 6.7 Navigation Drawer for Security Guard

• This Screen displays navigation drawer for Security Guard.

 

Fig. 6.8 Notice page

• This Screen displays notice to the societyMembers.

Fig. 6.9 Notice in detail page

• This Screen displays Notice in detail to the members.

Fig. 6.10  News page

• This Screen displays news of Society to the members.

 

Fig. 6.11 news in detail page

• This Screen displays news in detail to the members.

Fig. 6.12 Launching page

• This Screen displays transaction to pay maintenance charge.

Fig. 6.13 Visitor Request page

• This Screen displays visitor request form send to security guard.

 

Fig. 6.14 Loading page

• This Screen displays event activity loading.

CHAPTER: 7 TESTING

Testing is a process of executing a program with the intent of finding an error. If testing was conducted successfully, it will uncover the error in the software.

Secondly, testing demonstrates that software functions appear to be working according to specification and that performance requirements appear to have been met. In additional, data collected as testing is conducted provides a good indication of software reliability and some indication of software quality as whole.

However, there is one thing that testing cannot do: Testing cannot show the absence of defects, it can only show that software errors are present.

There are several objectives, which are as follows:

Testing Principle

Following are the testing principles, which are used:

• All tests should be traceable to customer requirement.
• Tests should be planned long before testing begins.
• Exhaustive testing is not possible.
• To be most effective testing should be conduct by independent third party.
• To be most effective testing should be conduct by independent third party.

^

7.1 Testing Plan

The aim of the testing process is to identify all defects existing in software Product. However, for most practical systems, even after satisfactorily carrying out the testing phase, it is not possible to guarantee that the software is error free. This is because of the fact that the input data domain of most software products is very large.

It is not practical to test the software exhaustively with respect to each value that the input data may assume. Even with this practical limitation of the testing process, the importance of testing should not be underestimated. It must be remembered that testing does expose many defects existing in a Software product. Thus testing provides a practical way of reducing defects in a System and increasing the users‟ confidence in a developed system.

Functional Testing

The testing technique that is going to be used in the project is black box testing. In black box testing the expected inputs to the system are applied and only the outputs are checked.

The working or the other parameters of the functionality are not reviewed or tested on the black box testing technique. There is a specific set of inputs for each and every module which is applied and for each set of inputs the result or the output is verified and if found as per the system working this testing is termed or result is declared as pass.

If the set of inputs that are provided to each module are not giving the outputs as per the expected results from the module then the result of that testing is to be declare failed.

Moreover the bottom up integration of the modules is applied herein so that each module can be verified at the initial stage and if it is found that the independent module is perfectly alright, only then it is going to be integrated with other related modules otherwise the module is checked for flaws and then if it satisfies all the specific requirements of the module, is integrated to other related modules to form and incorporate a system.

In the black-box testing approach, test cases are designed using only the functional specification of the software, i.e. without any knowledge of the internal structure of the software. For this reason, black-box testing is known as functional testing.

Equivalence Class Partitioning

In this approach, the domain of input values to a program is partitioned into a set of equivalence classes. This partitioning is done such that the behavior of the program is similar for every input data belonging to the same equivalence class. The main idea behind defining the equivalence classes is that testing the code with any one value belonging to an equivalence class is as good as testing the software with any other value belonging to that equivalence class. Equivalence classes for software can be designed by examining the input data and output data.

Boundary Value Analysis

A type of programming error frequently occurs at the boundaries of different equivalence classes of inputs. The reason behind such errors might purely be due to psychological factors. Programmers often fail to see the special processing required by the input values that lie at the boundary of the different equivalence classes. For example, programmers may improperly use < instead of <=, or conversely <= for <. Boundary value analysis leads to selection of test cases at the boundaries of the different equivalence classes.

Structural Testing

In the white-box testing approach, designing test cases requires thorough knowledge about the internal structure of software, and therefore the white-box testing is called structural testing.

Fig:-7.1 Testing Process.

7.2 Testing Strategy

The black box testing is going to be used for the project. The entire module is going to be checked for the specific inputs and the output is going to be checked. Iare going to test the modules individually and thereafter if found to be working as per the expectations they are going to be integrated with other successfully tested modules and then on integrated.

At last all the modules are integrated and thereafter it is checked on a broader basis and all the requirements which are specified are checked for each integrated system modules. If all the functionalities are successfully satisfied than the entire integrated system is found to be working perfectly alright.

The integration is going to be in a bottom up manner where in each individual modules are going to be checked for the first time initially. Later on as and when other modules are developed and are in a working condition than they are integrated and the entire system is going to be generated. As mentioned before these entire system will finally be tested as per the requirements specified by the customer if any flaws are seen they are immediately required to be solved. In short the entire system should be working as per the requirements with no unexpected results.

 

 

 

 

7.3 Testing Methods

Involve execution and implementation of the software with test data and examining the outputs of the software and its operational behavior to check that it is performing as required.

7.3.1 Statistical Testing

Used to test the program’s performance and reliability and to check how it works under

Operational conditions. Tests are designed to reflect the actual user inputs and their frequency. The stages involved in the static analysis are follows.

• Control flow analysis

• Unreachable Code
• Unconditional branches into loops

• Data use analysis

• Variable used before initialization
• Variables declared but never used
• Variables assigned twice but never used between assignments
• Possible array bound violations
• Declared variables

• Interface analysis

• Parameter type mismatches
• Parameter number mismatches
• Non-usage of the results of functions
• Uncalled functions and procedures

• Storage management faults

• Unassigned pointers
• Pointer arithmetic

 

2.      Defect Testing

• Intended to find inconsistencies between a program and its specification. These inconsistencies are usually due to program faults or defects.

• I have tested our functions of component to check the specification of our components. I was selected input set to test the components as if in query process I gave the different kinds of inputs to examine their output.

• I was test software with sequences that have only a single value.

• I was used different sequences of different sizes in different tests.

• Derived tests so that the first, middle and last elements of the sequence and accessed to reveal the problems at partition boundaries.

Table 7.1 Method of Software Testing

Method	Summary
Black Box Testing	A software testing method in which the tester does not know the internal structure/design/implementation of the item being tested. These tests can be functional or non-functional, though usually functional. Test design techniques include Equivalence partitioning, Boundary Value Analysis, Cause Effect Graphing.
White Box Testing	A software testing method in which the internal structure/design/implementation of the item being tested is known to the tester. Test design techniques include: Control flow testing, Data flow testing, Branch testing, Path testing.
Gray Box Testing	A software testing method which is a combination of Black Box Testing method and White Box Testing method.
Agile Testing	A method of software testing that follows the principles of agile software development.
Ad Hoc Testing	A method of software testing without any planning and documentation.

CHAPTER-8 Limitation and Future Enhancement

8.1 Limitation

If members cannot filled a proper detail to pay a online maintenance then they can’t access this feature as a security so a payment of user is delayed.

If members not requested a visitors detail to the security guest then a time consuming is more.as well as some times a visitor list is become a large amount of data and storage a more space.

Guard security is a knowledgeable for use for this application.

If the members do not sign in on this application, then they cannot access any kind of services on this application and an internet is required too.

8.2 Future work

• In future users can communicate with each other in this application by chatting facility for particular society.

• Improve a system of  Society security

• In future, I will add some new features for kids.

• I will add a vendor option to find easily nearest vendor.

8.3 Conclusion

. The use of RFID card decreases the degree of risk. RFID (Radio Frequency Identification) is a wireless technology, which uses electromagnetic fields to transfer data, for the process of automatic identification and tracking tags attached to objects. It reduces the cash flow.

A new vision can be developed for viewing the value of cash. It will force legal transactions and reduce the illegal transactions. Hence, the theft of tax could be minimized. It even eliminates the problem of change. The validity of the card can be set for a particular time and when the validity expires, the amount in the card is transferred again into the user’s bank account.

REFERENCES

Book References

1. Jeffery A. Hoffer, Joey F. George and Joseph S. Valacich, “ModernSystem Analysis and Design”, Ed. 3rd. India: Pearson Education (Singapore) Pte. Ltd, 2002.

2. Craig Larman, “Applying UML and Patterns”, Ed. 2nd. India: Pearson Education (Singapore) Pte. Ltd, 2002.

 

Website Referred

1. www.stackoverflow.com
2. www.w3schools.com
3. www.androidhive.info
4. www.viralandroid.com