Disclaimer: This dissertation has been written by a student and is not an example of our professional work, which you can see examples of here.

Any opinions, findings, conclusions, or recommendations expressed in this dissertation are those of the authors and do not necessarily reflect the views of UKDiss.com.

Workflow Management Online System

Info: 17705 words (71 pages) Dissertation
Published: 11th Dec 2019

Reference this

Tags: Information SystemsManagementTechnology

Table of Contents

TITLE

Certificate Page i
GTU PMMS Completion Certificate ii
Industry Certificate v
Declaration of Originality vi
Acknowledgement vii
Table of Content viii
List of Figure x
List of Table xii
Abbreviation xiii
Abstract xv
CHAPTER-1
Introduction
1.1 Project Summary 1
1.2 Goals and Objectives 1
1.3 Problems Specification and Scope 1
1.4 Technology and Literature review 2
CHAPTER-2
Project Management
2.1 Project Planning and Scheduling 11
2.1.1 Project Development Approach and Justification 11
2.1.2 Project Plan 13
2.1.2.1 Milestones 13
2.1.2.2 Deliverables 14
2.1.2.3 Roles 14
2.1.2.4 Responsibilities 14
2.1.2.5 Resources 14
2.2 Risk Management 15
2.2.1 Risk Identification 16
2.2.2 Risk Analysis 16
2.2.3 Risk Planning 17
CHAPTER-3
System Requirements
3.1 User Characteristics 18
3.2 Hardware and Software Requirements 18
3.3 Constraints 19
CHAPTER-4
System Analysis
4.1 Study of Current System 21
4.2 Problem and Weakness of Current System 21
4.3 Requirement of New System 21
4.3.1 Functional Requirements 21
4.3.2 Non-Functional Requirements 21
4.4 Feasibility Study 22
4.4.1 Technical Feasibility 22
4.4.2 Economical Feasibility 22
4.4.3 Operational Feasibility 23
CHAPTER-5
System Design
5.1 Function of System 24
5.1.1 Use Case 24
5.1.2 Data Flow Diagram 25
5.1.2.1 Context Level 25
5.1.2.2 First Level: User, Admin etc. 26
5.1.3 Class Diagram 29
5.1.4 Activity Diagram 30
5.2 Data Modelling 31
5.2.1 ER Diagram 31
5.3 Database Design 32
5.3.1 Patient Side 32
5.3.2 Doctor Side 33
5.3.3 Admin Side 34
CHAPTER-6
Implementation Details and Planning
6.1 Implementation Environment 35
6.1.1 Implementation Planning 35
6.1.2 Database Implementation 35
6.1.3 Administration Module Implementation 35
6.1.4 User Components Implementation 35
6.2 Security Features 35
6.3 Coding standards 36
6.4 Input and Output Design / screen shots of designing pages 37
CHAPTER-7
Testing
7.1 Testing Plan 56
7.2 Testing Strategy 59
7.3 Testing Methods 59
CHAPTER-8
Conclusion and Feature Enhancement
8.1 Limitation 61
8.2 Future Work 61
8.3 Conclusion 61
References 62

                     

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LIST OF FIGURES

 

 

Figure No Figure Description Page No
1 Prototype model 6
2 Use case diagram 16
3 Data Flow Diagram-Context Level 17
4 Data Flow Diagram-First Level: Admin 18
5 Data Flow Diagram-First Level: Staff 20
6 Class Diagram 22
7 Activity diagram-Login 23
8 Activity diagram-Admin 24
9 Activity diagram-Staff 25
10 ER Diagram 26
11

12

Login

Regestration

41

41

13 Add_country 42
14 Search_country 42
16 Add_state 43
17 Search_state 43
18 Add_city 44
19 Search_city 44
20 Add company 45
21 Search company 45
22 Manage hierarchy 46
23 Search hierarchy 46
24

25

Manage task status

Assign job

47

47

26 Manage department 47
27 Add branches 48
28 Search branches 48
29 Forgot password 49
30 Manage complain 50
31 Manage feedback 51

 

 

 

LIST OF TABLES

 

Table No Table Description Page No
1 Project Plan 4
2 Risk type – possible risk 8
3 Hardware Requirements 10
4 Software Requirements 11
5 Add State 27
6 Add City 27
7 Add Area 27
8 User Details 27
9 Add Job type 28
10 Add Roll 28
11 Add Post 28
12 Add Branch 28
13 Add Feedback 29
14 Add Complain 29
15 Login 29

 

 

 

 

 

 

 

 

 

 

ABBREVATION

 

M2CI    Module to Code Interpreter
JSP   JavaServer Pages
MVC    Model View Controller
HTML    Hypertext Markup Language
CSS   Cascading Style Sheet
Ajax   Asynchronous JavaScript and HTML
     
J2EE    Java to Enterprise Edition
ORM    Object Relation Mapping
ASD   Agile Software Development
JDK

 

  Java Development Kit

 

ABSTRACT

“WORKFLOW MANAGEMENT” is an online system which helps an Organization to control work flow department wise and it also helps to control internal partialities as well as corruption to achieve Organization’s desirable goal.In this modern technical era, everyone wants to be tech connect. This project will show the internal  orientation  of  an  organization  which  is  implementing  on  all  the  departments. Organization can optimize throughout work and bringing them centralize format. By doing this any task can be smoothen.

 

 

 

 

CHAPTER 1: Introduction

1.1 Project Summary

Basically, we have developed this project for Companies, Organizations that will be used for managing workflow hierarchy wise for their better to achieve desirable goal within time. Each employee should must submit their work before the given task duration. If he can’t make it then a notification will pop up after end of the time duration to his superior and that will certainly show in monthly report card as well.

1.2 Aim and Objectives of the project

  • Provide an easy interface so that Staff can easily understand.
  • Provide rating system as per their previous work done according to given time.
  • Provide a facility of messages, emails, complains.
  • Dashboard facility is there so that all the recent activities can easily know.

1.3 Problem Specification and Scope

The purpose of “Organize Organization” is to help an organization to manage workflow system. It reduces internal partialities as well as corruption. It is an application used for an Organization’s various departments and their various staff Hierarchy wise. It is an very fast, easy to use, inexpensive and effective.

1.4 Technology Used

Programming language Framework Front End

: JAVA, J2EE

: Hibernate

: HTML, HTML5, CSS, CSS3, JavaScript, JSP,

JQuery.

Database

Server

Tools

: MySQL

: Apache Tomcat

: Eclipse, SQL Yog.

Documentation

:MS Office 2013, MS Visio 2013

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.

2.1.1 Project Development Approach and Justification

For developing this project, in the first case we went through the basic concept of analysis and examining all users. We analyzed some related projects that offers such kind of facilities and thought over what can we add to make it more efficient and easy to handle. The basic idea behind the project is to provide the convenience to user performing transactions more securely and easily.

Table 2.1 Project plan

Task Description             Time Taken                      Year
 Domain Understanding       July              2016
 Requirement Gathering and analysis      August              2016
 Define Objectives      September              2016
 System Design      October               2016
 Partial Documentation      November, December              2016
 Implementation      January               2017
 Testing                                                     February              2017
 Final Documentation       March              2017

 

2.2 Project Scheduling

Following the software engineering standard as specified for Web Engineering, we are using Prototype model for the development. This process model is explained in brief below.

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 model:

[fig: 2.6.1 software process Model]

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 cannot work if the JDK is not installed in the system. 
  It cannot transact money if you don‟t get an OTP. 
  It cannot proceed transaction if somehow the RFID card or reader is not
working 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 software 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. Its characteristics and system requirements are to be described with the view of removing all ambiguities from customer perception.

3.1 User Characteristics

Our system will be used by two type of user. They are as follow:

● Admin :

This type of user will be responsible to manage whole system & also job task will be published. This type of users will be given special training for doing this if required.

● Staff :

This type of user will be able to get their work from superior and allocate work to his team (Hierarchy wise) and access the notification, create job, post complain etc. but they will not be able to change any content on System .They will be able to give feedback for improvement.

3.2 Hardware and Software Requirements

Table 3.1 Hardware requirements

Requirements Description
Card and Card Reader Java API RFID
Processor Dual core
RAM / Hard Disk 512MB / 100GB
(or higher)

Table 3.2 Software requirements:
Requirements Description
Architecture MVC
Database MySQL
Tool Eclipse, SQL Yog
Framework Hibernate

3.3 Constraint

  • Hardware constraints: 



We need a Java API based RFID Card Reader to read the Luxury Card which itself is a RFID card.



  •                   Design constraints:



The system design is user friendly. All the information about the users are well managed. The system will provide an interface that is available to the user through any of the browser. To avoid duplication in the database we have used primary key as well as some times also used unique key. To establish relationship between columns of multiple tables, we have used foreign key constraints.

  •               Reliability 



To achieve reliability requirement, validation and authentication is used. Secure transactions takes place with the help of hidden tags and labels present in the RFID card which are unique for each of the user.

  •               Availability 



We have considered all the basic requirements of the users like delivering the luxury

card to the account holder, facilities for feedback and complains, getting statements of transactions.





Maintainability 



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





Portability 



We have used JAVA, HIBERNATE as a back end language and SERVLET and JSP as front end.

CHAPTER4: System Analysis

4.1 Study of Current Systems

Carrying large amount of cash everywhere is risky, so people nowadays use card for the transaction purposes but still there are issues that can arise related to its security.

4.2 Problems and Weakness of Current System

Right now in the current scenario of developing web application, we can see that the basic functionalities are so 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. So, this project is made with the solution to provide online functionality and make the work faster and easier.

4.3 Requirements of new System

There is lots of partiality done the large scale industries where the employees are not allotted the work equally. Besides this other systems can only operate through specified devices. This system can be operated from any device

4.3.1 Functional Requirement

The admin-Staff must perform some function for this product. They are as listed below:

1.  Admin

Manage Department

Manage Registration of Staff

Manage Post

4.3.2 Non-Functional Requirement

Performance Requirements

The Organize Organization requires details about the Role, Post, Job Type, Department, and Tasks information about the Staff like name, mobile number, email-id, Role, Post, Job Type, and Department etc.

Security Requirements

Security is an important aspect of any software development. Without reasonable level of security, the availability, the reliability and safety may be compromised if external attack damage to the system. For security purpose we have various validations.

  • Keep software up to date
  • Error Messages
  • Server side validation/form validation
  • Password
  • File uploads
  • Website security tools

regardless of time and place. Besides this it will also keep all the record of work allotment, work completion, etc.







4.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. If it indeed leads to a project being approved, it will – before the real work of the proposed Project starts – be used to ascertain the likelihood of the project’s success. 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 we can 
 easily get the technical help of Java technology from the internet.  
The system development in Java technology is specified by client. 
  • We 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 Hibernate 3.0 and Microsoft SQL Server 2008 which are readily available for the development environment. 

4.4.2. Economic Feasibility:

Economic feasibility is very important in development of the software for any company. 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. 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.

As the System is going to be developed at the place where it is going to be implemented, the track of the operations related to the software is constantly monitored by them and sufficient support is available.

CHAPTER 5: System Design

5.1 Function of System

5.5.1 Use cases

 

 

 

Figure 5.1: Use case diagram

Use-Case Diagram for Staff:

[fig 5.1.1 USE-CASE Diagram for Staff]

5.1.2    Data Flow Diagrams

5.1.2.1 Level 0 DFD Diagram (Context Level)

[fig. 5.2 DFD level 0]

5.1.2.2 First Level:

Level 1 DFD Diagram (Admin)

[fig 5.3 DFD Level-1 Admin]

5.1.2.3Level 1 DFD Diagram (Staff)

 

 

[fig 5.4 DFD Level 1- Staff]

 

 

 

 

 

 

5.1.3 Class Diagram:

5.5 Class Diagram

[fig 5.5 Class diagram]

 

 

 

 

 

 

 

 

5.1.4 Activity Diagram:

5.1.4.1 Admin: Activity Diagram for Login Process

[fig 5.6 Activity Diagram- Login]

5.1.4.2 Activity Diagram for Admin

[fig 5.7 Activity Diagram-Admin]

5.1.4.3 Activity Diagram for Staff

[fig 5.8 Activity Diagram -Staff]

5.2 Data Modelling

 

5.2.1 ER DIAGRAM

 

 

 

 

 

 

C:UsersmunirahemadDesktopUntitled1.png

 

5.3 Data Dictionary

add_state
NO Field Name Data-type Size Constraint Description
(1) State_Id Int 5 Primary Key To store the state id
(2) State_Name Varchar 15 Not null To store state name
(3) State_ Description Varchar 50 Not null To store state description

[Table 5.3.1: add_state ]

add_city

NO Field Name Data- Size Constraint Description
type
(1) City_Id Int 5 Primary Key To store the city code
(2) City_Name Varchar 15 Not null To store city name
(3) State_Id Int 5 Foreign Key of To store the state id for particular
State_Id city
(3) City_Description Varchar 50 Not null To store city description

[Table 5.3.2: add_city ]

add_area

NO Field Name Data- Size Constraint Description
type
(1) Area_Id Int 5 Primary To store the Area
(2) Area_Name Varchar 15 Not null To store city name
(3) State_Id Int 5 Foreign Key of To store the state id for particular
State_Id Area
(4) City_Id Int Foreign Key of To store the city id for particular
City_Id Area
(5) Area_ Varchar 50 Not null To store Area description
Description

[Table 5.3.3 add_area]

 Organize Organization

user_detail
NO Field Name Data- Size Constraint Description
type
(1) User_Id Int 5 Primary To store Employe id
(2) First_Name Varchar 15 Not null To store the user first name
(3) Middle_Name Varchar 15 Not null To store the user Middle name
(4) Last_Name Varchar 15 Not null To store user last name
(5) Address Varchar 50 Not null To store user address information
(6) Pincode Int 6 Not null To store user city pin code no
(7) City_Id Int 5 Foreign key of City_Id To store user city id
(8) Area_Id Int 5 Foreign key of To store the Area id
Area_Id
(9) State_Id Int 5 Foreign key of To store the State id
State_Id
(10) Phone Int 10 Not null To store user contact no
(11) Gender Varchar 6 Not null To store user Gender
(12) Dob Datetime Not null To store user birth of date
(13) Email Varchar 25 Not null To store user email address
(14) Password Varchar 25 Not null To store user account password
(15) Religion Varchar 15 Not null To store Employee Religion
(16) Role Varchar 15 Foreign key of To store EMP Role
Role_id
(17) Post Varchar 15 Foreign key of To store EMP Post
Post_Id
(18) Login_Id Int 5 Foreign key  of Po
Login_Id
[Table 5.3.4 user_details]
add_job_type
NO Field Name Data- Size Constraint Description
type
(1) Job_Id Int 5 Primary To store the Job type
(2) Job_Name Varchar 15 Not null To store Job name
(3) Job_description Varchar 50 Not null To store Job description

 

[Table 5.3.5 user_details]

110300107101(CE)
add_role
NO Field Name Data-type Size Constraint Description
(1) Role_Id Int 5 Primary To store the Role
(2) Role_Name Varchar 15 Not null To store Role name
(3) Role_Description Varchar 50 Not null To store Role description

[Table 5.3.6 add_role]

add_post

NO Field Name Data-type Size Constraint Description
(1) Post_Id Int 5 Primary To store the Post
(2) Post_Name Varchar 15 Not null To store Post name
(3) Post_Description Varchar 50 Not null To store Post
description
[Table 5.3.7 add_post]
add_branch
NO Field Name Data-type Size Constraint Description
(1) Branch_Id Int 5 Primary To store the Branch
(2) Branch_Name Varchar 15 Not null To store city name
(3) State_Id Int 5 Foreign Key of To store the state id for
State_Id particular Location
(4) City_Id Int 5 Foreign Key of City_id To store the city id for
particular Location
(5) Area_Id Int 5 Foreign Key of Area_Id To store the Area
(6) Branch_Description Varchar 50 Not null To store Location
description

[Table 5.3.8 add_branch]

add_feedback
NO Field Name Data-type Size Constraint Description
(1) Feedback_Id Int 5 Primary To store feedback code
(2) Feedback_Description Varchar 50 Not null To store feedback details
(3) User_Id Int 5 Ref. of To store Staff id for particular
Registration feedback
table
(4) Feedback_Date Datetime Not null To store feedback create date

[Table 5.3.9 add_feedback]

add_complain

NO Field Name Data-type Size Constraint Description
(1) Complain_Id Int 5 Primary To store customer complain id
(2) Complain_Date Datetime Not null To store customer complain date
(3) User_Id Int 5 Ref. of To store complain user code
Citizen_Mst
(4) Complain_Description Varchar 15 Not null To   store   complain   status
information

[Table 5.3.10 add_complain]

login

NO Field Name Data-type Size Constraint Description
(1) Login_Id Int 5 Primary To store staff user id
(2) Email_Name Varchar 15 Not null To store staff email address
(3) Password Varchar 15 Not null To store user account password
(4) User_Type Varchar 15 Not null To store type of user

[Table 5.3.11 login]

 

CHAPTER 6: Implementation Planning And Detail

6.1 Implementation Environment

The project is multi-user as it is launched on the internet; all users can access it simultaneously. The project is a result of group consequences. 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. We developed the site in various sub phases in Implementation Phase.

6.1.2 Database Implementation

This phase involved creation of database. As we are using Hibernate Frame work in our project, we only need to code the hibernate concepts and specify their relationships in it.

6.1.3 Administration Module Implementation

This Subsystem involves administration specific services like managing card request, bank, city, state, country, newsletter, transaction charges, transaction type and money transfer.

6.1.4 User Components Implementation

In these phase we have developed user interface components like requesting a card, registration, changing password, posting complaint or feedback, renewing card or cancelling it, cancelling account.

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 (web forms) of the system is also provided.

Unauthorized users cannot access to the administrator panel. When user‟s 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 by scanning the card, an OTP is required to allow the transaction to both the user as well as seller. This makes the transaction committed effectively.

6.3 Coding Standards

Coding standards keep the code consistent and easy for the entire team to read and re-factor. When the team focuses moves from „me‟ to „we‟, coding standards becomes a natural outcome. 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 MVC files as e.g : BankDao, BankVo.

Function Naming

Function and methods naming are applied as per their function. Ex: insert(), update(), delete().

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: descriptionName, descriptionId

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.

6.4  Input and Output Design / screen shots of designing pages

Admin Side

Login:

 

Fig. 6.1 Login

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Regestration:

 

          Fig. 6.2 Regestration

 

Add Country:

 

Fig. 6.3 Add Counry

Search Country:

 

            Fig. 6.4 Search Country

Add State:

Fig. 6.5 Add State

Search State:

Fig. 6.6 Search State

 

 

 

 

Add City:

Fig. 6.7 Add City

Search City:

 

          Fig. 6.8 Search City

 

 

 

 

 

 

 

 

Add Company:

 

          Fig. 6.9 Add Company

 

Search Company

 

          Fig. 6.10 Search Company

 

 

 

 

 

 

 

 

Manage Hierarchy:

 

          Fig. 6.11 Manage Hierarchy

 

Search Heirarchy:

 

          Fig. 6.12 Search Hierarchy

 

 

 

 

 

 

 

 

Manage Task status:

 

          Fig. 6.13 Manage Task status

 

Assign Job:

 

          Fig. 6.14 Assign Job

 

 

 

 

 

 

 

 

Manage Department:

 

 

Fig. 6.15 Manage Department

 

 

 

 

 

 

Add Branch:

 

 

 Fig. 6.16 Add Branch

 

Search Brach:

Fig. 6.17 Search Brach

 

 

 

 

 

 

 

Forgot Password:

 

C:UsersmunirahemadPicturesScreenshotsScreenshot (36).png

Fig. 6.18 Forgot Password

 

 

 

 

 

 

 

 

Manage Complain:

 

Fig. 6.19 Manage Complain

 

Manage Feedback

 

               Fig. 6.20 Manage Feedback

 

 

 

 

 

CHAPTER: 7 TESTING

Testing is a process of executing a program with the intent of finding an error. If testing is 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.

But 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.
Testing should be in small and progress toward testing in the large.
Exhaustive testing is not possible.
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. We are 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

7.3.2 Defect Testing

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

We have tested our functions of component to check the specification of our components.
We selected input set to test the components like in query process we gave the different kinds of
 inputs to examine their output.
We test software with sequences that have only a single value.
We 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 Types of testing

Sr. Type of testing Responsibility Remarks
No.
1 Unit testing Independent code Checking whether the
(working in any code is
circumstances) Flexible for further
changes to be made.
Will it affect any other
module to any extent
or not. Perform alpha
testing to reduce bugs.
N-Unit tool used.
2 Integration Testing done to check To ensure that running
Interdependencies of the
units. No gaps in data Current test affects the
flow previous code to
achieve each test case.
All fixes are achieved
3 System System as a whole
working on any
environment
4 Acceptance System should operate To ensure no gaps. To
in the achieve the overall
Expected manner. End functionality
user
Maps his initial
requirements with the
system.

CHAPTER-8 Limitation and Future Enhancement

8.1 Limitation

  • Require an Account
  • Require Understanding about System

8.2 Future work

  • Scalability Enhance
  • Cloud Environment
  • Better Option

8.3 Conclusion

  • In nearby future we can make few changes for Government’s all organizations.

 

  • -As our Honorable Prime Minister Mr. Narendra Modi announced to make digital India. We will work on it to apply on Government organization to reduce corruption and internal partialities.

 

  • -We can add more functionality in existing product.

 

  • -We can also add more categories.

 

  • -We will try to add more functionality in my system so that Organization can easily operate this system with high tech security

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this dissertation and no longer wish to have your work published on the UKDiss.com website then please: