Acknowledgement

We take this opportunity to express out sincere thanks and deep

gratitude to all those people who extended their wholehearted co-
operation and have helped us in completing this project successfully.
We would like to convey our gratitude and sincere thanks to our
Project Manager, Mr.Neeraj Kumar who guided us throughout our
project despite of his tight schedule and provided us with dynamic
leadership, great care and direction and smoothened our path towards
the successful accomplishment of our project.
We would like to extend our thanks to all the faculty members for
their encouragement and lending their expertise when needed.
We would also like to express our thanks to all non-teaching staff for
their sincere cooperation and moral boost. We are also thankful to
Mr.Gufran, Softwar Developer Ducat Noida who provided us
necessary information all the time we need.
We would be quite unsatisfied if we do not extend our cordial
thanks to our HOD Mr.Abdul Qayoom Sofi and our Internal guide Mr.
Ovais who at times keep on asking about the project work and provided
us with their valuable suggestions.
Last but not least, we express our heartfelt gratitude to our parents
for their love and blessing to complete the project successfully.

Developers
 CONTENTS
Topic Page No

1. INTRODUCTION 1

2. ANALYSIS 3

3. SOFTWARE REQUIREMENTS SPECIFICATION 10

4. SYSTEM DESIGN 16

5. SYSTEM PLANING 51

6. SCREEN SHOTS 54

7. DATABASE DESIGN 70

8. IMPLEMENTATION 79

9. TESTING 83

10. FUTURE ENHANCEMENTS 99

11.BIBLIOGRAPHY 101
 1

INTRODUCTION
 2

“PayGini – A Software Package for HR Needs “

For an organization to run successfully and efficiently its very

important to manage employee details and resources especially
human resources.So one of the important goal of the organization
is to manage people and resources efficiently.
Managing people and resources have been a difficult task.For
organizations with more than hundred or thousands of employees,
managing each employee’s details, loans and advances, attendance,
multiple shifts and overtime etc., is impossible without an efficient
system.

It is thus felt that a computer based solution be developed, which

can assist organizations in meeting their HR needs.

Hence, a computer based solution PayGini has been made which

can assist organizations in meeting their HR needs.
 3

ANALYSIS
 4
REQUIREMENT ANALAYSIS

The requirement analysis involves studying the existing system to

find out how it works and where improvements should be made.
The output of requirement analysis is a set of basic requirements
plus some other requirements that add more functionality to the
system. The basic requirements include:

• What are the current system processes.

• Data that are used or produced during the processing.

• Limits imposed by the time and the volume of work.

• Performance controls that are used.

INFORMATION GATHRING
 Since defining the user requirements require an
understanding of how the system works and what its

5
problems are ; a variety of factfinding techniques are
used for information gathering in order to develop such
an understanding. For Paygini we use the Existing
system of HR.

Existing System:

In existing system all the work is performed manually which

involves the following flaws:

• Time consuming.
• Hectic.
• Large manpower required.
• Error prone.
• Lack of accuracy.
• Lack of efficiency.
 The problem in building information systems is dealing with the
balance between database design and process design.
Designing/Building the database and designing/building the
software is treated as separate processes.

Problem Definition:

“To develop an alternative for this poor, inefficient and unreliable

manual procedure of Paygini”

Proposed System:

The proposed system, named as ‘PayGini’ is a comprehensive

software package which would provide the following features:

• Manage Employee and Company Details - This would

include the following:
- Capture details of the company and all its employees.
- Categorize employees.
• Manage Loans and Advances – The proposed module
would cover the following:
 - Define any number of loans and advances against
employee.
- Define parameters for loans.
- Facility to reschedule loan repayment.

• Manage Attendance, Multiple Shifts & Over Time –

- Provision for integrating to time attendance system.
- Define number of shifts.
- Validate time attendance for each employee, depending
on status and profile of the employee.
- Define rules for above mentioned validations.
• Company Policy Database – The module would assist
define the policies for various activities. Like min/max limit
for leaves etc.
• System admin module would assist in user definable
passwords etc.

Future Modules: The package may integrate payroll system.

 8

FEASIBILITY STUDY

Once the system requirements are drawn up,the next step is to

check whether it is feasible to implement the system. The
feasibility study takes into account various constraints within
which the proposed system should be implemented and operated.
There are three aspects of feasibility to be considered:

1. Technical Feasibility:

After thorough investigation the proposed system has

been found as technically feasible. The application requires
atleast one Server with minimum of Pentium 4 processor,
2GB RAM and 40GB or more hard disk space is required.

2. Operational Feasibility:
 The proposed system does meet the organization’s
operating Needs and increases the operational efficiency of
the staff as well.The system does not require highly qualified
professional for its operation.

3. Economic Feasibility:

The proposed system is economically feasible

because the cost involved in purchasing the hardware and software
are within approachable .The personal cost like salaries of
employees hired are also nominal, because working in this system
need not required a highly qualified professional. The operating-
environment costs are marginal. The less time involved also helped
in its economically feasible.
 10

SOFTWARE
REQUIREMENT
SPECIFICATION
 11

The software requirements specification is actually the result of

system analysis. While the system analysis describe the problem,
the software requirement specification(SRS) defines the desired
characteristics of the solution.

Purpose:

The purpose of this document is to describe the requirement for

Paygini.

SCOPE:

This project brings forth current methods and techniques used in

the Requirement Specification of information systems. The
highlight here has been the use of various models to define: system
scope, domain analysis, functional behavior, system timing, and
object definition & design.
The problem in building information systems is dealing with the
balance between database design and process design. Designing /
building the database and designing / building the software are
often treated as separate processes. In this project we explore how
these two sides of the coin can be coordinated. Also emphasis has
been given to managing software project. A strict vigilance on time
12

schedules and estimations is followed to mitigate time over run for

development and deployment. To accomplish the above stated
objectives, we have attempted to create a reasonably sized
application consisting of a database and processes. The database
will be designed using an ‘Entity-Relationship’ approach. The
application will be built using the Unified Modeling Language
(UML).

SPECIFICATION REQUIREMENT DEFINITION:

The software requirement definition is developed to ensure that the

developer and the customer have the same perception of the
system. This section includes:
- Proposed H/w Specification
- Proposed S/w Specification
 - Software Requirement Analysis

Business Process:

To understand the business process we have used the UML

Activity diagram notation. Activity diagram is the notation for a
13
special form of state machine intended to model computations and
workflows.We allocate responsibility for the process steps in the
business process definition by creating swim lanes – areas of
diagram with distinct subjects of responsibility.
 Activity Diagram

14

The activity diagram describes how the proposed solution would

assist in managing HR needs of a company. An authorized
company employee is allowed to access and edit critical
information regarding each employee. There is provision for
creating and granting different permissions to different users of the
system. The application works on a Client/ Server environment
where only specific users can access specific required information.
The system records and manages different types of loans, allocated
to different employees. The loan modules takes care of every need
of the HR department, which varies from managing loan details,
processing EMI, rescheduling loans, recovery of loans to
processing and generating different reports. Also it manages daily
attendance for each employee of the company. Daily attendances
are normalized for purpose of payroll and payment of salaries.

Note: The payroll and reporting systems here is treated as external

system and is beyond the scope of this project.

15
Business Concept Model:

Business concept model is a mind map that relates the terms

generated in the business process like Loan, Employee, EMI and
other important terms. The business concept model doesn’t have
to be tightly scoped to the problem that is, it doesn’t need to
be detailed. In simple terms it is the understanding of the
scope of project from business person’s point of view. It
helps in development of common understanding between
the developer of the system and the client. We depict using
a form of UML class diagram

Business Concept Model

16
 SYSTEM DESIGN

17

Use Cases Identification:

Use cases are primary mechanism in UML for defining the
software boundary. They are a function specification of the
software system treating the system as a black box with respect to
its internal structure and organization. Use cases show, in general,
how the requirements are to be met by the software system.

A use case describes the interaction that follows from a single

business event. Our scoped business process tells us about two
events, so we can assume use cases for each of these.

1. Loans and Advances

2. Time Management
3. Administrative Control

18
Use Case Diagram for Loans and Advances

19
Use Case Diagram for Time Management and
Administration

20
Use Case Descriptions:

We use a textual structure here based on that of Alistair Cockburn.

We present a simplified form here. A use case description contains
at least
- an identifying name and / or number
- the name of the initiating actor
- A short description of the goal of the use case
- A single numbered sequence of steps that describe the
main success scenario.

21

Use Case Number: 1

Use Case Name: Apply Loan
Primary Actor: Employee
Secondary Actor: Employee
Description:
An employee makes a request for a term loan by mentioning the
amount of loan desired, the period for which it is required etc. The
employee submits this request for getting approval by the
concerned authority.

Pre-Condition:
1. The request maker should be a permanent employee of the
company.
2. The loan amount should not exceed the maximum loan
amount stated in Loan Master (Company Policy Master
Records).

Post-Condition:
1. The request is made, through duly filled form, and marked
for approval.

Main Success Scenario:

1. An employee accesses the loan application form and submits

it to concerned authority for approval.
2. The employee selects the type of loan desired along with
employee detail, loan amount, and number of installments.
3. The system marks the application as pending (default, i.e.
waits for loan approval, if applicable).
4. The system generates loan application ID.
 5. Authorizee details are added when application is processed
by authority.

Extensions:
6. The loan application may be:
a. Regretted
b. Remain Pending
c. Approved

23
Use Case Number: 2

Use Case Name: Loan Details

Primary Actor: Employee
Secondary Actor: Employee
Description:
Sets policies for different types of loan facilities provided by the
company. Any loan request is processed by a cross check with
policies defined under this use case.

Pre-Condition:
- Loan code should be unique.

Post-Condition:
- Only valid inputs like loan amount and repay period are
entered.
Main Success Scenario:

1. An authorized employee enters the details for each type of

loan facility available to company staff.
2. The employee enters valid inputs which include grade,
maximum loan repayment period, and maximum loan
amount.
3. The employee enters description for each type of loan.
4. The system generates unique loan code for each new entry.
5. All specified valid entries are stored into a database.

24
Use Case Number: 3

Use Case Name: Loan EMI Calculation

Primary Actor: Employee
Secondary Actor: Employee
Description:
Describes all loans awarded against each employee or a particular
employee. Calculates EMI’s against each loan granted to
company’s employee and makes payment.

Pre-Condition:
a. The desired month should hold valid loan records.
b. Records should be requested for a valid financial
period.

Post-Condition:
c. Only employees who have taken loan should be listed.
d. Records displayed should be for a valid month and
financial period.
e. EMI’s processed should correspond to period of loan.

Main Success Scenario:

1. Authorized employee logs in to access the EMI calculation

module.
2. The person enters the financial period, the location, and the
month for which EMI has to be processed.
3. The person chooses the employee for which EMI needs to be
processed.
 4. Loan details for selected employee are displayed along with
number of EMI’s already processed and the remaining ones.
5. The person processes the EMI for employee.
6. Person logs out.

Extension

5 a. EMI for an employee is processed and person exits.

b. Person pays another installment for the same month.
Case1: Balance loan remains due.
Case2: No further payment remains due: Fail

26
Use Case Number: 4

Use Case Name: Loan Recovery

Primary Actor: Employee
Description:
Describes details of each type of loan. Assist in listing total loans
awarded and their corresponding EMI’s (dues and paid), for each
loan category, against selected employee.
Pre-Condition:
- Valid employee and location should be entered.
Post-Condition:
- Records should be displayed for each loan category for
particular employee only.

Main Success Scenario:

1. Person logs in with valid id.

2. Person enters a valid location and employee working within
that location.
3. Person retrieves records for dues and payments for selected
employee.

27
Use Case Number: 5

Use Case Name: Loan Rescheduling

Primary Actor: Employee
Secondary Actor: Employee
Description:
Allows rescheduling of any loan granted by the company.
Calculates and lists the current status of the loan taken by an
employee.

Pre-Condition:
f. Valid employee location and Employee ID should be
selected.
g. For more than one loan against a particular employee, a
valid Application ID should be entered.

Post-Condition:
h. Records for each requested application ID should be
displayed along with current status of a particular loan.
i. For each editing the corresponding values should be
automatically changed. (Like if loan installment number
is changed then corresponding EMI should also adjust.)

Main Success Scenario:

1. Person logs in with valid ID.

2. Person enters valid employee ID and location for which
records are to be retrieved.

3. Person edits the records and saves the current data into
database.
 4. Person leaves.

Extensions:

3. a. Person makes changes to loan amount.

- Corresponding EMI’s and other values changes. :Success
- Corresponding values do not change :Fail
b. Person doesn’t make changes to any field.
- Current records saved with out changes :Success.

29

Use Case Number: 6

Use Case Name: Loan Application Status
Description:
Sets the status for the loan application as regretted, pending or
sanctioned. Any application first submitted should be marked as
pending.

Pre-Condition:
- All details for the loan application should be duly filed.
Post-Condition:
- For each new request (application) the application is
marked
as pending.
- Only pending applications can be marked as sanctioned or
regretted.
Main Success Scenario:

1. An authorized employee of the company submits an

application form with all details of the requested loan.
2. The duly filed application is marked as pending.
3. An authorized person (administrator) can mark and approve
the loan requested in each application.
4. Three status for application can thus result as:
j. Pending
k. Sanctioned
l. Regretted.

Extension:
4.a For sanctioned loans EMI and the installments paid (if
any) is calculated and saved.
30
Use Case Number: 7

Use Case Name: Mark Attendance

Description:
Sets the status for daily attendance of each employee in a company.
Marks In Time and Out Time for each employee, for a given month
and date.

Pre-Condition:
- The date selected should not be a defined off in company
leave policy database.

Post-Condition:
- Each employee’s In Time and Out Time is marked actual.
- The status for each employee should be recorded as valid
input.

Main Success Scenario:

1. An authorized employee enters the department, location,

shift and month for which he wants to mark attendance.
2. The employee then selects the date for which attendance
has to be marked.

3. The In Time and Out Time are recorded for each employee.
4. An employee is marked Absent or Present correspondingly.
5. Valid records are saves to database.

31

Use Case Number: 8

Use Case Name: Normalize Attendance
Description:
Sets status for attendance in case an employee is marked absent
according to ‘Leave Mark Policy’ of the system. I.e., if an
employee is on field duty and attends office during late hours. In
such case his/her attendance will be normalized to full day working
status, rather than being marked absent for the day.

Pre-Condition:
- An employee should be present on particular day for which
normalization has to take place.
- The normalization cannot take place for holidays.

Post-Condition:
- The normalized attendance cannot be marked absent for
payroll module.

Main Success Scenario:

1. An employee of the company enters details for the month

and date for which normalization is desired.
2. Employee details are displayed along with marked
attendance for each employee.
3. The normalization In Time and Out Time is set of a

particular employee.

4. Records are stored and used for other modules.

32
Use Case Number: 9

Use Case Name: Login

Description:
Allows access for users. This is the main access point to the
software and all users enter by submitting relevant User ID’s and
Password.

Pre-Condition:
m.Valid User Name and Password should be provided.
Post-Condition:
n. None
Main Success Scenario:

1. Only Valid Authorized users can access the system.

2. Person enters valid username and password.
3. Person gains access to the system.
4. For invalid username and password, system exits.

33
Use Case Number: 10

Use Case Name: Create User

Description:
Creates new user for access to the system. The system access
permissions are granted separately.

Pre-Condition:
Only system admin or master account user can grant
permissions to other users.
Post-Condition:
None
Main Success Scenario:

1. An authorized person enters the system and creates new

user by assigning username and password.
2. New user category is defined (Master or normal).
3. New User created.

34
Use Case Number: 11

Use Case Name: Grant Permissions

Description:
Grants access permissions to all users created earlier.
Grant permission can be accessed using master account (Admin
Account)

Pre-Condition:
o. Access permissions can be granted only to authorize
users.
Post-Condition:
p. None
Main Success Scenario:

1. Authorized person enters to grant permission to different

users.
2. Permission are granted for those users, created by master
account (Authorized person)
3. Permissions are granted for various sections of the system.
4. A new master account can also be created using this
facility.
5. Permissions are granted and user exits.

35
 E-R DIAGRAM

Identifying Entities and Attributes:

We transform the class diagram to ER-Diagram by identifying the

persistent and non-persistent data being maintained by the classes.
36
 InstallmentAmt
Permissio
n
InstallmentDat LastUpdate_Dat
SubModuleN e
o
lmonth
SubModuleN
LOGIN_SECURITY o

LOAN_RECOVERY

Permit Makes
User_Id

LOGIN_ Is_Ma
MASTER Create EMPLOYEE de_Fo

LnAppI
D
X
: Applie LOAN_APPLICATION

nAmt
MaxLoanAmt

Ln_Code
Percent LOAN Is
For LnStatu
s
InterestDate
LnAppDat
e
MaxRepayPeriod
e
GradeCode SancAmt

UserName InstallmentNo
s
BP_Cod AuthorisedDat
e e
Passwor
d AmtToBeRepai
d
Logintype
LastUpdate_Date
LastLoginDat
e
SancInstallmentNo
s
37
 Shift code

intime LastUpdate_Dat
e
empcod
e outime
Atendat
e
Normalization

Under
goes satus

Makes Attendance BPcode

Sft
In time cd

X OutTime
: LnAppI
D

38
38
 Business Type Model
The figure above shows the Class Diagram for the proposed
model. Here the Employee is the external system that is out of
scope of the given project domain. We assume that the information
needed for our problem domain will be shared form this external
system.

39
 Sequence Diagram

Use case diagrams present an outside view of the system. The

functionality of a use case is captured in its flow of events.
Scenarios are used to describe how use cases are realized as
interactions among societies of objects. Scenarios are captured in
sequence diagrams. Sequence diagrams are associated with use
cases.

The sequence diagrams describe the dynamic behavior of the

objects. While a collaboration diagram emphasizes the structural
organization of the objects, the sequence diagram emphasize on the
time ordering of the messages.

For our proposed model we use sequence diagrams* to depict the

sequence of activities that must take place for a given use case.

40
[* Note: we include Sequence Diagram for every Use Case
described in the requirements document. However, the details of
data structure, for each operation may not be described in the
diagram (due to print limitations). For such cases, we describe
them separately along with the diagram.]
Loan Master Sequence Diagram

setLoanDetail( in lnD[1..*]: Loan Details, in fp: Financial Period,

in cD: company ID, in gC: grade Code, out lnID : Char )
41
 Sequence Diagram for Loan Status(New Loans)Use Case

getApplicationDetails ( in lnD[1..*]: LoanDetails, in cD: Company

Details, in eD: Employee Details,
out lnID: Char, lnSt: Char )
 42
Sequence Diagram for Loan Status(New Loans)UseCase
 43

Here the administrator/ authorized person approves or disapproves

the loan application being created in earlier use case. In case the
loan is approved the administrator enters the sanctioned amount
and the system then calculates the estimated EMI for that loan. The
interested is calculated as applicable.
In case the loan is disapproved, the system just records the loan
status as cancelled. In such case the original records is maintained
by the system.
 44

Sequence Diagram for Loan EMI Processing Use Case

The sequence diagram above describes the loan EMI processing

use case.
The structure of the data type is as follows:
getEnquiryDetails( in emp: Employee Name, in fp: Financial
Period, in lo Location, out ld[1..*]: loan Details )
 45

Sequence Diagram for Loan Rescheduling Use Case

For rescheduling a loan, the administrator accesses the required

loan details and then only makes the required rescheduling. I.e., the
administrator enters the new period for repayment of the loan,
accordingly the EMI’s are calculated for that loan. All records are
also updated respectively.
 46

Sequence Diagram for Create User Use Case

The above figure shows how the proposed model creates a new
user and grants permission for it. The user here is the employee of
the company, which already exists. We assume that the data for
data for the employees is maintained by an external system and is
out of scope of our problem
 47

Sequence diagram for grant/change user permissions

 48

Sequence diagram for Mark Attendance Use Case

The diagram above explains how Mark Attendance is

accomplished. The attendance is marked for a particular employee
for a particular day.
 49

The day records are maintained by a separate table and the system
thus first checks for any holidays or described leaves, if any. This
is accomplished by the getDayDetail() method shown above. The
getAttendanceStatus method marks an employee as absent or
present. Once the attendance is marked for a particular employee,
all records are then maintained and stored.
 50

Sequence Diagram for Normalize Attendance

An attendance is normalized for a particular employee, for a

particular day, thus the getDayDetail() method above gets the day
for which changes have to take place. The current marked status of
the attendance is then checked. The administrator thereafter marks
the normalized status for the attendance.
 51

SYSTEM PLANING
 52

Project Planing

For the purpose of estimating the duration and maintaining strict

time schedule for the project, we first break down the project into
relatively smaller group of activities. This technique of dividing
the problem domain into smaller units, of tasks and subtasks, is
known as Work Break Down Structure (WBS).
The technique is efficient since it helps in estimation and better
handling of the project.
For our problem domain the WBS are specified as stated below.
Project planning is an important work and entrails all the activities
that must be performed before starting development work.
The system has been defined to contain the following list of
activities along with the required time of activities

S.NO Activity Predecessor Time(in weeks)

1. Existing System Study -- 1
2. Requirements Analysis 1 4
3. Feasibility Study 2 1
4. System Analysis 3 2
5. System Design and
Coding
5.1 Database Design 4 2
5.2 User Interface Design 4 2.5
6. System Testing 5.1-5.2 1
7. Implementation 6 1
 53

3 5.
1 1
2 1
2
1
4 4
6 1 7
2
2
2.5
5.
2

Fig: - Pert Chart for System planning (figures shows time in

weeks)

Critical path = (1+4+1+2+2.5+1) weeks

= 11.5 weeks.

Minimum time required completing the project:

= (1+4+1+2+2+1) weeks
= 11 weeks.

54
SCREEN SHOTS

55
Picture 1: Home Page

Purpose:- The page displays general information.

 56

Picture 2: Admin Login Page

Purpose:- This page allows Adminstrator (HR) to login

and go through following modules i-e Create,
Attendence , Loan.
 57

Picture 3: Admin User Page

Purpose:- This page allows that the Adminstrator (HR) can

create a new user ,grant him permission and
can also view all employees

58
Picture 4: User Page

Purpose:- This page Creats a User with Employee Code

and Password given by HR.

59
Picture 5: Permission Page

Purpose:- This page gives Prmission to a Particular

Employee.

60
Picture 6: Attendence Page

Purpose:- This page appears when HR has to Normalize

and Mark Employee Attendence

61
Picture 7: Mark Attendance Page

Purpose:- It Marks Attendence Of a particular Employee.

62
Picture 8: Normalized Page

Purpose:- It Normalizes Attendence on the basis of

Employee code.

63
Picture 9:Employee Login Page

Purpose:- This page allows Employees to mark his/her

Attendence and other Loan Details etc.

64
Picture 10: Loan Page

Purpose:- This Page Gives information about all Loan

Modules.

65
Picture 11: Apply Loan Page

Purpose:- This Page appears when an Employee wants

to Apply for New Loan.

66
Picture 12: Reschdule Page

Purpose:- It Reschudles Loan.

67
Picture 13: Loan Detial Page

Purpose:- This page gives details of all Loans given to

an Employee.

68
Picture 14: Invalid Username/Password Page

Purpose:- This page displays a message in case user

enters a wrong username or password.The user can try
logging into the system by clicking on the try again link.

69
Picture 15: Logout Page

Purpose:- Sign Out for Admin.

70
DATABASE DESIGN

72
 Table Structure and Field Description
For our proposed model the Tables and the associated Attributes
are as follows:
Loan_emp_app

Attribute Type
BP_Code Character
LnAppID VarChar
EmpCode Character
Ln_Code VarChar
LnAppDate Date
LnAmt Float
InstallmentNos SmallInteger
LnStatus Char
AuthorisedBy Char
AuthorisedSite Char
AuthorisedDate Date
LnSancAmt Float
EMI Float
SancInstallmentNos SmallInteger
LnAmtToBeRepaid Float
LnAmtRepaid Float
LnAmtBalance Float
IssueDate Date
User_Id Char
LastUpdate_Date DateTime

LOAN_EMPLOYEERECOVERY

Attribute Type
BP_Code Char
LnAppID VarChar
EmpCode Char
Ln_Code VarChar
FinancialPeriodID VarChar
Month Integer
InstallmentDate Date
InstallmentAmt Float
User_Id Char
LastUpdate_Date DateTime

74

MASTER_LOAN
Attribute Type
BP_Code Char
Ln_Code VarChar
Ln_Desc VarChar
MaxLoanAmt Float
Interest Char
Percent Float
MaxRepayPeriod SmallInteger
GradeCode VarChar
User_Id Char
LastUpdate_Date DateTime
 75

ATTENDANCE

Attribute Type
BP_Code Char
LocationCode VarChar
Attendance_Date Date
EmpCode Char
Department_Code Char
ShiftCode Char
In_Time Char
Out_Time Char
AppStatus Char
TotalHrs Char
User_ID Char
LastUpdate_Date DateTime
 76

EMPLOYEE

Attribute Type
BP_Code Char
EmpCode Char
name Char
epassword Char
F_name Char
M_name Char
dob Date
T_address Varchar
p_address Varchar
pno Number
mno Number
email VarChar
Quail VarChar
Sex Char
doj Date/Time
 77

Loan_sanc
Attribute Type
Loan_app_Id Varchar
Authorisd Site Char
Authorisd By Char
LoanSancAmt Integer
LoanSancNo Integer
Issue Date Date/Time
EMI Integer
Lsanc_instlment Integer
LnAmt2BeRepaid Integer
LnAmt Repay Integer

MASTER_LOGIN

Attribute Type
UserName VarChar
BP_Code Char
Password VarChar
Logintype VarChar
LastLoginDate DateTime

78

MASTER_SECURITY
Attibute Type
Bp_Code Char
UserID Char
SubModuleNo Integer
Permission Char

SETUP_SUBMODULE

Attribute Type
SubModuleNo SmallInteger
ModuleNo SmallInteger
SubModuleName VarChar

Note: Attributes in Italics signify ‘Foreign Keys’. Attributes in

Bold signify ‘Primary Keys’. The attributes in Bold + Italics
signify ‘Composite Primary Key’.

79
 IMPLEMENTATION

80

SYSTEM IMPLEMENTATION

The Paygini has been implemented by using the following

environment:
 • Operating System Windows XP/Vista
• Front-End J2EE
• Back-End Ms-Access

Also, the Paygini has been designed with the following

minimum hardware requirements:

• Processor Pentium IV
• Memory(RAM) 256 MB
• Hard Disk 40GB or above
• Monitor 256 VGA Color Monitor

81

SOFTWARE AND TOOLS USED

Tools intended to be used for the development of the

proposed project are:

Java 2 Enterprise Edition (J2EE):

 J2EE is a superset of J2SE that is geared toward enterprise
programming with an emphasis on server-side development using
Enterprise JavaBeans (EJBs), web applications (servlets and
JavaServer Pages), CORBA, and Extensible Markup Language
(XML).
The machines (hardware resources) that have been used for
the development of the project have the following configuration:
• Intel Pentium IV.
• 256 MB RAM or above.
• 80 HDD or above.
All the development will be carried out under windows platform.
As this project titled “Paygini” will be developed using j2ee
therefore platform independent.

82

On the end user side we expect the final program to run well
on any system having a configuration equal to or higher than:
• Intel Pentium IV.
• 128 MB RAM
 • Minimum 80 HDD .
• Windows / Mac / Linux with any Java enabled web browser.

SOFTWARE REQUIREMENTS

• Back End Database : Ms-Access

• Front End Developer : J2EE.

• Operating System : Windows xp Professional.

• Web Server : Weblogic 8.1

83
 TESTING

84

Test Plan Document.

A test plan is a general document for the entire project which

defines the scope, approach to be taken, and the schedule for
testing, as well as identifying the test items for entire testing
process, and the personnel responsible for the different activities of
testing. The test plan can be done well before the actual testing
commences and can be done in parallel with the coding and design
phases.

The requirement document and design document are the basic

documents used for selecting the test units and deciding the
approaches to be employed during testing.

For our problem domain we start this procedure by defining the

Test Cases. During testing, the program to be tested is executed wit
a set of Test Cases and the output of the program for the test cases
is evaluated to determine is the program is performing as it is
expected to do.

85

This kind of dynamic approach can only ascertain the presence of

error in the program; the exact nature of the error is not usually
decided by testing.
We begin with defining test cases for each Use Case identified
earlier in the requirements document.

The test plan would specify the following:

- Test Unit Specification

- Features to be Tested
- Approach for Testing
- Test Deliverables
- Schedule. (generally defined for big projects)

86

Unit Number: 1.0

Test Unit: Login Module
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Company Enable selection amongst registered
Selection companies.
2. Authenticate User Enable already registered user to
access
3. User Registration Enable new user to register.
4. Grant Permission Assign desired permissions to
registered users only.
5. Create New Enable creation of new company
Company account.
6. Record Login Record Login Time and Date for
user.

87

Unit Number: 2.0

Test Unit: Loan Module
Feature To Be Tested: Apply New Loan
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access
2. Loan Selection Enable selection amongst registered
Loan Types.
3. Employee Select from pre-listed employees of
Selection particular department and company.
4. Submit new Loan Enable submission of new loan
Request request.
5. Submit Authentic request mark pending.
6. Access Enable browsing registered
applications applications.

88

Unit Number: 2.1

Test Unit: Loan Module
Feature To Be Tested: Sanction New Loan
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access
2. Access a. Enable browse thorough submitted
Applications applications.
b. Define status of each application.
3. Submit Authorizee Enable selection of employee.
Details
4. Submit approved Enable submission of loan details,
Loan details which are approved.
5. EMI calculation Define EMI for each loan approved.
6. Record details Enable registration of all details in
database.

89

Unit Number: 2.2

Test Unit: Loan Module
Feature To Be Tested: Loan EMI Process
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access.
2. Define Financial Enable selection of financial year.
Year
3. Select Employee Enable selection amongst pre-
registered employees.
3. Define Loan Define current loan status for
Status selected employee.
4. Process EMI Enable repayment of EMI for a
particular loan.
5. Update Status For amount paid Update Status of
loan.
6. Record details Enable registration of all details in
database.

90

Unit Number: 2.3

Test Unit: Loan Module
Feature To Be Tested: Loan Repayment Reschedule
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access.
2. Select Employee Enable selection amongst pre-
registered employees.
3. Define Loan Define current loan status for
Status selected employee.
4. Reschedule Loan Enable Rescheduling for a valid
number of installments by each loan
type.
5. Alter EMI Enable change of EMI.
6. Update record Enable registration of all details in
details database.

91

Unit Number: 2.4

Test Unit: Loan Module
Feature To Be Tested: Loan Recovery
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access.
2. Select Employee Enable selection amongst pre-
registered employees.
3. Define Loan Define current loan status for each
Status loan granted to selected employee.

92

Unit Number: 3.0

Test Unit: Time Management Module
Feature To Be Tested: View/ Mark Attendance
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access.
2. Select Employee, Enable selection amongst pre-
shift, month, day registered employees, shift(s) and
define month, day.
3. Define day detail Define attendance for selected day.
4. Select day for Enable mark attendance status for
Mark Attendance selected day.
5. Record Details Record all details in database

93

Unit Number: 3.1

Test Unit: Time Management Module
Feature To Be Tested: View/Normalize Attendance
Test Approach: Black Box Testing
Sr.No. Test Cases Expected Result
1. Authenticate User Enable permitted user to access.
2. Select Employee, Enable selection amongst pre-
shift, month, day registered employees, shift(s) and
define month, day.
3. Define day detail Define attendance for selected day
along with in-time and out-time.
4. Normalize Enable normalize attendance status
attendance for selected day.
5. Update records Update changed details in database.

Note: We choose Black Box Testing for our problem domain

since, in this kind of testing the internal details or programs are
not considered for selection of test cases. We plan to test the
outcome of the program against the required expected result,
rather than testing each unit of program separately.

94
Test Document

TC Descript Result Cause Analysi Status

No. ion of Bug s/Soluti
on
1.0.1 Compan Desired NONE -------- Succes
y s
Selection
1.0.2 Authenti Desired NONE -------- Succes
cate User s
1.0.3 User Database Undeclared Calling Revise
Registrat error Variable variable d/
ion change Succes
d s
1.0.4 Grant Access Interchange Reset Revise
Permissi denied d calling the d/Succ
on despite of checkbox. checkb ess
grant ox
permissio
n
1.0.5 Create Desired NONE -------- Succes
New s
Compan
y
1.0.6 Record Desired NONE -------- Succes
Login s
2.0.1 Authenti Desired NONE -------- Succes
cate User s
2.0.2 Loan Invalid Type Set Revise
Selection Selection selected paramet d/Succ
was one er for ess
incremented select
in record record
list. from
D/b.
2.0.3 Employe Desired NONE ------- Succes
e s
Selection
2.0.4 Submit Desired NONE ------- Succes
new s
Loan
Request
2.0.5 Submit Pending Default Set Revise
not Checkbox status d/Succ
marked status set to ess
off
2.1.1 Access Desired NONE -------- Succes
applicati s
ons
2.1.2 Authenti Desired NONE -------- Succes
cate User s
2.1.3 Access Desired NONE -------- Succes
Applicati s
ons
2.1.4 Submit Desired NONE -------- Succes
Authoriz s
ee
Details

2.1.5 Submit Desired NONE -------- Succes

approved s
Loan
details
2.2.1 EMI Incorrect Logical Set Revise
calculati EMI Error Formul d/Succ
on a ess
2.2.2 Record Desired NONE ------- Succes
details s
2.2.3 Authenti Desired NONE ------- Succes
cate User s
2.2.4 Define Desired NONE ------- Succes
Financial s
Year
2.2.5 Select Desired NONE ------- Succes
Employe s
e
2.2.6 Define Status Record Set Revise
Loan displayed selected paramet d/Succ
Status for next was of next er for ess
employee employee in select
employee record
list. from
D/b.
2.2.7 Process EMI Database Set Revise
EMI remains Error query d/Succ
un- change ess
deducted d.
2.2.7 Update Status Database Set Revise
Status Unchang Error query d/
ed change Succes
d s
2.2.8 Record Desired NONE -------- Succes
details s
2.3.1 Authenti Desired NONE -------- Succes
cate User s
2.3.2 Select Desired NONE -------- Succes
Employe s
e
2.3.3 Define Desired NONE -------- Succes
Loan s
Status
2.3.4 Resched Desired NONE ------- Succes
ule Loan s
2.3.5 Alter Incorrect Logical Formul Revise
EMI Emi Error a d/
revised Succes
s
2.3.6 Update Desired NONE ------- Succes
record s
details
2.4.1 Authenti Desired NONE ------- Succes
cate User s

2.4.2 Select Desired NONE ------- Succes

Employe s
e

2.4.3 Define Desired NONE ------- Succes

Loan s
Status
3.0.1 Authenti Desired NONE ------- Succes
cate User s
3.0.2 Select Desired NONE ------- Succes
Employe s
e, shift,
month,
day
3.0.3 Define First Database Databas Revise
day Employe retrieval e select d/Succ
detail e Record error query ess
Empty change
d
3.0.4 Select Desired NONE ------- Succes
day for s
Mark
Attendan
ce
3.0.5 Record Desired NONE ------- Succes
Details s
3.1.1 Authenti Desired NONE ------ Succes
cate User s
3.1.2 Select Desired NONE ------ Succes
Employe s
e, shift,
month,
day

3.1.3 Define Intime/ Variable intercha Revise

day out time values nge d/Succ
detail incorrect interchange value ess
d for
variable
3.1.4 Normaliz Desired NONE ------- Succes
e s
attendan
ce
3.1.5 Update Desired NONE ------- Succes
records s

99
 FUTURE
ENHANCEMENTS

100

FUTURE ENHANCEMENTS
The payroll , Salary and Reporting Systems here is treated as
external system and is beyond the scope of this project. They will
be Implemented in Future.

101
 BIBLIOGRAPHY

102

BIBLIOGRAPHY

1. Bond , Law , Longshaw , SAMS Teach Yourself J2EE,

Pearson Education.
2. Professional JAVA Server Programming Apress Edition.

3. Pressman , Roger S
Software Engineering ( A Practitioner’s Approach ).
McGraw-Hill International Edition.

4. Introduction To System Analysis and Design

Hawryszkiewycz , Igor T.

5. CodeNotes for J2EE , EJB , JDBC , JSP , and Servlets,

Robert McGrovern and Stuart Chariton.

6. Search Engines
http://www.google.com/
http://www.askjeaves.com/