HR Information Project Report (WWW - Students3k.com)

http://students3k.
com
Table of Contents
Introduction
" Human Resource Information System " is an information system to provide effective control of
safety functions and employees' compensation and leave records. This system is meant to
be installed at Durgapur Steel Plant (DSP). The development of the system is done at the
R&D (RDCIS), Steel Athority of India Limited (SAIL), Ranchi, Jharkhand, India. This system
is an extension to a "Human Resource Information System (HRIS)" developed by RDCIS,
SAIL for Durgapur Steel Plant.
The system, basically, deals with areas not considered in HRIS, such as, employees; safety
related functions, leave record and management of gate pass and statutory requirements of
Contract Labour Cell (CLC).
Basically, It is a user-friendly Human Resource Information System (HRIS). It allows the
organization to take advantage of enterprise class HR functionality without the overwhelming
expense traditionally incurred. It manages the employee information, so provides an aid to
manager to manage the employees efficiently.
This particular package is meant to revolutionize the way to manage the human resource
demands. Time required to search the information will be available for planning and heading
off potential problems. The value for benefit that will be received is outstanding and will help
the employees of the organisation to a great extent.
The Major areas considered by the system can be characterised as
Safety Functions
Employees Leave Record Function
Contract Labour Cell (CLC)
The system interacts with three different departments:
Safety Department
Personnel Department
Finance Department
The involvement of these department demands proper co-ordination between them. For
proper and efficient functioning, the system interacts with these three departments.
The objective of the information system is to provide an efficient handling of man-power
resource and keeping track of the accident related information. The system also helps in
keeping the employees leave record up to date. The assistance provided by the system can
be :
Effective and Efficient utilization of the existing man power.
Maintenance of accident detail, analysis and redressal activity.
Management of employee's leave records.
http://students3k.com
1. Organizational Background
1.1 Company Profile
Steel Authority of India Limited (SAIL) is the leading steel-making company in India. It is a
fully integrated iron and steel maker, producing both basic and special steels for domestic
construction, engineering, power, railway, automotive and defence industries and for sale in
export markets.
Ranked amongst the top ten public sector companies in India in terms of turnover, SAIL
manufactures and sells a broad range of steel products, including hot and cold rolled sheets
and coils, galvanised sheets, electrical sheets, structurals, railway products, plates, bars and
rods, stainless steel and other alloy steels. SAIL produces iron and steel at four integrated
plants and three special steel plants, located principally in the eastern and central regions of
India and situated close to domestic sources of raw materials, including the Company's iron
ore, limestone and dolomite mines.
SAIL's wide range of long and flat steel products is much in demand in the domestic as well
as the international market. This vital responsibility is carried out by SAIL's own Central
Marketing Organisation (CMO) and the International Trade Division. CMO encompasses a
wide network of 38 branch offices and 47 stockyards located in major cities and towns
throughout India.
With technical and managerial expertise and know-how in steel making gained over four
decades, SAIL's Consultancy Division (SAILCON) at New Delhi offers services and
consultancy to clients world-wide.
SAIL has a well-equipped Research and Development Centre for Iron and Steel (RDCIS) at
Ranchi, which helps to produce quality steel and develop new technologies for the steel
industry. Besides, SAIL has its own in-house Centre for Engineering and Technology (CET),
Management Training Institute (MTI) and Safety Organisation at Ranchi. Our captive mines
are under the control of the Raw Materials Division in Calcutta. The Environment
Management Division and Growth Division of SAIL operate from their headquarters in
Calcutta. Almost all our plants and major units are ISO Certified.
Major Units of SAIL
Integrated Steel Plants at Bhilai Steel Plant (BSP) in Chhattisgarh, Durgapur Steel
Plant (DSP) in West Bengal, Rourkela Steel Plant (RSP) in Orissa and Bokaro Steel
Plant (BSL) in Jharkhand
Special Steel Plants at Alloy Steels Plants (ASP) in West Bengal, Salem Steel Plant
(SSP) in Tamil Nadu, Visvesvaraya Iron and Steel Plant (VISL) in Karnataka
Subsidiaries : Indian Iron and Steel Company (IISCO) in West Bengal. Maharashtra
Elektrosmelt Limited (MEL) in Maharashtra,SAIL Power Supply Company Limited
(SPSCL) in New Delhi,Bhilai Oxygen Limited (BOL) in New Delhi
1.2 An Overview of R&D Centre for Iron and Steel (RDCIS), SAIL
The Research & Development Centre for Iron & Steel (RDCIS) at Ranchi is the corporate R
& D unit of SAIL. Set up in 1972, the Centre has ISO: 9001 certification to its credit. It
undertakes R & D project in diverse realms of Iron & Steel Technology under the categories
of Basic Scientific Research, Plant Performance Improvement, Investigation & Consultancy
Assignments, Equipments & Instrument Design and Major Technology Development.
RDCIS has more than 300 dedicated and competent scientists and engineers and its
laboratory is equipped with around 300 sophisticated diagnostic research equipment and 5
pilot plant facilities.
RDCIS provides customers with prompt, innovative and cost-effective R & D solutions;
develop and commercialize improved processes and products; continually enhance the
capability of its human resources to emerge as a center of excellence. The major efforts are
directed towards cost reduction, quality improvement and value-addition to products of SAIL
plants and providing application engineering support to SAILs products at customers end.
RDCIS, along with steel plants, has recently taken initiatives to develop special steel
products utilizing the modernized production facilities at steel plants.
RDCIS also offers technological services to various organizations in the form of: Know how
transfer of technologies developed by RDCIS; Consultancy services; Specialized testing
services; Contrast research and technology awareness programmes.
1.3 An Overview of DURGAPUR STEEL PLANT (DSP)

Set up in the late 50's with an initial annual
capacity of one million tonnes of crude steel per
year, the capacity of Durgapur Steel Plant (DSP)
was later expanded to 1.6 million tonnes in the
70's. A massive modernisation programme was
undertaken in the plant in early 90's, which, while
bringing numerous technological developments in
the plant, enhanced the capacity of the plant to
2.088 million tonnes of hot metal,1.8 million
tonnes crude steel and 1.586 million tonnes
saleable steel. The entire plant is covered under
ISO 9001: 2000 quality management system.
The modernized DSP now has state-of -the-art technology for quality steel making. The
modernized units have brought about improved productivity, substantial improvement in
energy conservation and better quality products. DSP's Steel Making complex and the entire
mills zone, comprising its Blooming & Billet Mill, Merchant Mill, Skelp Mill, Section Mill and
Wheel & Axle Plant, are covered under ISO: 9002 quality assurance certification.
With the successful commissioning of the modernized units, DSP is all set to produce 2.088
million tones of hot metal, 1.8 million tones of crude steel and 1.586 million tones of saleable
steel annually.
Centre for Human Resource Development:
DSP has always attached maximum importance on proper training and development of its
employees. Its Centre for Human Resource Development has all modern facilities including
the state-of-the-art Electrical and Electronics laboratory, Hydraulics and Pneumatics
laboratory and workshop for effective training and development of its employees.
Location:
Situated at a distance of 158 km from Calcutta, its geographical location is defined as 230
27' North and 880 29' East. It is situated on the banks of the Damodar river. The Grand
Trunk Road and the main Calcutta-Delhi railway line pass through Durgapur.
2. Background of the Project

Research & Development Centre for Iron & Steel (RDCIS) at Ranchi developed an
information system - "Human Resource Information System (HRIS), for Durgapur Steel
Plant (DSP). HRIS is an information system thats an aid for managing the human resource
at the Durgapur Steel Plant. On completion of the software development, the Durgapur
Steel Plant showed an interest in computerising of areas such as employees' leave record,
safety related functions and management of gate pass and statutory requirements at
Contract Labour Cell (CLC). The required system, basically, deals with areas not considered
in HRIS.
So, the new required system is more of an extension to a "Human Resource Information
System (HRIS)". As the HRIS project was undertaken by the RDCIS, so the additional
demand to develop the extension to the already developed system is taken in hand by the
RDCIS only. This new project is much more than just the continuous software support from
RDCIS for implementation of developed modules. So, the RDCIS proposed a new software
development project for "Computerization of leave records, contract labour cell and safety
department at DSP."
3. Human Resource Information System

3.1 The Purpose of HRIS
A HRIS is implemented of Durgapur Steel Plant (DSP). HRIS stands for Human Resource
Information System. The Human Resource Information System (HRIS) is a record system. It
is the central repository for personnel and payroll data. HRIS supplies information and
statistics on all employees. The data provided is used to determine how human resources
are being managed.
HRIS reports data on all employees to whom the DSP pays or reimburses salaries or
benefits, regardless of funding sources or reporting system; maintains data on former and
current employees; and stores historical personnel data for inquiry and analysis.
3.2 The Impact of Implementing an HRIS

Integrated HR Information Systems (HRIS) have a profound effect on firms that implement
them. Most often these firms are replacing several related systems, such as a personnel
database, payroll system and benefits system, with one single HRIS that does it all. Many
people focus on the improved reporting and processing that will be realized from the new
system, and those are the reasons most firms choose to implement a new HRIS. But what
many people dont focus on is that the new HRIS will most likely affect the company much
more deeply it will challenge the operating structure and principles of all the HR-related
departments.
Actually, in an organization, the pressure is on for proactive HR innovations that contribute
directly to the bottom-line or improve employee morale and efficiency. Ajuwon (2002) points
out that the typical HR professional gets involved with one step in many different flows of
work. Very often the involvement of HR has no purpose except to validate the process in
some way and acts as an interruption to the flow of work. In other words, the HR function is
a 'gatekeeper for information thats been deemed too highly classified for the data owner.'
So, HR is not actually making a measurable contribution - in fact, the opposite. HR
involvement creates a queue or delay in the process. We should ask, if the HR involvement
is really necessary.
Once upon a time the HR database had an 'all-or-nothing' quality - probably because it was
paper-based. But now technology allows controlled access to various portions of the
database. So an employee can safely amend his or her own address or bank account
details, while the ability to change certain appraisal details might be confined to the line
manager. In either case, there is no reason for HR to be involved. HR should move on from
the role of intermediary. The job that used to create delay in an organization, is handled
pretty comfortably by the computerized Human Resource Information System.
So, it can be said that an integrated HRIS results is a drastically different environment than a
cluster of related but separate systems. The core concept of a centralized data store
inherent with an HRIS demands integrated work processes for consistently managing that
store. The two attributes centralized data storage and integrated work processes will
affect the company in ways most managers dont expect.
Not surprisingly, the use of Human Resource information Systems for records, information,
payroll and other functions is becoming increasingly common. The HR, Payroll and other
departments in the organization just gets the information required by it reducing its burden
to a great extent. The HR department is supplied with improved reporting of employee data,
Payroll is provided with the systems pay check calculations and regulatory reporting.
In addition to all this, libraries of forms can be kept online to be downloaded as and when
required. Systems can be enhanced to include streaming video and other new software
providing wide access to corporate videos, training, etc. Obviously, e-mail announcements
and newsletters can also be used to alert employees to new developments or urgent
requests.
3.3 Planning and setting up a new Human resource information system (HRIS) Management of HR Systems
There are three primary activities in an HRIS implementation
configuring the HRIS for the firms business processes and policies,
interfacing data with other systems and converting historical data into the HRIS,
preparing the organization for the new HRIS.
Implementing a new HR information system (HRIS) is one project, which requires a good
project plan to serve as a road map. Implementing a full HRIS, or health and safety,
requires sufficient time to be spent to plan out the future course of action.
A good planning can be possible by following the guidelines.
3.4 Developing the plan

The project leader's initial task is to develop the plan. The more complex the system, the
more detail the plan needs. The questions to answer are:
What has to be done?
In what order should tasks be completed?
Who i going to do it?
By what deadline? and

What is the impact of one task on the others?
Breaking the work down into tasks that can be assigned to individuals is vital to project
planning. Each main task can have numbered subtasks to assist in tracking.
Another approach is to draw a chart that identifies the time line as well as key project due
dates. The project plan is to be monitored periodically to report the progress.
Basic Training. For proper development and implementation of the system, some
training on the system is required. Training is often delivered in a one-time dose of two to
four days, covering in rapid succession everything thats needed to know about the
system. An overview of the system - navigation, functions, file structure and
customization features - is important before moving further on the project.
Finding Ways to Improve Work Flow. Technology provides a wonderful opportunity to

examine the work flow in the HR department, to ask some hard questions about old
policies and procedures, and to ask why and how the department does what it does.
Along the way, knowing how technology can support changes in operations i vital. The
new system has the capability to change the work-flow. In streamlining compensation,
for example, it could be proposed that the line manager have direct access to
performance information and merit increases. Can the system give the manager access
to this information while at the same time guarding the data files? Another example:
Since the applicant-tracking program can produce labels, will the printer handle
postcards so that the process of addressing and affixing labels can be eliminated? Not
everyone will have the resources or time to do such a project, but if its possible, then the
organization can take maximum advantage of the new system.
System Customization. Depending on the product's capability, there are several ways
to customize a new computerised system such as renaming fields, addin fields and
screens, and modifying the code tables used for data entry and calculations. The first
thing to do is talk with the users and review documentation to fully understand how the
system handles customization. The next step is to document the specific requirements.
Whether customization is not the time for guesswork. An easy way to review the
customization needs is to print the screens and review them for completeness. A more
detailed analysis method is to do a "map" of the written requirements against the
system's capabilities.
Time spent on careful planning for code tables is a critical part of customization. Their value
is multi-fold. They provide the basis for reporting and make data entry easier and more
accurate.
With these tasks accomplished and documented, the project team is ready to get the system
ready for full production.
Further, planning is done to map the journey to a successful HRIS implementation. The
planning is done of the jobs - data conversion, data entry and audit, report development,
system administration, and communication to the organization. While going through ths
process, the purpose of the project plan kept in mind: avoiding the pitfalls by identifying all
the tasks and resources needed for completion.
A Time Line: Although deadlines may change, each phase and task of the plan should
be drawn in a time line that will mitigate the effects of Murphy's Law: "Everything takes
longer than you think it will." The time line and the plan is used for weekly monitoring of
the project. Monitoring is done by discussing what happened last week, what is going on
this week, and what is expecting to do next week.
Data Conversion: When is electronic data conversion worth the effort? When the
organization has 250 or more records to enter, accurate current data is in a computer
system, and the technical resources are available. If the database is not current and
accurate, then there isnt any need to go for data conversion. As, the time and trouble
taken to define file layouts, test them and do the conversion may not be feasible.
Now, the task is to move all the electronic data from one place, or from many
places, into the new system. If files are electronic, the conversion will move
them from one system to another. The expert resources can be used to
achieve this task to avoid time consuming and frustrating errors. The plan
should include:
Determining demands and limits of each database.
Finding out the charges for conversion and file requirements if the files are
with a payroll service bureau.
Developing the data-conversion routine, usually a matter of defining the file

layout. The data-conversion utility may already be available to ease the
process.
Testing the import routine, usually with a small sample of the database for
importing to the new system. Verify the results and that the data appears in
the correct fields.
Conducting the data conversion. Review records and finish them with
supplemental data as described in data entry.
Data Entry and Audit: Planning for this task should include setting data-entry priorities,
for history records in the HRIS or a training system. An early part of the project is
determining the condition of the files. While other work is continuing, its good to assign
the task of reviewing and consolidating employee records - examination of several
sample files, and identification of what information is missing or exists in another
department. Is all the benefits data there or does the controller's office have those
records? Does payroll have the number of exemptions and other tax-related data that
your system will use? A complete, well-organized record for every employee will make a
tremendous difference in the data entry. The tasks are to
o
Review and consolidate employee records.
Enter five to 10 sample records. Select a wide range of employees so that

most of the circumstances are covered such as different job titles, salary,
departments and benefit choices.
Do data entry. Set aside two to four hours at a time when data entry can
proceed uninterrupted. DO NOT attempt to answer phones and handle other
interruptions while doing this critical task.
Print profile reports and do an audit. Most systems have a standard report
that prints the employee record. A second person should audit the records for
possible errors before going into production. It may be a nice idea to use a
report (minus performance and compensation data) to send to employees for
verification and updating.
Print and file profile reports. A print copy of the employee's record can be
placed in the file, giving access to managers who need to look at the
information. Some systems allow a manager direct network access to records
and reports for his or her department's staff.
Develop Reporting Processes: The success of the system will ultimately be

determined by the reports. Work on this task can begin early in the project even though it
is not completed until the end of the implementation. The reporting process should
include
Gathering current reports and determining the value of each.
Reviewing the vendor's standard reports and printing out samples using your
employee database.
Interviewing managers to find out what information they need and in what
format.
Getting report-writing training from the vendor.
Testing key reports.
Printing formats and sample reports for your records-management manual.
System Administration: Computer systems do not take care of themselves; someone

must be responsible and accountable for each application in the department. The
implementation plan should determine who will be using the system and what type of
privileges each person will have. Privileges refers to the type of access to activities, from
viewing data to entering data to maintaining the code tables. There are three primary
tasks in planning for system administration:
o
First, clarification of the relationships between payroll and HR for access and
system maintenance.
Then assignment of responsibilities for backup, archiving, installing

enhancements and training new users.
Third, coordination of the system administration tasks with the systems

department, decide who in HR will be the system administrator and plan for
that person's training.
Communication of Changes: What difference will the new system make to the
organization outside of HR? There will be several different audiences for the
communications - executives, line managers and other employees. The most frequent
mistake is to either not plan at all for the communications or to announce the system's
benefits too soon and set up expectations long before they can be met. Steps in the
communication plan are to
o
Identify the impact of the system on different groups.
Define any information or participation that may be needed such as verifying

data or responding to a survey.
Let people know how the work is progressing through an employee newsletter
or other publication.
Describe of the changes and benefits after they are implemented, giving
specific examples.
On implementation of the plan, its monitoring is done with the time line. This will show how
the system is developed efficiently week by week, task by task.
4. Software Development Life Cycle (SDLC)

The System Development Life Cycle is the process of developing information systems
through investigation, analysis, design, implementation, and maintenance. The System
Development Life Cycle (SDLC) is also known as Information Systems Development or
Application Development.
System Development Life Cycle involves a number of steps. Each phase within the overall
cycle may be made up of several steps.
Approach
Feasibility Study
Software Requirement Specification
o
Database Design
User Interface (Form) Design
Report Design
Software Development
o
Database Tables Creating Master Tables
User Interfaces Form development
Reports
Testing
Documentation
User Training
Implementation
Implementation
User Training
Documentation
Testing
Software Development
Software Design
S/W Requirement Specification
Feasibility Study
5. Feasibility Study
5.1 Feasibility Study
The main objective of feasibility study activity is to determine whether it would be feasible to
develop the product. The feasibility study activity involves the analysis of the problem and
collection of all relevant information relation to the product such different data items which
would be input to the system.
5.2 HR Sahyak - Feasibility Study:

5.2.1
Abstract problem definition:
The objective is to develop a system that facilitates computerization for on-line and effective
control of safety functions, compensation and leave records of the employee at Durgapur
Steel Plant (DSP), Durgapur.
This system is an extension to a "Human Resource Information System (HRIS)" developed
by RDCIS, SAIL for Durgapur Steel Plant.
The system, basically, deals with areas not considered in HRIS, such as, employees; safety
related functions, leave record and management of gate pass and statutory requirements of
Contract Labour Cell (CLC).
5.2.2
Formulation of the different solution strategies
The required objective of a system that facilitates computerization for on-line and effective
control of safety functions, compensation and leave records of the employee at Durgapur
Steel Plant (DSP), Durgapur - can be achieved by
just providing the extension to the previous Information System by making the additions
to the already developed system-in-use at Durgapur Steel Plant (DSP).
forming a new project that works with the previous one, sharing the required information.
The additional demand is accomplished with a new software development project for
"Computerization of leave records, contract labour cell and safety department at DSP".
5.2.3
Analysis of alternative solution strategies
The new required system is more of an extension to a "Human Resource Information
System (HRIS)". As the HRIS project was undertaken by the RDCIS, so the additional
demand to develop the extension to the already developed system is taken in hand by the
RDCIS only. This new project is much more than just the continuous software support from
RDCIS for implementation of developed modules. So, the RDCIS proposed a new software
development project for "Computerization of leave records, contract labour cell and safety
department at DSP".
6. Software Requirement Specification

6.1 Software Requirement Specification
Software Requirement Specification (SRC) is a systematic organization of requirements.
SRS specifies all the requirements in an informal form.
SRS documents the following aspects of a system:
Functional Requirements
Functional requirements deal with the functionalities required from the system. A
system can be considered as performing a set of functions. It is an identification of
high-level function requirements of the system. High-level requirements involve
accepting some data as input and transforming it to the required output.
Non-Functional Requirements
Non-functional requirements deal with the characteristics of the system that cannot
be expressed as functions.
6.2 Functional Requirements

Identification of high-level functional requirements of System
6.2.1
Functional Requirement #1: Safety function
Description: Covers details about the accident occurred within the plant
premises:
Input:
Details of incidence
Details of persons affected in accident
Details of machine/equipment affected
Safety department keeps record of all accidents occurred

within the plant premise. Standard reporting format for
accident is followed in all the plants of SAIL. Based on this
data many analyses are carried out for MIS purpose.
For analysis purpose the accident related information has

been standardized. The Accident information will be based on
the standardized codes developed. The information stored
includes employee, contractor or visitor.
The standardized information is:

o
Accident Category
Accident Cause
Unsafe Condition
Unsafe Act
Geographic Location of Accident
Person Category
Injury Nature
Body Part Injured
Equipment Type involved in Accident
Details about an accident
Output:
Processing:
6.2.2
Functional Requirement #2: Leave Module
Description: Management of employee leave record
Leave module covers the following:

Leave Rule
Leave limitation as per leave rule
Entry & Validation of Leave Record (Leave Consumption)
Display of balance leave account
Display of attendance data
Printing of various leave order
Employees of DSP go for different kind of leave. The leave

can be divided in two major categories Leave Type and
Basic Leave Type. Leave type is the nomenclature used in
organizational personal policy manual and consists of basic
leave types. Basic leave types are accounted in salary
payment.
The detail of the leave types is enclosed.
The line managers have authority to sanction leave of an

employee. On the approval, information goes to personnel
department where from the leave order is issued. Depending
upon the leave rule that governs the employee fixed days of
particular leave is credited to the employee at the beginning
of calendar year.
At the end of calendar year some of the leaves are carried

forward and some of them lapse. EL & HPL are the example
of leave to be carried forward. The accounting of leaves to be
carried forward in the next calendar year is done as per
personal policy.
Input:
Output:
Processing:
At DSP Time Office and C&IT Department are already doing this task under the gamut of
Payroll System. However, the personal department does not have on-line access to this.
Similarly, Personal Department asks for the relevant document from employee for grant of
IOW leave; though the unfit period information is available with Safety Engineering.
Note: The detail of leave follows:
Basic Leave Type
Code
Description
CL
Casual Leave
EL
Earn Leave
FL
Festival Leave
EOL
Extra Ordinary Leave
HPL
Half Pay Leave
SABL
Sabbatical Leave
COML
Commuted Leave
TRL
Transit Leave
MATL
Maternity Leave
QL
Quarantine Leave
SCL
Special Casual Leave
SDL
Special Disability Leave
SL
Study Leave
LND
Leave not due
Leave Type
Code
Description
Personal Leave
Study Leave
Sabbatical Leave
Sick/Ill Leave
Maternity Leave
Baby care Leave
LTC/LLTC Leave
Sports & Other Leave
Injury on Works
6.2.3
Functional Requirement #3: Compensation Module
Description: Personnel department will operate this module centrally. The
data created will be linked with accident information. The prerequisite for implementation of this module is available of
Up-to-date full employee database
Up-to-date accident information
The software will compute the compensation amount to be

paid based on:
o
Compensation Act Rule
Compensation Earning Loss Table
DSP was keen to capture some more data related to

employee's accident. Injury to employee is reported through
"Reported injury on Work" form at the time of accident, filled
by the authorized person from the department where
accident takes place and is sent immediately along with the
injured person to the OHS Centre/Main Hospital. The medical
officer after duly filling the "Injury Certificate" sends the
information to Safety Engineering department and the
concerned department. Depending upon the type of injury the
employee may proceed on special leave for recovery. It is
known as Injured On Works leave (IOW). During the period
employee is paid full remuneration and his seniority is
maintained. On recovery from injury the employee needs a
fitness certificate to be issued from OHS Centre/Main
Hospital. On production of the same he may resume his duty.
Employee or his nominee (in case of fatal accident) is entitled

to claim for the compensation for the injury resulting in
permanent earning capacity loss of the employee. Five
different agencies of DSP is involved till the final payment of
the compensation:
Concerned Department
Safety Engineering Department
Medical Board
Finance Department
Personnel Department
The employee submits application to the personnel

department to initiate the process. Personnel department is
the main agency to co-ordinate the entire activity as per rules
and regulations. The department furnishes the details of the
accident and employees injured there in. Safety Engineering
Department conforms the same. A medical board is
constituted to access the loss of earning capacity. Finance
department provides details of last 12 months salary of the
employee for computation of average salary used for
computation of compensation amount to be paid. Also
finance department makes the final payment of the
compensation amount on receipt of order from personnel
department.
Compensation amount to be paid to the employee is

computed based on the guidelines from Compensation Act,
1923. It includes the factor based on age, minimum amount
to be paid as per Act and percentage of loss of permanent
earning capacity.
Input:
Output:
Processing:
Safety Functions
Efficient
Manpower
Utilization
Accident detail
Maintenance
Leave
Compensation
Leave Records
Management
6.2.4
HR Sahayak: System Concept for Safety Function and Compensation
6.2.5
HR Sahayak: System Concept for Safety Function and Compensation
6.2.6
Functional Hierarchy Diagram Depicts Menu Structure
6.3 Non-functional Requirements

Functional requirements are associated with specific functions, tasks or behaviours the
system must support, while non-functional requirements are constraints on various attributes
of these functions or tasks. In terms of the quality characteristics for evaluation, the
functional requirements address the quality characteristic of functionality while the other
quality characteristics are concerned with various kinds of non-functional requirements. Nonfunctional requirements are stated in terms of constraints on the results of tasks, which are
given as functional requirements (e.g., constraints on the speed or efficiency of a given
task). The non-functional requirements can be think as being adverbially related to tasks or
functional requirements: how fast, how efficiently, how safely, etc., is a particular task carried
out by a particular system?
Identification of non-functional requirements
Portability, Reliability, Maintainability Correctablity & Adaptability, reusability,

testability and correctness
6.3.1
Portability
A portability requirement is a developer-oriented quality requirement that specifies a required
amount of portability. Portability is a quality factor that is defined for the present project - as
the ease with which the System can be moved from one organizational, hardware, or
software environment to another.
The typical objectives of a portability requirement for the program are to:
Ensure that the application or component can be easily and quickly ported to
specified new environments if and when necessary.
Minimize porting costs and schedules.
6.3.2
Reliability
A reliability requirement is a developer-oriented quality requirement that specifies a required
amount of reliability
For the present application, reliability is a quality factor that is defined as the degree to which
system operates without failure under given conditions during a given time period.
The typical objectives of Maintainability Requirement for The system are:
Ensure that system will function properly for long periods without failure.
Thereby minimize any unintentional disruptions in operation (i.e., unscheduled

downtime).
6.3.3
Maintainability
A maintainability requirement is a developer-oriented quality requirement that specifies a
required amount of maintainability
For the present application, maintainability is a quality factor that is defined as the degree to
which something can be maintained while in use.
The typical objectives of Maintainability Requirement for The system are:
Ensure that minor defects in the application or component are easy to correct.
Ensure that minor enhancements to the application or component are relatively easy
to implement.
Minimize maintenance costs.
Minimize maintenance organization staffing needs (e.g., to free up maintenance

programmers for new development).
Different types of maintainability requirements for The system:
Correctability Requirements (corrective maintenance), which is restricted to fixing

defects while system is in use.
o
It is concerned with the ease to which minor defects can be corrected

between major releases of the system (i.e., while the thing with defects is in
use).
Ensure that minor defects in the application or component can be easily and
quickly:
Identified,
Understood, and
Corrected.
Minimize defect correction costs.
Extensibility Requirements (adaptive maintenance), which is restricted to minor

enhancements of the application.
o
It is concerned with the degree to which system can be enhanced in the

future to meet changing requirements or goals.
The system should be developed in such a way that it enables architects and
designers to partially base their choices on foreseen enhancements.
The design should ensure that future enhancements to an application or

component can be easily and quickly to implemented.
Minimize enhancement costs.
It should be extendible. The application is made to parse HTML text documents to

create the Lexicon. It should be designed in such a way that the parsing to XML
documents etc. can be possible just by attaching an additional module for extracting
lexicon data from a particular format.
To provide ease to maintain The system and components the application should provide:
Modular software
Information hiding implementation
Well-defined interfaces
Object-orientation and component-based development.
Well documented - Complete and current documentation.
Adherence to project conventions.
6.3.4
Reusability
A reusability requirement is a developer-oriented quality requirement that specifies a
required amount of reusability. For the present application, reusability is a quality factor that
is defined as the ease of and ability for all or part of the system can be reused for purposes
other than the one for which it is being developed.
The typical objectives of Reusability Requirement for the current application are:
Increase current reuse by developing the applications

documentation by using existing reusable work products.
Increase future reuse by developing the applications components and

documentation that shall be potentially reusable for purposes other than originally
intended (e.g., as part of future system applications).
components
and
6.3.5
Testability
A testability requirement is a developer-oriented quality requirement that specifies a required
amount of testability. For the present application, testability is a quality factor that is defined
as the degree to which system application facilitates the creation and execution of
successful tests (i.e., tests that cause failures due to underlying defects).
The typical objectives of testability Requirement for the current application are:
Ensure that the system is feasible to test.
Can be tested effectively and efficiently.
Minimize the cost of testing.
Maximize the defects that can be found by testing.
6.3.6
Correctness
A correctness requirement is a developer-oriented quality requirement that specifies a
required amount of correctness. For the present application, correctness is a quality factor
that is defined as the degree to which the working of system and its outputs shall be free
from defects once the work product is delivered.
The typical objectives of correctness requirement for the current application are:
Ensure that the work product does not contain an unacceptable number of latent
defects.
Ensure that all numerical data returned or stored by an application or component are
sufficiently accurate, precise, and up to date.
The system is required to abide by the correctness requirements such that it meets the
associated users needs and expectations, regardless of whether or not these needs and
expectations are specified as requirements.
7. Software Design
7.1 Database Design

Database design is the process of producing a detailed data model of a database. This
model contains all the needed physical design choices and physical storage parameters
needed to generate DDL which can then be used to create a database. A fully attributed data
model contains detailed attributes for each entity.
7.1.1
Entity-relationship model
The Entity-Relationship model is a data model for high-level descriptions of conceptual data
models, and it provides a graphical notation for representing such data models in the form of
entity-relationship diagrams. Such data models are typically used in the first stage of
information-system design; they are used, for example, to describe information needs and/or
the type of information that is to be stored in the database during the requirements analysis.
The modelling technique, however, can be used to describe any ontology (i.e. an overview
and classification of used terms and their relationships) for a certain universe of discourse
(i.e. area of interest). In the case of the design of an information system that is based on a
database, the conceptual data model is, at a later stage (usually called logical design),
mapped to a logical data model, such as the relational model; this in turn is mapped to a
physical model during physical design. Sometimes, both of these phases are referred to as
"physical design".
7.1.2
Reduction of an E-R Schema to Tables
A database that is represented as an E-R database schema can be represented as a
collection of tables. For each entity set and for each relationship set in the database, there
is a unique table.
Both E-R model and the relational-database model are abstract, logical representations of
real-world enterprises. Because two models employ similar design principles, it is possible
to convert an E-R design into a relational design.
The set of Tables turned out to be:
Accident_Det
Compensation
Leave
Leave_Det
Leave_Encash
Leave_Limit
Comp_Act
Accident
Comp_Earn_Loss_Table
Location
Machine
Leave_Int_Holiday
Comp_Factor
Per_Category
Acc_Category
Body_Part
Leave_Type
Ignorant
Injury_Nature
Cause
Basic_Leave_Type
Leave_Rule
Unsafe_Condition
Unsafe_Act
Equipment
7.1.3
Tables - Internals
ACCIDENT_IDSLNONAMEAGE
SHIFTALIVEADDR1ADDR2AD
DR3CITYSTATEUNFIT_FROM
UNFIT_TOMEDICAL_COSTWA
GE_COSTINDIRECT_COSTMA
N_HR_LOSTPLNODEPT_CODE
SUB_DEPT_CODEWORK_AREA
_CODEGRADE_CODEDESG_CO
DEDSG_SUFFIXINJ_NATURE
_CODEBODY_PART_CODEPER
_CAT_CODEACC_CAT_CODEU
NSAFE_ACT_CODEIGNORANT
_CODEREMARK
ACCIDENT_IDSLNONAMEAGE
SHIFTALIVEADDR1ADDR2AD
DR3CITYSTATEUNFIT_FROM
UNFIT_TOMEDICAL_COSTWA
GE_COSTINDIRECT_COSTMA
N_HR_LOSTPLNODEPT_CODE
SUB_DEPT_CODEWORK_AREA
_CODEGRADE_CODEDESG_CO
DEDSG_SUFFIXINJ_NATURE
_CODEBODY_PART_CODEPER
_CAT_CODEACC_CAT_CODEU
NSAFE_ACT_CODEIGNORANT
_CODEREMARK
ACCIDENT_IDACCIDENT_DE
T_SLNOAPPLLICATION_DAT
EPLNOAGEFACTORAVG_SALA
RYEARN_LOSSDSCRORD_NOO
RD_DATECOMP_AMOUNTWAGE
_UPPER_LIMITCOMP_ACT_V
ALID_FROMCOMP_ELT_VALI
D_FROMCOMP_ELT_SLNOCOM
P_FACT_VALID_FROMFATAL
_PCTFATAL_LOW_AMOUNTNO
N_FATAL_PCTNON_FATAL_L
OW_AMOUNT
PLNOLEAVE_TYPE_CODEDAT
E_FROMDATE_TOSTATION_L
EAVESTATUSREASONADDR1A
DDR2ADDR3CITYSTATEPHON
EORD_NOORD_DATE
PLNOTYPE_CODELEAVE_DAT
E_FROMSLNODATE_FROMDAT
E_TOBASIC_LEAVE_CODENO
_OF_DAYSENTERY_ONFLAGA
CCIDENT_IDACCIDENT_SLN
OFIN_XFR_DATEFIN_XFR_S
TATUS
PLNOBASIC_LEAVE_CODESL
NOENCASH_MTH_YRNO_OF_D
AYSAMOUNTENTRY_ONFLAGS
TATUSFIN_XFR_DATEFIN_X
FR_STATUS
BASIC_LEAVE_CODELEAVE_
RULE_CODEVALID_FROMVAL
ID_TONO_OF_DAYSREQ_PR_
DAYS_YRBONUS_DAYS_YRDA
YS_LIMIT_YR
VALID_FROMVALID_TOFATA
L_PCTFATAL_LOWNON_FATA
L_PCTNON_FATAL_LOW_AMO
UNTWAGE_UPPER_LIMITACT
_DSCR
IDINCIDENT_DATEDSCRLOC
ATION_CODECAUSE_CODEUN
SAFE_CON_CODESAFETY_AC
TION
SLNOVALID_FROMVALID_TO
DSCREARN_LOSS_PCTDISPL
AY_SLNO
CODEDSCRDEPT_CODESUB_D
EPT_CODEWORK_AREA_CODE
ACCIDENT_IDSLNOEQUIPTM
ENT_CODEMC_HR_LOSTREMA
RKS
PLNOLEAVE_TYPE_CODELEA
VE_DATE_FROMHOLIDAY_DA
TEOFF_HOLIDAY
AGEVALID_FROMVALID_TOF
ACTOR
CODEDSCRPER_CAT_TYPE
CODEDSCRAC_CATEGORY_TY
PE
CODEDSCRBODY_PART
CODEDSCRNO_OF_DAYS
CODEDSCR
CODEDSCR
CODEDSCR
CODEDSCR
CODEDSCR
CODEDSCR
CODEDSCR
CODEDSCREQUIP_TYPE
7.1.4
Module wise Table Association
Module wise the functions carried out at DSP is mentioned earlier, while studying functional
requirements. Here for each module function wise associated table is shown. Also table wise
field level detail is enclosed. This gives the complete idea about the information that will be
captured in the developed system for any function.
Safety Module
The person from Safety Engineering Department will be responsible for operating functions
under this module. Safety department will enter the data for accident and unfit duration
(IOW) in case of employees accident. Building of up-to-date full employee database is
mandatory for implementation of this module. Function wise associated tables are:
S.No.
Function / Description
Associated Table for field detail
Standardization Modules
1. Accident Category
ACC_CATEGORY
2. Accident Cause
CAUSE
3. Unsafe Condition
UNSAFE_CONDITION
4. Unsafe Act
UNSAFE_ACT
5. Geographic Location of Accident
LOCATION
6. Person Category
PER_CATEGORY
7. Injury Nature
INJURY_NATURE
8. Body Part Injured
BODY_PART
9. Equipment Type
EQUIPMENT
10. Ignorance
IGNORANT
Transaction Modules
1. Details of incidence
ACCIDENT
2. Details of persons affected
ACCIDENT_DET
3. Details of machine/equipment
MACHINE_DET
Employee is entitled to get compensation for the permanent earning loss capacity as per
rules and regulation. Developed system will incorporate this function to be operated by
personnel department. Safety department will not operate the compensation paid for
accident. However, they will have access to view the same.
+ACCIDENT_IDSLNONAMEAGES
HIFTALIVEADDR1ADDR2ADDR3
CITYSTATEUNFIT_FROMUNFIT
_TOMEDICAL_COSTWAGE_COST
INDIRECT_COSTMAN_HR_LOST
+PLNO+DEPT_CODE+SUB_DEPT
_CODE+WORK_AREA_CODE+GRA
DE_CODE+DESG_CODEDSG_SUF
FIX+INJ_NATURE_CODE+BODY
_PART_CODE+PER_CAT_CODE+
ACC_CAT_CODE+UNSAFE_ACT_
CODE+IGNORANT_CODEREMARK
IDINCIDENT_DATEDSCRLOCAT
ION_CODE+CAUSE_CODE+UNSA
FE_CON_CODE+SAFETY_ACTIO
N
Compensation Module
Compensation payment includes five agencies as mentioned above. However the developed
software will have interaction with Safety Engineering Department & Personnel Department.
The medical board could not be thought of due to non-availability of network connectivity.
Other departments were discarded, as implementation is difficult when too many persons
are involved for the operation.
Personnel department will operate this module centrally. The data created will be linked with
accident information. The pre-requisite for implementation of this module is availability of
Up-to-date full employee database
Up-to-date accident information
The software will compute the compensation amount to be paid based on the logic given by
DSP. But one can change this amount manually if required. The formula used for
compensation amount is given below:
Compensation Amount*
Compensation Factor X Percentage of permanent

earning capacity loss X Percentage to be paid (Fatal /
Non-Fatal as per Compensation Act) X Avg salary of
employee or maximum wage limit as per Compensation
Act
* Computed Compensation Amount should be more than the minimum amount as specified
in Compensation Act (Fatal/Non-Fatal) otherwise minimum amount as per Act will be the
Compensation Amount
SlNo
1. Compensation Act Detail
COMP_ACT
2. Factor for working out compensation
COMP_FACTOR
3. Permanent earning capacity loss (%)
COMP_EARN_LOSS_TABLE
Transaction Modules
1. Compensation Payment
COMPENSATION
In the computerized system POs will operate IOW leave that is linked to accident. The
system will insure that such type of leave is linked to appropriate accident. Thus IOW leave
operation will depend upon the up-to-date accident information.
+ACCIDENT_ID+ACCIDENT_DE
T_SLNOAPPLLICATION_DATE+
PLNO+AGE
+COMP_FACT_VALID_FROMFAC
TORAVG_SALARYEARN_LOSSDS
CRORD_NOORD_DATECOMP_AMO
UNTWAGE_UPPER_LIMIT+COMP
_ACT_VALID_FROM+COMP_ELT
_VALID_FROM+COMP_ELT_SLN
OFATAL_PCTFATAL_LOW_AMOU
NTNON_FATAL_PCTNON_FATAL
_LOW_AMOUNT
Leave Management Module
The computerized leave record system will not only provide easy access of available
information at C&IT but will help personnel department to take out the leave orders. The
personnel officer will operate this module. The software will validate the leave related data
entry based on employee wise balanced leave account in Payroll System at C&IT. This
module will have on-line access of leave and attendance data of payroll system. The
software under this module will deal with
Leave Rule
Leave limitation as per leave rule
Entry & Validation of Leave Record (Leave Consumption)
Display of balance leave account
Display of attendance data
Printing of various leave order
The module will not have interface for employees attendance and will exclude the software
for leave accumulation and leave accounting. These functions are already operational at
C&IT department as mentioned earlier. The functional existing system will be coupled with
this module.
RDCIS discussed with C&IT and personnel department regarding the access of leave and
attendance data in Payroll System. It was agreed upon that C&IT would provide read only
data access in the following structure:
SlNo
Field Name
Field Type
Remarks
1. att_tkt_no
NUMBER(5)
Ticket No
2. att_duty
NUMBER(2)
No. of duty days
3. att_off
NUMBER(2)
No. of off days
4. att_fl
NUMBER(2)
No. of Festival Leave days
5. att_el
NUMBER(2)
No. of Earn Leave days
6. att_cl
NUMBER(2)
No. of Casual Leave days
7. att_comm.
NUMBER(2)
No. of Commuted Leave days
8. att_hpl
NUMBER(2)
No. of Half Pay Leave days
9. att_ofpl
NUMBER(2)
No. of Other Full Pay Leave days
10. att_eol
NUMBER(2)
No. of Extra Ordinary Leave days
11. att_abs
NUMBER(2)
No. of Absent days
12. att_mm
NUMBER(2)
Month
13. att_yyyy
NUMBER(4)
Year
Software developed by RDCIS will use this information for leave record data entry validation.
RDCIS will create necessary view once read access is granted by C&IT. Function wise
associated tables are:
SlNo
1.
Leave Rule
LEAVE_RULE
2.
Basic Leave Type
BASIC_LEAVE_TYPE
3.
Leave Type
LEAVE_TYPE
4.
Leave limitation as per Rule
LEAVE_LIMIT
5.
Attendance / Leave from Pay Bills
ATT_MASTER_PB
Transaction Modules
1.
Leave availed/consumed
LEAVE
2.
Details/composition of leave
LEAVE_DET
3.
Intervening Holidays
LEAVE_INT_HOLIDAY
Leave Encashment
LEAVE_ENCASH
7.2 User Interface (Form) Design

According to The Dictionary of Computing, User Interface Design refers to the aspects of
hardware or software which can be seen (or heard or otherwise perceived) by the human
user, and the commands and mechanisms the user uses to control its operation and input
data.
While User Interface Design is often used for computer systems, it is the part of any system
exposed to a user. In a computer system, the user typically interacts with an operating
system or with application software such as a spreadsheet or a word processor. With
systems, the user interacts using menus, icons, keystrokes, mouse clicks, and similar
capabilities.
In this project, a set of 21 possible User-computer interaction points are identified. So, the
possible set of User Interfaces can be:
Accident Detail
Employees Leave Encashment
Safety Master
o
Accident Category
Body Parts
Cause
Equipment
Ignorant
Injury Nature
Location
Person Category
Unsafe Act
Unsafe Condition
Leave Limitation (No. of Days)
LLTC Block Years
Basic Leave Type
Leave Type
Relation
Leave Rules
Workmen's Compensation Factor
Injuries Resulting in Permanent Loss of Earning Capacity
Workmen's Compensation Act Detail
7.2.1
User Interface Design: Accident Detail
Accident Detail
Incidence
ID
Date
Loc
Department
Cause
Unsafe
Con
Detail
Safe Act
S
Dp
Area
Accident Detail
S. No.
Acc
Category
Dept
Earn Loss
Shift
Sub Dept
Per
Category
W
Area
PIN
no
Body Part
Name
Injury Nature
Compensation amount & dt. Man hr lost
Man hr cost
Age
Grd
Unsafe Act
Wage Cost
Desg Suff.
Ignor
e
unfit
frm
Ind Cost
Add
Unfit
to
Alive
7.2.2
User Interface Design: Employees Leave Encashment
Employees Leave Encashment

Pl No.
SI No.
First Name
Encash
Dt
(mmyyyy)
No.
of
Days
Last Name
Amoun
t
Entry
on
Paid/
cancell
ed
Leave Type
Lv..
A/C
Flag
Fin Xfr
Date
Fin Xfr
Status
7.2.3
User Interface Design: Safety Master - Accident Category
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Accident Category
Code
Description
Acc Cat Type
7.2.4
User Interface Design: Safety Master - Body Parts
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Body Parts
Code
Description
Body Part
7.2.5
User Interface Design: Safety Master - Cause
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Cause
Code
Description
7.2.6
User Interface Design: Safety Master - Equipment
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Equipment
Code
Description
Equipment Type
7.2.7
User Interface Design: Safety Master - Ignorant
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Ignorant
Code
Description
7.2.8
User Interface Design: Safety Master - Injury Nature
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Injury Nature
Code
Description
7.2.9
User Interface Design: Safety Master - Location
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Location
Code
Description
Dept
Sub-Dept
Work Area
7.2.10
User Interface Design: Safety Master - Person Category
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Person Category
Code
Description
Per Cat. Type
7.2.11
User Interface Design: Safety Master - Unsafe Act
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Unsafe Act
Code
Description
7.2.12
User Interface Design: Safety Master - Unsafe Condition
Safety Master
ACC
Body
Cause
Equip
Ignore
Injury
Loc
Per
Act
Cond.
Unsafe Condition
Code
Description
7.2.13
User Interface Design: Leave Limitation (No. of Days)
Leave Limitation (No. of

Days)
Leave
Code
Leave Rule
Code
Dscr
Validity
From
To
Max Leave
Accum (Days)
Req
Pr
Days/
Yr
Bonus
Days/
Yr
Max
Leave
Accum/Yr
7.2.14
User Interface Design: LLTC Block Years
LLTC Block Years

Block
Standard
7.2.15
User Interface Design: Basic Leave Type
Basic Leave Type

Code
Description
7.2.16
User Interface Design: Leave Type
Leave Type
Code
Description
Permitted Max Days
7.2.17
User Interface Design: Relation
Relation
Code
7.2.18
User Interface Design: Leave Rules
Leave Rules
Code
Description
7.2.19
User Interface Design: Workmen's Compensation Factor
Workmens Compensation Factor

Valid from Date
Valid to Date
Age Years
Compensation Factor
7.2.20
UI Design: Injuries Resulting in Permanent Loss of Earning Capacity
Injuries Resulting in Permanent Loss of Earning Capacity

SI No
Description of Injury
% Earning
Loss
Disp.
Order
Valid from
Date
Valid
to Date
7.2.21
User Interface Design: Workmen's Compensation Act Detail
Workmens Compensation Act Detail

Fatal Accident
Valid
From
Valid To
Pay
%
Min.
Amount
Non - Fatal
Accident
Pay
Min.
%
Amount
Wage (Max)
Description
8. Software Development
In consultation with concerned person from DSP, RDCIS would carry out the application
software development following the standard approach of SSAD (System Analysis And
Design). The software developed will be open in nature allowing dynamic additions and
modifications of standardization module by the users themselves. The hard coding will be
avoided and wherever required a look-up table will be provided for easy data entry. RDCIS
would handover the ERD (Entity Relation Diagram) and entire source code to DSP on
completion of the project. The software will be developed for client-server environment
having Oracle 9i as back end database on UNIX platform, while Developer 6i as front-end
tool on Windows platform.
Salient features of software
Single integrated database
Data sharing with security
Interfaces for users having different role.
Data capturing at source
Data integration & validation
No duplication of data. Close coupling with existing HRIS and leave module of
Payroll System.
8.1 Data Population

DSP shall be responsible for extraction or building of master data. The master data will be
collected or extracted into a flat file by DSP. RDCIS will extend help to load data into Oracle
9i database from the prepared flat files. The software will be tested against population of
some of the real life accident data both fatal and non-fatal cases with and without
compensation payment. However, entire data loading is not in the purview of the project.
DSP will be responsible for the implementation of the computerized system while RDCIS will
extend all kind of software support during the implementation.
8.2 Hardware & System Software

The hardware and associated software items other than the application software will be
provided by DSP. The installation of hardware, system software including Oracle RDBMS,
front-end oracle tools (Developer 6i) will be done by DSP. Similarly responsibility of network
design, network components procurement and their installation will lie with DSP. RDCIS will
be responsible for installation of application software at the client machine and making it
operational at node.
9. Coding
9.1 SQL Code

CODES FOR MASTER TABLE STANDARDISATION
CREATE TABLE ACC_CATEGORY (CODE VARCHAR2(3) NOT NULL,
DSCR VARCHAR2(50) NOT NULL,
ACC_CAT_TYPE VARCHAR2(1) NOT NULL)
CREATE TABLE BODY_PART (CODE VARCHAR2(3) NOT NULL,
BODY_PART VARCHAR2(1) NOT NULL)
CREATE TABLE CAUSE (CODE VARCHAR2(3) NOT NULL,
DSCR VARCHAR2(50) NOT NULL)
CREATE TABLE EQUIPMENT (CODE VARCHAR2(3) NOT NULL,
EQUIP_TYPE VARCHAR2(1) NOT NULL)
CREATE TABLE IGNORANT (CODE VARCHAR2(3) NOT NULL,
CREATE TABLE INJURY_NATURE (CODE VARCHAR2(3) NOT NULL,
CREATE TABLE LOCATION (CODE VARCHAR2(5) NOT NULL,
DEPT_CODE NUMBER(4) NOT NULL,
SUB_DEPT_CODE NUMBER(3) NOT NULL,
WORK_AREA_CODE VARCHAR2(10) NOT NULL)
CREATE TABLE PER_CATEGORY (CODE VARCHAR2(3) NOT NULL,
PER_CAT_TYPE VARCHAR2(1) NOT NULL)
CREATE TABLE UNSAFE_CONDITION (CODE VARCHAR2(3) NOT NULL,
CREATE TABLE UNSAFE_ACT (CODE VARCHAR2(3) NOT NULL,
CREATE TABLE ACCIDENT (ID NUMBER(6) NOT NULL,

INCIDENT_DATE DATE NOT NULL,
LOCATION_CODE VARCHAR2(5) NOT NULL,
CAUSE_CODE VARCHAR2(3) NOT NULL,
UNSAFE_CON_CODE VARCHAR2(3) NOT NULL,
SAFETY_ACTION VARCHAR2(200))
CREATE TABLE ACCIDENT_DET (ACCIDENT_ID NUMBER(6) NOT NULL,
SLNO NUMBER(3) NOT NULL,
NAME VARCHAR2(50) NOT NULL,
AGE NUMBER(3) NOT NULL,
SHIFT VARCHAR2(1) NOT NULL,
ALIVE VARCHAR2(1) NOT NULL,
ADDR1 VARCHAR2(50),
ADDR2 VARCHAR2(50),
ADDR3 VARCHAR2(50),
CITY VARCHAR2(20),
STATE VARCHAR2(20),
UNFIT_FROM DATE,
UNFIT_TO DATE,
MEDICAL_COST NUMBER(14,2),
WAGE_COST NUMBER(14,2),
INDIRECT_COST NUMBER(14,2),
MAN_HR_LOST NUMBER(5),
PLNO NUMBER(6),
DEPT_CODE NUMBER(4),
SUB_DEPT_CODE NUMBER(3),
WORK_AREA_CODE VARCHAR2(10),
GRADE_CODE VARCHAR2(5),
DESG_CODE VARCHAR2(10),
DESG_SUFFIX VARCHAR2(10),
INJ_NATURE_CODE VARCHAR2(3) NOT NULL,
BODY_PART_CODE VARCHAR2(3) NOT NULL,
PER_CAT_CODE VARCHAR2(3) NOT NULL,
ACC_CAT_CODE VARCHAR2(3) NOT NULL,
UNSAFE_ACT_CODE VARCHAR2(3) NOT NULL,
IGNORANT_CODE VARCHAR2(3) NOT NULL,
REMARKS VARCHAR2(100))
CREATE TABLE MACHINE_DET (ACCIDENT_ID NUMBER(6) NOT NULL,
EQUIPMENT_CODE VARCHAR2(3) NOT NULL,
MC_HR_LOST NUMBER(5,1) NOT NULL,
REMARKS VARCHAR2(100))
CREATE TABLE COMP_ACT (VALID_FROM DATE NOT NULL,
VALID_TO DATE,
FATAL_PCT NUMBER(5,2) NOT NULL,
FATAL_LOW_AMOUNT NUMBER(14,2) NOT NULL,
NON_FATAL_PCT NUMBER(5,2) NOT NULL,
NON_FATAL_LOW_AMOUNT NUMBER(14,2) NOT NULL,
WAGE_UPPER_LIMIT NUMBER(14,2) NOT NULL,
ACT_DSCR VARCHAR2(300))
CREATE TABLE COMP_EARN_LOSS_TABLE (VALID_FROM DATE NOT NULL,
VALID_TO DATE,
SLNO VARCHAR2(7) NOT NULL,
EARN_LOSS_PCT NUMBER(5,2) NOT NULL,
DISPLAY_SLNO NUMBER(6) NOT NULL)
CREATE TABLE COMP_FACTOR (VALID_FROM DATE NOT NULL,
VALID_TO DATE,
AGE NUMBER(4,1) NOT NULL,
FACTOR NUMBER(7,3) NOT NULL)
CREATE TABLE COMPENSATION (ACCIDENT_ID NUMBER(6) NOT NULL,
ACCIDENT_DET_SLNO NUMBER(3) NOT NULL,
APPLICATION_DATE DATE NOT NULL,
PLNO NUMBER(6) NOT NULL,
AGE NUMBER(4,1) NOT NULL,
FACTOR NUMBER(7,3) NOT NULL,
AVG_SALARY NUMBER(14,2) NOT NULL,
EARN_LOSS_PCT NUMBER(5,2) NOT NULL,
DSCR VARCHAR2(300),
ORD_NO VARCHAR2(50) NOT NULL,
ORD_DATE DATE NOT NULL,
COMP_AMOUNT NUMBER(14,2) NOT NULL,
WAGE_UPPER_LIMIT NUMBER(14,2) NOT NULL,
COMP_ACT_VALID_FROM DATE NOT NULL,
COMP_ELT_VALID_FROM DATE NOT NULL,
COMP_ELT_SLNO VARCHAR2(7) NOT NULL,
COMP_FACT_VALID_FROM DATE NOT NULL,
FATAL_PCT NUMBER(5,2),
FATAL_LOW_AMOUNT NUMBER(14,2),
NON_FATAL_PCT NUMBER(5,2),
NON_FATAL_LOW_AMOUNT NUMBER(14,2))
CREATE TABLE LEAVE_RULE (CODE NUMBER(2) NOT NULL,
CREATE TABLE BASIC_LEAVE_TYPE (CODE VARCHAR2(8) NOT NULL,
CREATE TABLE LEAVE_TYPE (CODE NUMBER(2) NOT NULL,
NO_OF_DAYS NUMBER(4))
CREATE TABLE LEAVE_LIMIT (BASIC_LEAVE_CODE VARCHAR2(8) NOT NULL,
LEAVE_RULE_CODE NUMBER(2) NOT NULL,
VALID_FROM DATE NOT NULL,
VALID_TO DATE,
NO_OF_DAYS NUMBER(4) NOT NULL,
REQ_PR_DAYS_YR NUMBER(3),
BONUS_DAYS_YR NUMBER(3),
DAYS_LIMIT_YR NUMBER(3))
CREATE TABLE LEAVE (PLNO NUMBER(6) NOT NULL,
LEAVE_TYPE_CODE NUMBER(2) NOT NULL,
DATE_FROM DATE NOT NULL,
DATE_TO DATE NOT NULL,
STATION_LEAVE_PER VARCHAR2(1) NOT NULL,
STATUS VARCHAR2(1) NOT NULL,
REASON VARCHAR2(100) NOT NULL,
ADDR1 VARCHAR2(50),
ADDR2 VARCHAR2(50),
ADDR3 VARCHAR2(50),
CITY VARCHAR2(20),
STATE VARCHAR2(20),
PHONE VARCHAR2(20),
ORD_NO VARCHAR2(50),
ORD_DATE DATE)
CREATE TABLE LEAVE_DET
(PLNO NUMBER(6) NOT NULL,
TYPE_CODE NUMBER(2) NOT NULL,
LEAVE_DATE_FROM DATE NOT NULL,
DATE_FROM DATE NOT NULL,
DATE_TO DATE NOT NULL,
BASIC_LEAVE_CODE VARCHAR2(8) NOT NULL,
NO_OF_DAYS NUMBER(5,1) NOT NULL,
ENTERY_ON DATE NOT NULL,
FLAG VARCHAR2(1) NOT NULL,
ACCIDENT_ID NUMBER(6),
ACCIDENT_SLNO NUMBER(3),
FIN_XFR_DATE DATE,
FIN_XFR_STATUS VARCHAR2(1))
CREATE TABLE LEAVE_INT_HOLIDAY (PLNO NUMBER(6) NOT NULL,
LEAVE_TYPE_CODE NUMBER(2) NOT NULL,
LEAVE_DATE_FROM DATE NOT NULL,
HOLIDAY_DATE DATE NOT NULL,
OFF_HOLIDAY VARCHAR2(1) NOT NULL)
CREATE TABLE LEAVE_ENCASH (PLNO NUMBER(6) NOT NULL,
BASIC_LEAVE_CODE VARCHAR2(8) NOT NULL,
ENCASH_MTH_YR DATE NOT NULL,
NO_OF_DAYS NUMBER(4) NOT NULL,
AMOUNT NUMBER(14,2) NOT NULL,
ENTRY_ON DATE NOT NULL,
FLAG VARCHAR2(1) NOT NULL,
STATUS VARCHAR2(1),
FIN_XFR_DATE DATE,
FIN_XFR_STATUS VARCHAR2(1))
ALTER TABLE ACC_CATEGORY
ADD CONSTRAINT ACC_CAT_PK PRIMARY KEY (CODE)
ALTER TABLE BODY_PART
ADD CONSTRAINT BODY_PART_PK PRIMARY KEY (CODE)
ALTER TABLE CAUSE
ADD CONSTRAINT CAUSE_PK PRIMARY KEY (CODE)
ALTER TABLE EQUIPMENT
ADD CONSTRAINT EQUIPMENT_PK PRIMARY KEY (CODE)
ALTER TABLE IGNORANT
ADD CONSTRAINT IGNORANT_PK PRIMARY KEY (CODE)
ALTER TABLE INJURY_NATURE
ADD CONSTRAINT INJ_NATURE_PK PRIMARY KEY (CODE)
ALTER TABLE LOCATION
ADD CONSTRAINT LOCATION_PK PRIMARY KEY (CODE)
ALTER TABLE LOCATION
ADD CONSTRAINT LOCATION_WORK_AREA_FK FOREIGN KEY (DEPT_CODE, SUB_DEPT_CODE, WORK_AREA_CODE)
REFERENCES WORK_AREA (DEPT_CODE, SUB_DEPT_CODE, CODE)
ALTER TABLE PER_CATEGORY
ADD CONSTRAINT PER_CAT_PK PRIMARY KEY (CODE)
ALTER TABLE UNSAFE_ACT
ADD CONSTRAINT UNSAFE_ACT_PK PRIMARY KEY (CODE)
ALTER TABLE UNSAFE_CONDITION
ADD CONSTRAINT UNSAFE_CON_PK PRIMARY KEY (CODE)
ALTER TABLE ACCIDENT
ADD CONSTRAINT ACCIDENT_PK PRIMARY KEY (ID)
ALTER TABLE ACCIDENT
ADD CONSTRAINT ACCIDENT_LOCATION_FK FOREIGN KEY (LOCATION_CODE) REFERENCES LOCATION (CODE)
ADD CONSTRAINT ACCIDENT_CAUSE_FK FOREIGN KEY (CAUSE_CODE) REFERENCES CAUSE (CODE)
ADD
CONSTRAINT
ACCIDENT_UNSAFE_CON_FK
FOREIGN
KEY
(UNSAFE_CON_CODE)
REFERENCES
UNSAFE_CONDITION (CODE)
ALTER TABLE ACCIDENT_DET
ADD CONSTRAINT ACIDENTDET_PK PRIMARY KEY (ACCIDENT_ID, SLNO)
ALTER TABLE ACCIDENT_DET
ADD CONSTRAINT ACIDENTDET_ACC_CAT_FK FOREIGN KEY
(ACC_CAT_CODE) REFERENCES ACC_CATEGORY
(CODE)
ADD CONSTRAINT ACIDENTDET_UNSAFE_ACT_FK FOREIGN KEY (UNSAFE_ACT_CODE) REFERENCES UNSAFE_ACT
(CODE)
ADD CONSTRAINT ACIDENTDET_IGNORANT_FK FOREIGN KEY (IGNORANT_CODE) REFERENCES IGNORANT (CODE)
ADD CONSTRAINT ACIDENTDET_ACCIDENT_FK FOREIGN KEY (ACCIDENT_ID) REFERENCES ACCIDENT (ID)
ADD CONSTRAINT ACIDENTDET_EMPLOYEE_FK FOREIGN KEY (PLNO) REFERENCES EMPLOYEE (PLNO)
ADD CONSTRAINT ACIDENTDET_WORK_AREA_FK FOREIGN KEY (DEPT_CODE, SUB_DEPT_CODE, WORK_AREA_CODE)
REFERENCES WORK_AREA (DEPT_CODE, SUB_DEPT_CODE, CODE)
ADD CONSTRAINT ACIDENTDET_GRADE_FK FOREIGN KEY (GRADE_CODE) REFERENCES GRADE (CODE)
ADD CONSTRAINT ACIDENTDET_DESG_FK FOREIGN KEY (DESG_CODE) REFERENCES DESG (CODE)
ADD
CONSTRAINT
ACIDENTDET_INJ_NATURE_FK
FOREIGN
KEY
(INJ_NATURE_CODE)
REFERENCES
INJURY_NATURE (CODE)
ADD CONSTRAINT ACIDENTDET_BODY_PART_FK FOREIGN KEY
(BODY_PART_CODE) REFERENCES BODY_PART
(CODE)
ADD CONSTRAINT ACIDENTDET_PER_CAT_FK FOREIGN KEY
(PER_CAT_CODE) REFERENCES PER_CATEGORY
(CODE)
ALTER TABLE MACHINE_DET
ADD CONSTRAINT MACHINEDET_PK PRIMARY KEY (ACCIDENT_ID, SLNO)
ALTER TABLE MACHINE_DET
ADD CONSTRAINT MACHINEDET_ACCIDENT_FK FOREIGN KEY (ACCIDENT_ID) REFERENCES ACCIDENT (ID)
ADD CONSTRAINT MACHINEDET_EQUIPMENT_FK FOREIGN KEY
(EQUIPMENT_CODE) REFERENCES EQUIPMENT
(CODE)
ALTER TABLE LEAVE_RULE
ADD CONSTRAINT LEAVE_RULE_PK PRIMARY KEY (CODE)
ALTER TABLE LEAVE_RULE
ADD CONSTRAINT LEAVE_RULE_UK UNIQUE (DSCR)
ALTER TABLE BASIC_LEAVE_TYPE
ADD CONSTRAINT BASIC_LEAV_PK PRIMARY KEY (CODE)
ALTER TABLE LEAVE_TYPE
ADD CONSTRAINT LEAVE_TYPE_PK PRIMARY KEY (CODE)
ALTER TABLE LEAVE_LIMIT
ADD CONSTRAINT LEAVE_LMT_PK PRIMARY KEY (BASIC_LEAVE_CODE, LEAVE_RULE_CODE, VALID_FROM)
ALTER TABLE LEAVE_LIMIT
ADD CONSTRAINT LEAVE_LMT_LEAVE_RULE_FK FOREIGN KEY
(LEAVE_RULE_CODE) REFERENCES LEAVE_RULE
(CODE)
ADD
CONSTRAINT
LEAVE_LMT_BASIC_LEAV_FK
FOREIGN
KEY
(BASIC_LEAVE_CODE)
REFERENCES
BASIC_LEAVE_TYPE (CODE)
ALTER TABLE LEAVE
ADD CONSTRAINT LEAVE_PK PRIMARY KEY (PLNO, LEAVE_TYPE_CODE, DATE_FROM)
ALTER TABLE LEAVE
ADD CONSTRAINT LEAVE_LEAVE_TYPE_FK FOREIGN KEY (LEAVE_TYPE_CODE) REFERENCES LEAVE_TYPE (CODE)
ADD CONSTRAINT LEAVE_EMPLOYEE_FK FOREIGN KEY (PLNO) REFERENCES EMPLOYEE (PLNO)
ALTER TABLE LEAVE_DET
ADD CONSTRAINT LEAVE_DET_PK PRIMARY KEY (PLNO, TYPE_CODE, LEAVE_DATE_FROM, SLNO)
ALTER TABLE LEAVE_DET
ADD CONSTRAINT LEAVE_DET_ACIDENTDET_FK FOREIGN KEY
(ACCIDENT_ID, ACCIDENT_SLNO) REFERENCES
ACCIDENT_DET (ACCIDENT_ID, SLNO)
ADD CONSTRAINT LEAVE_DET_LEAVE_FK FOREIGN KEY (PLNO, TYPE_CODE, LEAVE_DATE_FROM) REFERENCES
LEAVE (PLNO, LEAVE_TYPE_CODE, DATE_FROM)
ADD
CONSTRAINT
LEAVE_DET_BASIC_LEAV_FK
FOREIGN
KEY
(BASIC_LEAVE_CODE)
REFERENCES
ALTER TABLE LEAVE_INT_HOLIDAY
ADD CONSTRAINT LEAVEHOLI_PK PRIMARY KEY
(PLNO, LEAVE_TYPE_CODE, LEAVE_DATE_FROM,
HOLIDAY_DATE)
ALTER TABLE LEAVE_INT_HOLIDAY
ADD CONSTRAINT LEAVEHOLI_LEAVE_FK FOREIGN KEY
(PLNO, LEAVE_TYPE_CODE, LEAVE_DATE_FROM)
REFERENCES LEAVE (PLNO, LEAVE_TYPE_CODE, DATE_FROM)
ALTER TABLE LEAVE_ENCASH
ADD CONSTRAINT LEAVE_CASH_PK PRIMARY KEY (PLNO, BASIC_LEAVE_CODE, SLNO)
ALTER TABLE LEAVE_ENCASH
ADD
CONSTRAINT
LEAVE_CASH_BASIC_LEAV_FK
FOREIGN
KEY
(BASIC_LEAVE_CODE)
REFERENCES
ADD CONSTRAINT LEAVE_CASH_EMPLOYEE_FK FOREIGN KEY (PLNO) REFERENCES EMPLOYEE (PLNO)
ALTER TABLE COMP_ACT
ADD CONSTRAINT COMP_ACT_PK PRIMARY KEY (VALID_FROM)
ALTER TABLE COMP_FACTOR
ADD CONSTRAINT COMP_FACT_PK PRIMARY KEY (VALID_FROM, AGE)
ALTER TABLE COMP_EARN_LOSS_TABLE
ADD CONSTRAINT COMP_ELT_PK PRIMARY KEY (VALID_FROM, SLNO)
ALTER TABLE COMPENSATION
ADD CONSTRAINT COMP_PK PRIMARY KEY (ACCIDENT_DET_SLNO, ACCIDENT_ID)
ALTER TABLE COMPENSATION
ADD CONSTRAINT COMP_ACIDENTDET_FK FOREIGN KEY
(ACCIDENT_ID, ACCIDENT_DET_SLNO) REFERENCES
ACCIDENT_DET (ACCIDENT_ID, SLNO)
ADD CONSTRAINT
COMP_EMPLOYEE_FK FOREIGN KEY (PLNO) REFERENCES EMPLOYEE (PLNO)
ADD CONSTRAINT COMP_COMP_ACT_FK FOREIGN KEY
(COMP_ACT_VALID_FROM) REFERENCES COMP_ACT
(VALID_FROM)
ADD CONSTRAINT COMP_COMP_ELT_FK FOREIGN KEY (COMP_ELT_SLNO, COMP_ELT_VALID_FROM) REFERENCES
COMP_EARN_LOSS_TABLE (SLNO, VALID_FROM)
ADD CONSTRAINT
COMP_COMP_FACT_FK FOREIGN KEY
(COMP_FACT_VALID_FROM, AGE) REFERENCES COMP_FACTOR
(VALID_FROM, AGE)
CREATE INDEX LOCATION_WORK_AREA_FK_I ON LOCATION (DEPT_CODE, SUB_DEPT_CODE, WORK_AREA_CODE)
CREATE INDEX ACCIDENT_CAUSE_FK_I ON ACCIDENT (CAUSE_CODE)
CREATE INDEX ACCIDENT_LOCATION_FK_I ON ACCIDENT (LOCATION_CODE)
CREATE INDEX ACCIDENT_UNSAFE_CON_FK_I ON ACCIDENT (UNSAFE_CON_CODE)
CREATE INDEX ACIDENTDET_ACC_CAT_FK_I ON ACCIDENT_DET (ACC_CAT_CODE)
CREATE INDEX ACIDENTDET_BODY_PART_FK_I ON ACCIDENT_DET (BODY_PART_CODE)
CREATE INDEX ACIDENTDET_IGNORANT_FK_I ON ACCIDENT_DET (IGNORANT_CODE)
CREATE INDEX ACIDENTDET_INJ_NATURE_FK_I ON ACCIDENT_DET (INJ_NATURE_CODE)
CREATE
INDEX
ACCIDENTDET_WORK_AREA_FK_I
ON
ACCIDENT_DET
(DEPT_CODE,
SUB_DEPT_CODE,
WORK_AREA_CODE)
CREATE INDEX ACIDENTDET_PER_CAT_FK_I ON ACCIDENT_DET (PER_CAT_CODE)
CREATE INDEX ACIDENTDET_UNSAFE_ACT_FK_I ON ACCIDENT_DET (UNSAFE_ACT_CODE)
CREATE INDEX ACIDENTDET_ACCIDENT_FK_I ON ACCIDENT_DET (ACCIDENT_ID)
CREATE INDEX ACIDENTDET_DESG_FK_I ON ACCIDENT_DET (DESG_CODE)
CREATE INDEX ACIDENTDET_EMPLOYEE_FK_I ON ACCIDENT_DET (PLNO)
CREATE INDEX ACIDENTDET_GRADE_FK_I ON ACCIDENT_DET (GRADE_CODE)
CREATE INDEX MACHINEDET_ACCIDENT_FK_I ON MACHINE_DET (ACCIDENT_ID)
CREATE INDEX MACHINEDET_EQUIPMENT_FK_I ON MACHINE_DET (EQUIPMENT_CODE)
CREATE INDEX COMP_COMP_ACT_FK_I ON COMPENSATION (COMP_ACT_VALID_FROM)
CREATE INDEX COMP_COMP_ELT_FK_I ON COMPENSATION (COMP_ELT_VALID_FROM, COMP_ELT_SLNO)
CREATE INDEX COMP_COMP_FACT_FK_I ON COMPENSATION (COMP_FACT_VALID_FROM, AGE)
CREATE INDEX COMP_ACIDENTDET_FK_I ON COMPENSATION (ACCIDENT_ID, ACCIDENT_DET_SLNO)
CREATE INDEX COMP_EMPLOYEE_FK_I ON COMPENSATION (PLNO)
CREATE INDEX LEAVE_LMT_BASIC_LEAV_FK_I ON LEAVE_LIMIT (BASIC_LEAVE_CODE)
CREATE INDEX LEAVE_LMT_LEAVE_RULE_FK_I ON LEAVE_LIMIT (LEAVE_RULE_CODE)
CREATE INDEX LEAVE_LEAVE_TYPE_FK_I ON LEAVE (LEAVE_TYPE_CODE)
CREATE INDEX LEAVE_EMPLOYEE_FK_I ON LEAVE (PLNO)
CREATE INDEX LEAVE_DET_ACCIDENTDET_FK_I ON LEAVE_DET (ACCIDENT_ID, ACCIDENT_SLNO)
CREATE INDEX LEAVE_DET_LEAVE_FK_I ON LEAVE_DET (PLNO, TYPE_CODE, LEAVE_DATE_FROM)
CREATE INDEX LEAVE_DET_BASIC_LEAV_FK_I ON LEAVE_DET (BASIC_LEAVE_CODE)
CREATE
INDEX
LEAVEHOLI_LEAVE_FK_I
ON
LEAVE_INT_HOLIDAY
(PLNO,
LEAVE_TYPE_CODE,
LEAVE_DATE_FROM)
CREATE INDEX LEAVE_CASH_BASIC_LEAV_FK_I ON LEAVE_ENCASH (BASIC_LEAVE_CODE)
CREATE INDEX LEAVE_CASH_EMPLOYEE_FK_I ON LEAVE_ENCASH (PLNO)
9.2 PL SQL Code

Trigger(FORM
COMP_FACTOR)
WHEN_NEW-FORM_INSTANCE
DECLARE
v_granted_role VARCHAR2(5);
fm_id
FormModule;
bk_id
Block;
bk_name VARCHAR2(40);
BEGIN
Set_Window_property(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE);
Set_Window_property(FORMS_MDI_WINDOW, TITLE, 'Computerised Human Resource
System');
Set_Window_property('WINDOW1', WINDOW_STATE, MAXIMIZE);
/*
IF USER <> 'HRIS' THEN
BEGIN
SELECT granted_role
INTO v_granted_role
FROM hris_user
WHERE user_id = USER;
IF v_granted_role NOT IN ('ADMIN') THEN
fm_id := Find_Form(:System.Current_Form);
bk_name := Get_Form_Property(fm_id, FIRST_BLOCK);
WHILE bk_name IS NOT NULL LOOP
bk_id := Find_Block(bk_name);
SET_BLOCK_PROPERTY(bk_id, INSERT_ALLOWED, PROPERTY_FALSE);
SET_BLOCK_PROPERTY(bk_id, DELETE_ALLOWED, PROPERTY_FALSE);
SET_BLOCK_PROPERTY(bk_id, UPDATE_ALLOWED, PROPERTY_FALSE);
SET_BLOCK_PROPERTY(bk_id, QUERY_ALLOWED, PROPERTY_TRUE);
bk_name := Get_Block_Property(bk_id, NEXTBLOCK);
END LOOP;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN
proc_msg('ERROR : Oracle ID is not VALID HRIS user...');
RAISE FORM_TRIGGER_FAILURE;
END;
END IF;
*/
END;
Information
2.WHEM_WINDOW_RESIZED
DECLARE
v_state VARCHAR2(50);
BEGIN
v_state := GET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE);
IF v_state IN ('NORMAL', 'MINIMIZE') THEN
SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE);
END IF;
END;
3.KEY_ENTQRY
CLEAR_RECORD;
ENTER_QUERY;
4.KEY_EXEQRY
IF :SYSTEM.MODE <> 'ENTER-QUERY' THEN
CLEAR_RECORD;
EXECUTE_QUERY;
ELSE
EXECUTE_QUERY;
END IF;
5.ON_MESSAGE
proc_msg(MESSAGE_TEXT || ' (' || MESSAGE_TYPE || '-' ||
TO_CHAR(MESSAGE_CODE) || ')');
6.ON-ERROR
proc_msg(ERROR_TEXT || ' (' || ERROR_TYPE || '-' ||
TO_CHAR(ERROR_CODE) || ')');
1.DATABLOCK
COMP_FACTOR
TRIGGERS
KEY-DELREC
--- Begin default enforce data integrity constraint COMP_FACT_PK section
-declare
cursor primary_cur is select 'x' from HRIS.COMPENSATION
where COMP_FACT_VALID_FROM = :COMP_FACTOR.VALID_FROM and AGE = :COMP_FACTOR.AGE;
primary_dummy char(1);
begin
if ( ( :COMP_FACTOR.VALID_FROM is not null ) and ( :COMP_FACTOR.AGE is not null ) ) then
open primary_cur;
fetch primary_cur into primary_dummy;
if ( primary_cur%found ) then
proc_msg('ERROR : Cannot delete. Matching records exist in COMPENSATION Table.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end if;
end;
delete_record;
--- End default enforce data integrity constraint COMP_FACT_PK section
-2.WHEM-VALIDATE-RECORD
if (:system.record_status <> 'QUERY') then
if (:comp_factor.valid_to is not null and
:comp_factor.valid_from > :comp_factor.valid_to) then
proc_msg('ERROR : Valid From Date should be earlier than Valid To Date.');
end if;
end if;
3..PRE-INSERT
declare
cursor primary_cur is
select 'x'
from comp_factor
where age = :comp_factor.age
and valid_to is null;
v_primary_dummy
char(1);
begin
open primary_cur;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Fill up the Valid To Date for old record.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
from comp_factor
where age = :comp_factor.age
and (:comp_factor.valid_from between valid_from and valid_to
or nvl(:comp_factor.valid_to, :comp_factor.valid_from) between valid_from and
valid_to
or valid_from between :comp_factor.valid_from and nvl(:comp_factor.valid_to,
:comp_factor.valid_from)
or valid_to between :comp_factor.valid_from and nvl(:comp_factor.valid_to,
:comp_factor.valid_from));
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
end if;
close primary_cur;
end;
4.PRE-UPDATE
eclare
select 'x'
from comp_factor
where valid_from <> :comp_factor.valid_from
and age = :comp_factor.age
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Fill up the Valid To Date for old record.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
from comp_factor
where valid_from <> :comp_factor.valid_from
and age = :comp_factor.age
and (:comp_factor.valid_from between valid_from and valid_to
or nvl(:comp_factor.valid_to, :comp_factor.valid_from) between valid_from and
valid_to
or valid_from between :comp_factor.valid_from and nvl(:comp_factor.valid_to,
:comp_factor.valid_from)
or valid_to between :comp_factor.valid_from and nvl(:comp_factor.valid_to,
:comp_factor.valid_from));
v_primary_dummy
char(1);
begin
open primary_cur;
close primary_cur;
end if;
close primary_cur;
end;
3.ITEM
VALIDFROM
TRIGGER
WHEN-VALIDATE-ITEM
--- Begin default enforce data integrity constraint SYS_C0057800 section
-if not( :COMP_FACTOR.VALID_FROM IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
end if;
--- End default enforce data integrity constraint SYS_C0057800 section
-4.AGE
TRIGGER
WHEN-VALIDATE-ITEM
-if not( :COMP_FACTOR.AGE IS NOT NULL ) then
end if;
-5.FACTOR
TRIGEER
WHEN-VALIDATE-ITEM
-- Begin default enforce data integrity constraint SYS_C0057802 section
-if not( :COMP_FACTOR.FACTOR IS NOT NULL ) then
end if;
-FORM
COMP_EARN_LOSS_TABLE
TRIGGER
WHEN-NEW-FORM-INSTANCE
DECLARE
fm_id
FormModule;
bk_id
Block;
BEGIN
System');
/*
BEGIN
SELECT granted_role
INTO v_granted_role
FROM hris_user
END LOOP;
END IF;
EXCEPTION
END;
END IF;
*/
END;
Information
2.WHEN-WINDOERESIZED
DECLARE
BEGIN
END IF;
END;
3.KEY-ENTQRY
CLEAR_RECORD;
ENTER_QUERY;
4.
KEY-EXEQRY
CLEAR_RECORD;
EXECUTE_QUERY;
ELSE
EXECUTE_QUERY;
END IF;
5.ON-MESSAGE
5.ON-ERROR
DATABLOCK
COMP_EARNLOSS_TABLR
TRIGGER
1.KEY-DELREC
--- Begin default enforce data integrity constraint COMP_ELT_PK section
-declare
where COMP_ELT_VALID_FROM = :COMP_EARN_LOSS_TABLE.VALID_FROM and COMP_ELT_SLNO =
:COMP_EARN_LOSS_TABLE.SLNO;
begin
if ( ( :COMP_EARN_LOSS_TABLE.VALID_FROM is not null ) and ( :COMP_EARN_LOSS_TABLE.SLNO is
not null ) ) then
open primary_cur;
proc_msg('ERROR : Cannot delete. Detail records exist in COMPENSATION Table.');
close primary_cur;
end if;
close primary_cur;
end if;
end;
delete_record;
--- End default enforce data integrity constraint COMP_ELT_PK section
-2.WHEN-VALIDATE-RECORD
if (:comp_earn_loss_table.valid_to is not null and
:comp_earn_loss_table.valid_from > :comp_earn_loss_table.valid_to) then
proc_msg('ERROR : Valid From Date should be earlier than Valid To');
end if;
end if;
3.PRE-INSERT
declare
select 'x'
from comp_earn_loss_table
where valid_to is null;
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Fill Valid To Date of previous Earning Loss Table.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
where :comp_earn_loss_table.valid_from between valid_from and valid_to
or nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from) between
valid_from and valid_to
or
valid_from
between
:comp_earn_loss_table.valid_from
and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from)
or
valid_to
between
and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from);
v_primary_dummy
char(1);
begin
open primary_cur;
close primary_cur;
end if;
close primary_cur;
end;
4.PRE-UPDATE
declare
select 'x'
where valid_from <> :comp_earn_loss_table.valid_from
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Fill Valid To Date of previous Earning Loss Table.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
where valid_from <> :comp_earn_loss_table.valid_from
and ( :comp_earn_loss_table.valid_from between valid_from and valid_to
or nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from) between
valid_from and valid_to
or
valid_from
between
and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from)
or
valid_to
between
and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from));
v_primary_dummy
char(1);
begin
open primary_cur;
close primary_cur;
end if;
close primary_cur;
end;
ITEM
TRIGEER
1.SLNO.
WHEN-VALIDATE-ITEM
-if not( :COMP_EARN_LOSS_TABLE.SLNO IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field
end if;
-2.DSCR
WHEN-VALIDATE-ITEM
-if not( :COMP_EARN_LOSS_TABLE.DSCR IS NOT NULL ) then
end if;
-3.EARN-LOSS-PCT
WHEN-VALIDATE-ITEM
-if not( :COMP_EARN_LOSS_TABLE.EARN_LOSS_PCT IS NOT NULL ) then
end if;
-4.DISPLAI-SLNO
WHEN-VALIDATE-ITEM
-if not( :COMP_EARN_LOSS_TABLE.DISPLAY_SLNO IS NOT NULL ) then
end if;
-5.VALID-FROM
WHEN-VALIDATE-ITEM
-if not( :COMP_EARN_LOSS_TABLE.VALID_FROM IS NOT NULL ) then
end if;
--
);
);
);
);
);
COMP_ACT _FMB
FORM
COMP_ACT
TRIGGER
WHEN-NEW-FORM-INSTANCE
DECLARE
fm_id
FormModule;
bk_id
Block;
BEGIN
System');
/*
BEGIN
SELECT granted_role
INTO v_granted_role
FROM hris_user
END LOOP;
END IF;
EXCEPTION
END;
END IF;
*/
END;
2.WHEN-WINDOW-RESIZED
DECLARE
BEGIN
END IF;
END;
3.KEY-ENTQRY
CLEAR_RECORD;
ENTER_QUERY;
4.KEY-EXEQRY
Information

CLEAR_RECORD;
EXECUTE_QUERY;
ELSE
EXECUTE_QUERY;
END IF;
5.ON-MESSAGE
6.0N_ERROR
DATABLOCK
COMP_ACT
TRIGEER
1.KEY_DELREC
--- Begin default enforce data integrity constraint COMP_ACT_PK section
-declare
where COMP_ACT_VALID_FROM = :COMP_ACT.VALID_FROM;
begin
if ( ( :COMP_ACT.VALID_FROM is not null ) ) then
open primary_cur;
proc_msg('ERROR : Cannot delete. Detail records exist in COMPENSATION Table.');
close primary_cur;
end if;
close primary_cur;
end if;
end;
delete_record;
--- End default enforce data integrity constraint COMP_ACT_PK section
-2.WHEN-VALIDATE-RECORD
if (:comp_act.valid_to is not null and
:comp_act.valid_from > :comp_act.valid_to) then
proc_msg('ERROR : Valid From Date should be earlier than Valid To');
end if;
end if;
3.PRE-INSERT
declare
select 'x'
from comp_act
where valid_to is null;
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Fill Valid To Date of previous Act.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
from comp_act
where :comp_act.valid_from between valid_from and valid_to
or nvl(:comp_act.valid_to, :comp_act.valid_from) between valid_from and valid_to
or valid_from between :comp_act.valid_from and nvl(:comp_act.valid_to,
:comp_act.valid_from)
or
valid_to
between
:comp_act.valid_from
and
nvl(:comp_act.valid_to,
:comp_act.valid_from);
v_primary_dummy
char(1);
begin
open primary_cur;
close primary_cur;
end if;
close primary_cur;
end;
3.PRE-UPDATE
declare
select 'x'
from comp_act
where valid_from <> :comp_act.valid_from
v_primary_dummy
char(1);
begin
open primary_cur;
proc_msg('ERROR : Fill Valid To Date of previous Act.');
close primary_cur;
end if;
close primary_cur;
end;
declare
select 'x'
from comp_act
where valid_from <> :comp_act.valid_from
and ( :comp_act.valid_from between valid_from and valid_to
or nvl(:comp_act.valid_to, :comp_act.valid_from) between valid_from and valid_to
or valid_from between :comp_act.valid_from and nvl(:comp_act.valid_to,
:comp_act.valid_from)
or valid_to between :comp_act.valid_from and nvl(:comp_act.valid_to,
:comp_act.valid_from));
v_primary_dummy
char(1);
begin
open primary_cur;
close primary_cur;
end if;
close primary_cur;
end;
ITEM
1.VALID_FROM
TRIGGER
WHEN_VALIDATE_ITEM
-if not( :COMP_ACT.VALID_FROM IS NOT NULL ) then
end if;
-2.FATAL_PCT
WHEN_VALIDATE_ITEM
-if not( :COMP_ACT.FATAL_PCT IS NOT NULL ) then
end if;
-3.FATAL_LOE_AMOUNT
WHEN_VALIDATE_ITEM
-if not( :COMP_ACT.FATAL_LOW_AMOUNT IS NOT NULL ) then
end if;
-4.NON_FATAL_PCT
WHEN_VALIDATE_ITEM
-if not( :COMP_ACT.NON_FATAL_PCT IS NOT NULL ) then
end if;
-5.
NON_FATAL_LOW_AMOUNT
WHEN_VALIDATE_ITEM
);
);
);
);

-if not( :COMP_ACT.NON_FATAL_LOW_AMOUNT IS NOT NULL ) then
end if;
-6.WAGE_UPPER_LIMIT
WHEN_VALIDATE_ITEM
-if not( :COMP_ACT.WAGE_UPPER_LIMIT IS NOT NULL ) then
end if;
--
10. Testing
Software testing is a process used to identify the correctness, completeness and quality of
developed computer software. Actually, testing can never establish the correctness of
computer software, as this can only done by formal verification. It can only find defects, not
prove that there are none. There are a number of different testing approaches that are used
to do this ranging from the most informal ad hoc testing, to formally specified and controlled
methods such as automated testing.
The quality of the application can and normally does vary widely from system to system but
some of the common quality attributes include reliability, stability, portability, maintainability
and usability.
In general, software engineers distinguish software faults and software failures. In case of a
failure, the software does not do what the user expects. A fault is a programming error that
may or may not actually manifest as a failure. A fault can also be described as an error in the
correctness of the semantic of a computer program. A fault will become a failure if the exact
computation conditions are met, one of them being that the faulty portion of computer
software executes on the CPU. A fault can also turn into a failure when the software is ported
to a different hardware platform or a different compiler, or when the software gets extended.
Software testing may be viewed as a sub-field of software quality assurance but typically
exists independently.
Regardless of the methods used or level of formality involved the desired result of testing is
a level of confidence in the software so that the developers are confident that the software
has an acceptable defect rate. What constitutes an acceptable defect rate depends on the
nature of the software. An arcade video game designed to simulate flying an airplane would
presumably have a much higher tolerance for defects than software used to control an actual
airliner. (What is a defect rate?)
A problem with software testing is that the number of defects in a software product can be
very large, and the number of configurations of the product larger still. Bugs that occur
infrequently are difficult to find in testing. A rule of thumb is that a system that is expected to
function without faults for a certain length of time must have already been tested for at least
that length of time. This has severe consequences for projects to write long-lived reliable
software.
A common practice of software testing is that it is performed by an independent group of
testers after finishing the software product and before it is shipped to the customer. This
practice often results in the testing phase being used as project buffer to compensate for
project delays. Another practice is to start software testing at the same moment the project
starts and it is a continuous process until the project finishes.
It is commonly believed that the earlier a defect is found the cheaper it is to fix it.
10.1.1
Alpha testing
In software development, testing is usually required before release to the general public. Inhouse developers often test the software in what is known as 'alpha' testing which is often
performed under a debugger or with hardware-assisted debugging to catch bugs quickly.
This technique is known as white box or glass box testing.
It can then be handed over to testing staff for additional inspection in an environment similar
to how it was intended to be used. This technique is known as black box testing. This is
often known as the second stage of alpha testing.
10.1.2
Beta testing
Following that, limited public tests known as beta-versions are often released to groups of
people so that further testing can ensure the product has few faults or bugs. Sometimes,
beta-versions are made available to the open public to increase the feedback field to a
maximal number of future users.
10.1.3
Gamma testing
There are companies that introduced the so-called gamma tests, which means featurecompleted, but the software did not run through all the in-house quality checks. Some cynics
refer to software release as "gamma testing".
10.2 Black box testing

Black box testing or functional testing is used in computer programming, software
engineering and software testing to check that the outputs of a program, given certain inputs,
conform to the functional specification of the program.
The term black box indicates that the internal implementation of the program being executed
is not examined by the tester. For this reason black box testing is not normally carried out by
the programmer. In most real-world engineering firms, one group does design work while a
separate group does the testing.
A complementary technique, white box testing or structural testing, uses information about
the structure of the program to check that it performs correctly.
10.2.1
Equivalence partitioning
A technique in black box testing is equivalence partitioning. Equivalence partitioning is
designed to minimize the number of test cases by dividing tests in such a way that the
system is expected to act the same way for all tests of each equivalence partition. Test
inputs would be selected from each partition.
Equivalence partitions are designed so that every possible input belongs to one and only
one equivalence partition.
Disadvantages to equivalence partitions
Doesn't test every input
No guidelines for choosing inputs
Heuristic-based
10.3 White box testing

White box testing, clear box or structural testing is used in computer programming, software
engineering and software testing to check that the outputs of a program, given certain inputs,
conform to the internal design and implementation of the program.
The term white box indicates that the tester closely examines the internal implementation of
the program being tested. A complementary technique, black box testing or functional
testing, checks that the program performs to its specification without examining its internal
implementation.
10.4 Code coverage

Code coverage is a measure used in software testing. It describes the degree to which the
source code of a program has been tested. It is distinct from black box testing methods
because it looks at the code directly, rather than other measures such as software functions
or object interfaces.
Code coverage techniques were amongst the first techniques invented for systematic
software testing. There are a number of different ways of measuring code coverage, the
main ones being:
Statement Coverage - Has each line of the source code been executed and tested?
Condition Coverage - Has each evaluation point (such as a true/false decision) been
executed and tested?
Path Coverage - Has every possible route through a given part of the code been
executed and tested?
Some of the coverage criteria above are connected; for instance, path coverage implies both
condition and statement coverage. Statement coverage does not imply condition coverage,
as the code (in the C programming language) below shows:
void foo(int bar)
{
printf("this is");
if (bar < 1)
{
printf("not ");
}
printf("a positive integer");
return;
}
If the function "foo" was called with variable "bar = -1", statement coverage would be
achieved. Condition coverage, however, would not.
Full path coverage, of the type described above, is usually impractical or impossible. Any
module with a succession of n decisions in it can have up to 2n paths within it; loop
constructs can result in an infinite number of paths. Many paths may also be infeasible, in
that there is no input to the program under test that can cause that particular path to be
executed. However, there is no general-purpose algorithm for identifying infeasible paths
(because such an algorithm could be used to solve the halting problem). Techniques for
practical path coverage testing instead attempt to identify classes of code paths that differ
only in the number of loop executions, and to achieve "basis path" coverage the tester must
cover all the path classes.
Usually the source code is instrumented and run through a series of tests. The resulting
output is then analysed to see what areas of code have not been exercised, and the tests
are updated to include these areas as necessary. Combined with other code coverage
methods the aim is to develop a rigorous yet manageable set of regression tests.
Code coverage is ultimately expressed as a percentage, as in "We have tested 67% of the
code". The meaning of this depends on what form(s) of code coverage have been used, as
67% path coverage is more comprehensive than 67% statement coverage.
10.5 Software testing activities

10.5.1
Unit test
In computer programming, a unit test is a method of testing the correctness of a particular
module of source code.
The idea is to write test cases for every non-trivial function or method in the module so that
each test case is separate from the others if possible.
Benefits
The goal of unit testing is to isolate each part of the program and show that the individual
parts are correct. It provides a written contract that the piece must satisfy. This isolated
testing provides two main benefits:
Encourages change
Unit testing allows the programmer to refactor code at a later date, and make sure the
module still works correctly (regression testing). This provides the benefit of encouraging
programmers to make changes to the code since it is easy for the programmer to check if
the piece is still working properly.
Simplifies Integration
Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a
bottom-up testing style approach. By testing the parts of a program first and then testing the
sum of its parts will make integration testing easier.
Limitations
It is important to realize that unit-testing will not catch every error in the program. By
definition, it only tests the functionality of the units themselves. Therefore, it will not catch
integration errors, performance problems and any other system-wide issues. Unit testing is
only effective if it is used in conjunction with other software testing activities.
Applications
The unit testing concept is part of the Extreme Programming method of software
engineering. Unit testing is the building block to test driven development (TDD). Extreme
Programming and most other methods use unit tests to perform black box testing.
This is also known as "programmer tests".
10.5.2
Integration testing
Integration testing is the phase of software testing in which individual software modules are
combined and tested as a group. It follows unit testing and precedes system testing.
Integration testing takes as its input modules that have been checked out by unit testing,
groups them in larger aggregates, applies tests defined in an Integration test plan to those
aggregates, and delivers as its output the integrated system ready for system testing.
Purpose
The purpose of Integration testing is to verify functional, performance and reliability

requirements placed on major design items. These "design items", i.e. assemblages (or
groups of units), are exercised through their interfaces using Black box testing, success and
error cases being simulated via appropriate parameter and data inputs. Simulated usage of
shared data areas and inter-process communication is tested, individual subsystems are
exercised through their input interface. All test cases are constructed to test that all
components within assemblages interact correctly, for example, across procedure calls or
process activations.
The overall idea, is the "building block" approach in which verified assemblages are added to
a verified base which is then used to support the Integration testing of further assemblages.
System testing
System testing is the phase of software testing in which the complete system is tested. It
follows Integration testing.
11. Appendix
11.1 Appendix A: User Interface (Forms) for HR Sahyak
The User Interface for HR Sahyak application is, more of, a specification for the look and
feel of the program. The user issues commands via the UI to computer applications. For the
ease of the user of the HR Sahyak, UI is developed for providing an interface to the
application. The UI of the HR Sahyak receive information from and display information to a
user.
The User Interface for HR Sahyak is a type of computer-human interface on a computer. At
a conceptual level, a computer-human interface is a "means by which people and computers
communicate with each other". The interface HR Sahyak 's UI - directly binds the user to
the operation and functionality of the program. A good UI design removes the impediment of
communication with the program and allows the user to work directly on the problem at
hand.
11.1.1
HR Sahyak Form #1:
11.1.2
HR Sahyak Form #2:
11.1.3
HR Sahyak Form #3a:
11.1.4
HR Sahyak Form #3b:
11.1.5
HR Sahyak Form #3c:
11.1.6
HR Sahyak Form #3d:
11.1.7
HR Sahyak Form #3e:
11.1.8
HR Sahyak Form #3f:
11.1.9
HR Sahyak Form #3g:
11.1.10
HR Sahyak Form #3h:
11.1.11
HR Sahyak Form #3i:
11.1.12
HR Sahyak Form #3j:
11.1.13
HR Sahyak Form #4:
11.1.14
HR Sahyak Form #5:
11.1.15
HR Sahyak Form #6:
11.1.16
HR Sahyak Form #7:
11.1.17
HR Sahyak Form #8:
11.1.18
HR Sahyak Form #9:
11.1.19
HR Sahyak Form #10:
11.1.20
HR Sahyak Form #11:
11.1.21
HR Sahyak Form #12:
12. Conclusion
13. Bibliography
[O'Connell] Planning and setting up a new HRIS: Part 1 - Human resource

information system - Management of HR Systems by Sandra E. O'Connell, in HR
Magazine, February, 1994.
[O'Connell] Planning and setting up a new HRIS - Part 2 - Human Resource

Information System by Sandra E. O'Connell, in HR Magazine, March, 1994.
Oracle PL/SQL Programming, Third Edition by Steven Feuerstein (O'Reilly

Publication)
Oracle8i: The Complete Reference by Kevin Loney, George Koch (Oracle Press)
SQL, PL/SQL the Programming Language of Oracle by Ivan Bayross (BPB

Publications)
Oracle Designer/2000 Handbook (Oracle Series) by Paul Dr. Dorsey, Peter Koletzke
(Oracle Press)

HR Information Project Report (WWW - Students3k.com)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

HR Information Project Report (WWW - Students3k.com)

Încărcat de

Drepturi de autor:

Formate disponibile

http://students3k.

Employees Leave Record Function

Contract Labour Cell (CLC)

The system interacts with three different departments:

Effective and Efficient utilization of the existing man power.

Maintenance of accident detail, analysis and redressal activity.

Management of employee's leave records.

1.3 An Overview of DURGAPUR STEEL PLANT (DSP)

2. Background of the Project

3. Human Resource Information System

3.2 The Impact of Implementing an HRIS

preparing the organization for the new HRIS.

A good planning can be possible by following the guidelines.

3.4 Developing the plan

What has to be done?

In what order should tasks be completed?

Who i going to do it?

By what deadline? and

What is the impact of one task on the others?

Finding Ways to Improve Work Flow. Technology provides a wonderful opportunity to

Determining demands and limits of each database.

Developing the data-conversion routine, usually a matter of defining the file

Review and consolidate employee records.

Enter five to 10 sample records. Select a wide range of employees so that

Develop Reporting Processes: The success of the system will ultimately be

Gathering current reports and determining the value of each.

Getting report-writing training from the vendor.

Testing key reports.

Printing formats and sample reports for your records-management manual.

System Administration: Computer systems do not take care of themselves; someone

Then assignment of responsibilities for backup, archiving, installing

Third, coordination of the system administration tasks with the systems

Identify the impact of the system on different groups.

Define any information or participation that may be needed such as verifying

4. Software Development Life Cycle (SDLC)

User Interface (Form) Design

Database Tables Creating Master Tables

User Interfaces Form development

S/W Requirement Specification

5.2 HR Sahyak - Feasibility Study:

6. Software Requirement Specification

6.2 Functional Requirements

Details of persons affected in accident

Details of machine/equipment affected

Safety department keeps record of all accidents occurred

For analysis purpose the accident related information has

The standardized information is:

Geographic Location of Accident

Body Part Injured

Equipment Type involved in Accident

Details about an accident

Leave module covers the following:

Employees of DSP go for different kind of leave. The leave

The detail of the leave types is enclosed.

The line managers have authority to sanction leave of an

At the end of calendar year some of the leaves are carried

Extra Ordinary Leave

Half Pay Leave

Special Casual Leave

Special Disability Leave

Leave not due

Baby care Leave

Sports & Other Leave