paygini

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

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.

6

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.

7

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.

9

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 Model16

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 LoanPrimary Actor: EmployeeSecondary Actor: EmployeeDescription: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 Pendingc. Approved

23

Use Case Number: 2

Use Case Name: Loan DetailsPrimary Actor: EmployeeSecondary Actor: EmployeeDescription: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.


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 CalculationPrimary Actor: EmployeeSecondary Actor: EmployeeDescription: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.


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 RecoveryPrimary Actor: EmployeeDescription: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.


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 ReschedulingPrimary Actor: EmployeeSecondary Actor: EmployeeDescription: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.)


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 StatusDescription: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.


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. Pendingk. Sanctionedl. 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.


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 AttendanceDescription: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.


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. NoneMain 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 UserDescription: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


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


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.

37

EMPLOYEE

LOAN_RECOVERY

LOAN_APPLICATION

LOAN

Makes

Applies

Is For

SubModuleNo

Permission

lmonth

InstallmentDate

InstallmentAmt

SubModuleNo

LastUpdate_Date

User_Id

Is_Made_For

Creates

LOGIN_MASTER

Permits

LnAppID

Ln_Code

LnAppDate

nAmt

InstallmentNos

AuthorisedDate

LnStatus

SancAmt

SancInstallmentNos

AmtToBeRepaid

LastUpdate_Date

MaxLoanAmt

InterestDate

Percent

MaxRepayPeriode

GradeCode

X:

UserName

Password

BP_Code

Logintype

LastLoginDate

LOGIN_SECURITY

38

Attendance

Normalization

Undergoes

empcode

intime

Shift code

outime

LastUpdate_Date

satus

Makes

LnAppID

Atendate

Sft cdIn time

OutTime

BPcode

X:

Business Type ModelThe 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 -- 12. Requirements Analysis 1 43. Feasibility Study 2 14. System Analysis 3 25. System Design and

Coding5.1 Database Design 4 25.2 User Interface Design 4 2.56. System Testing 5.1-5.2 17. Implementation 6 1

53

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

1

2

2.5

2

21

41

1

2

3

4

5.1

6 7

5.2

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 DescriptionFor our proposed model the Tables and the associated Attributes

are as follows:

Loan_emp_appAttribute Type

BP_Code CharacterLnAppID VarCharEmpCode CharacterLn_Code VarCharLnAppDate DateLnAmt FloatInstallmentNos SmallIntegerLnStatus CharAuthorisedBy CharAuthorisedSite CharAuthorisedDate DateLnSancAmt FloatEMI FloatSancInstallmentNos SmallIntegerLnAmtToBeRepaid FloatLnAmtRepaid FloatLnAmtBalance FloatIssueDate DateUser_Id CharLastUpdate_Date DateTime

LOAN_EMPLOYEERECOVERY

Attribute TypeBP_Code CharLnAppID VarChar

EmpCode CharLn_Code VarCharFinancialPeriodID VarCharMonth IntegerInstallmentDate Date InstallmentAmt FloatUser_Id CharLastUpdate_Date DateTime

74

MASTER_LOAN

Attribute TypeBP_Code CharLn_Code VarCharLn_Desc VarCharMaxLoanAmt Float

Interest CharPercent FloatMaxRepayPeriod SmallIntegerGradeCode VarCharUser_Id CharLastUpdate_Date DateTime

75

ATTENDANCE

Attribute TypeBP_Code CharLocationCode VarCharAttendance_Date DateEmpCode Char

Department_Code CharShiftCode CharIn_Time CharOut_Time CharAppStatus CharTotalHrs CharUser_ID CharLastUpdate_Date DateTime

76

EMPLOYEE

Attribute TypeBP_Code CharEmpCode Charname Charepassword CharF_name CharM_name Char

dob DateT_address Varcharp_address Varcharpno Numbermno Numberemail VarCharQuail VarCharSex Chardoj Date/Time

77

Loan_sancAttribute TypeLoan_app_Id VarcharAuthorisd Site CharAuthorisd By CharLoanSancAmt IntegerLoanSancNo IntegerIssue Date Date/TimeEMI IntegerLsanc_instlment IntegerLnAmt2BeRepaid Integer

LnAmt Repay Integer

MASTER_LOGIN

Attribute TypeUserName VarCharBP_Code CharPassword VarCharLogintype VarCharLastLoginDate DateTime

78

MASTER_SECURITYAttibute TypeBp_Code CharUserID CharSubModuleNo IntegerPermission Char

SETUP_SUBMODULE

Attribute Type

SubModuleNo SmallIntegerModuleNo SmallIntegerSubModuleName 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 ModuleTest Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Company

SelectionEnable selection amongst registered 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

CompanyEnable creation of new company account.

6. Record Login Record Login Time and Date for user.

87

Unit Number: 2.0

Test Unit: Loan ModuleFeature To Be Tested: Apply New LoanTest Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access2. Loan Selection Enable selection amongst registered

Loan Types. 3. Employee

SelectionSelect from pre-listed employees of particular department and company.

4. Submit new Loan Request

Enable submission of new loan request.

5. Submit Authentic request mark pending.6. Access

applicationsEnable browsing registered applications.

88

Unit Number: 2.1

Test Unit: Loan ModuleFeature To Be Tested: Sanction New LoanTest Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access2. Access

Applicationsa. Enable browse thorough submitted applications.b. Define status of each application.

3. Submit Authorizee Details

Enable selection of employee.

4. Submit approved Loan details

Enable submission of 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 ModuleFeature To Be Tested: Loan EMI Process Test Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access.2. Define Financial

YearEnable selection of financial year.

3. Select Employee Enable selection amongst pre-registered employees.

3. Define Loan Status

Define current loan status for 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 ModuleFeature To Be Tested: Loan Repayment Reschedule Test Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access.2. Select Employee Enable selection amongst pre-

registered employees. 3. Define Loan

Status Define current loan status for 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

detailsEnable registration of all details in database.

91

Unit Number: 2.4

Test Unit: Loan ModuleFeature To Be Tested: Loan Recovery Test Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access.2. Select Employee Enable selection amongst pre-

registered employees. 3. Define Loan

Status Define current loan status for each loan granted to selected employee.

92

Unit Number: 3.0

Test Unit: Time Management ModuleFeature To Be Tested: View/ Mark Attendance Test Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access.2. Select Employee,

shift, month, dayEnable selection amongst pre-registered employees, shift(s) and define month, day.

3. Define day detail Define attendance for selected day.4. Select day for

Mark AttendanceEnable mark attendance status for selected day.

5. Record Details Record all details in database

93

Unit Number: 3.1

Test Unit: Time Management ModuleFeature To Be Tested: View/Normalize Attendance Test Approach: Black Box Testing

Sr.No. Test Cases Expected Result1. Authenticate User Enable permitted user to access.2. Select Employee,

shift, month, dayEnable selection amongst pre-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 attendance

Enable normalize attendance status 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 No.

Description

Result Causeof Bug

Analysis/

Solution

Status

1.0.1 Company

Selection

Desired NONE -------- Success

1.0.2 Authenticate User


1.0.3 User Registrat

ion

Database error

Undeclared Variable

Calling variable change

d

Revised/

Success

1.0.4 Grant Permissi

on

Access denied

despite of grant

permission

Interchanged calling

checkbox.

Reset the

checkbox

Revised/

Success

1.0.5 Create New

Company


1.0.6 Record Login




2.0.2 Loan Selection

Invalid Selection

Type selected was one

incremented in record

list.

Set paramet

er for select record from D/b.

Revised/

Success

2.0.3 Employee

Selection

Desired NONE ------- Success

2.0.4 Submit new Loan

Request


2.0.5 Submit Pending not

marked

Default Checkbox

status set to off

Set status

Revised/

Success

2.1.1 Access applicati

ons




2.1.3 Access Applicati

ons


2.1.4 Submit Authoriz

ee Details


2.1.5 Submit approved

Loan details


2.2.1 EMI calculati

on

Incorrect EMI

Logical Error

Set Formul

a

Revised/

Success

2.2.2 Record details




2.2.4 Define Financial

Year


2.2.5 Select Employee


2.2.6 Define Loan Status

Status displayed for next

employee

Record selected

was of next employee in

employee list.

Set paramet

er for select record from D/b.

Revised/

Success

2.2.7 Process EMI

EMI remains

un-deducted

Database Error

Set query

changed.

Revised/

Success

2.2.7 Update Status

Status Unchang

ed

Database Error

Set query

changed

Revised/

Success

2.2.8 Record details








2.3.4 Reschedule Loan


2.3.5 Alter EMI

Incorrect Emi

Logical Error

Formula

revised

Revised/

Success

2.3.6 Update record details










3.0.2 Select Employee, shift, month, day


3.0.3 Define day detail

First Employee Record Empty

Database retrieval

error

Database select query

changed

Revised/

Success

3.0.4 Select day for Mark Attendance


3.0.5 Record Details



Desired NONE ------ Success

3.1.2 Select Employee, shift, month, day

Desired NONE ------ Success

3.1.3 Define day detail

Intime/ out time incorrect

Variable values

interchanged

interchange

value for

variable

Revised/

Success

3.1.4 Normalize attendance


3.1.5 Update records


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/

http://www.askjeaves.com/

http://www.google.com/

paygini

Documents

existing system of hr

efficient system

project work

current system processes

hr needs

project manager

project despite

user requirements