Documente Academic
Documente Profesional
Documente Cultură
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.
1. Organizational Background
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 SAIL’s 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)
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.
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 that’s 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
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
o Database Design
o User Interface (Form) Design
o Report Design
Software Development
o Database Tables – Creating Master Tables
o User Interfaces – Form development
o Reports
Testing
Documentation
User Training
Implementation
Implementation
User Training
Documentation
Testing
Software Development
Software Design
Feasibility Study
5. Feasibility Study
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:
Leave Type
Code Description
1 Personal Leave
2 Study Leave
3 Sabbatical Leave
4 Sick/Ill Leave
5 Maternity Leave
6 Baby care Leave
7 LTC/LLTC Leave
8 Sports & Other Leave
9 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 pre-
requisite for implementation of this module is available of
o Up-to-date full employee database
o Up-to-date accident information
The software will compute the compensation amount to be
paid based on:
o Compensation Act Rule
o 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:
o Concerned Department
o Safety Engineering Department
o Medical Board
o Finance Department
o 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:
Efficient
Safety Functions Manpower
Utilization
Accident detail
Maintenance
Leave Records
Leave Compensation
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. Non-
functional 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?
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.
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.
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 application’s components and
documentation by using existing reusable work products.
Increase future reuse by developing the application’s components and
documentation that shall be potentially reusable for purposes other than originally
intended (e.g., as part of future system applications).
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
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 employee’s accident. Building of up-to-date full employee database is
mandatory for implementation of this module. Function wise associated tables are:
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:
* 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
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
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 Function / Description Associated Table for field detail
Standardization Modules
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
Employee’s Leave Encashment
Safety Master
o Accident Category
o Body Parts
o Cause
o Equipment
o Ignorant
o Injury Nature
o Location
o Person Category
o Unsafe Act
o 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 S Area
Dp
Cause Unsafe
Con
Detail Safe Act
Accident Detail
S. No. Acc Shift Per PIN Name Age Grd Desg Suff. Add
Category Category no
Dept Sub Dept W Body Part Injury Nature Unsafe Act Ignor unfit Unfit
Area e frm to
Earn Loss Compensation amount & dt. Man hr lost Man hr cost Wage Cost Ind Cost Alive
7.2.2 User Interface Design: Employee’s Leave Encashment
SI No. Encash No. Amoun Entry Paid/ Lv.. Fin Xfr Fin Xfr
Dt of t on cancell A/C Date Status
(mm- Days ed Flag
yyyy)
7.2.3 User Interface Design: Safety Master - Accident Category
Safety Master
ACC Body Cause Equip Ignore Injury Loc Per Act Cond.
Accident Category
Safety Master
ACC Body Cause Equip Ignore Injury Loc Per Act Cond.
Body Parts
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
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
Safety Master
ACC Body Cause Equip Ignore Injury Loc Per Act Cond.
Person Category
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)
Block Standard
7.2.15 User Interface Design: Basic Leave Type
Code Description
7.2.16 User Interface Design: Leave Type
Leave Type
Relation
Code
7.2.18 User Interface Design: Leave Rules
Leave Rules
Code Description
7.2.19 User Interface Design: Workmen's Compensation Factor
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.
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 Information
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;
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
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
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;
raise form_trigger_failure;
end if;
close primary_cur;
end;
declare
cursor primary_cur is
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;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
4.PRE-UPDATE
eclare
cursor primary_cur is
select 'x'
from comp_factor
where valid_from <> :comp_factor.valid_from
and 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;
raise form_trigger_failure;
end if;
close primary_cur;
end;
declare
cursor primary_cur is
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;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
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 );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057800 section
--
4.AGE
TRIGGER
WHEN-VALIDATE-ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057801 section
--
if not( :COMP_FACTOR.AGE IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057801 section
--
5.FACTOR
TRIGEER
WHEN-VALIDATE-ITEM
FORM
COMP_EARN_LOSS_TABLE
TRIGGER
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 Information
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;
2.WHEN-WINDOERESIZED
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
declare
cursor primary_cur is
select 'x'
from comp_earn_loss_table
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 :comp_earn_loss_table.valid_from and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from);
v_primary_dummy char(1);
begin
open primary_cur;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
4.PRE-UPDATE
declare
cursor primary_cur is
select 'x'
from comp_earn_loss_table
where valid_from <> :comp_earn_loss_table.valid_from
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 Valid To Date of previous Earning Loss Table.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
declare
cursor primary_cur is
select 'x'
from comp_earn_loss_table
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 :comp_earn_loss_table.valid_from and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from)
or valid_to between :comp_earn_loss_table.valid_from and
nvl(:comp_earn_loss_table.valid_to, :comp_earn_loss_table.valid_from));
v_primary_dummy char(1);
begin
open primary_cur;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
ITEM
TRIGEER
1.SLNO.
WHEN-VALIDATE-ITEM
-- Begin default enforce data integrity constraint SYS_C0057810 section
--
if not( :COMP_EARN_LOSS_TABLE.SLNO IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057810 section
--
2.DSCR
WHEN-VALIDATE-ITEM
-
-- Begin default enforce data integrity constraint SYS_C0057811 section
--
if not( :COMP_EARN_LOSS_TABLE.DSCR IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057811 section
--
3.EARN-LOSS-PCT
WHEN-VALIDATE-ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057812 section
--
if not( :COMP_EARN_LOSS_TABLE.EARN_LOSS_PCT IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057812 section
--
4.DISPLAI-SLNO
WHEN-VALIDATE-ITEM
-- Begin default enforce data integrity constraint SYS_C0057813 section
--
if not( :COMP_EARN_LOSS_TABLE.DISPLAY_SLNO IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057813 section
--
5.VALID-FROM
WHEN-VALIDATE-ITEM
-- Begin default enforce data integrity constraint SYS_C0057809 section
--
if not( :COMP_EARN_LOSS_TABLE.VALID_FROM IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057809 section
--
COMP_ACT _FMB
FORM
COMP_ACT
TRIGGER
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 Information
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;
2.WHEN-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
--
-- Begin default enforce data integrity constraint COMP_ACT_PK section
--
declare
cursor primary_cur is select 'x' from HRIS.COMPENSATION
where COMP_ACT_VALID_FROM = :COMP_ACT.VALID_FROM;
primary_dummy char(1);
begin
if ( ( :COMP_ACT.VALID_FROM is not null ) ) then
open primary_cur;
fetch primary_cur into primary_dummy;
if ( primary_cur%found ) then
proc_msg('ERROR : Cannot delete. Detail 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_ACT_PK section
--
2.WHEN-VALIDATE-RECORD
if (:system.record_status <> 'QUERY') then
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');
raise form_trigger_failure;
end if;
end if;
3.PRE-INSERT
declare
cursor primary_cur is
select 'x'
from comp_act
where 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 Valid To Date of previous Act.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
declare
cursor primary_cur is
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;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
3.PRE-UPDATE
declare
cursor primary_cur is
select 'x'
from comp_act
where valid_from <> :comp_act.valid_from
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 Valid To Date of previous Act.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
declare
cursor primary_cur is
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;
fetch primary_cur into v_primary_dummy;
if primary_cur%found then
proc_msg('ERROR : Overlapping Period. Check Valid From and Valid To Date.');
close primary_cur;
raise form_trigger_failure;
end if;
close primary_cur;
end;
ITEM
1.VALID_FROM
TRIGGER
WHEN_VALIDATE_ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057803 section
--
if not( :COMP_ACT.VALID_FROM IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057803 section
--
2.FATAL_PCT
WHEN_VALIDATE_ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057804 section
--
if not( :COMP_ACT.FATAL_PCT IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057804 section
--
3.FATAL_LOE_AMOUNT
WHEN_VALIDATE_ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057805 section
--
if not( :COMP_ACT.FATAL_LOW_AMOUNT IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057805 section
--
4.NON_FATAL_PCT
WHEN_VALIDATE_ITEM
--
-- Begin default enforce data integrity constraint SYS_C0057806 section
--
if not( :COMP_ACT.NON_FATAL_PCT IS NOT NULL ) then
message( 'WHEN-VALIDATE-ITEM trigger failed on field - ' || :system.trigger_field );
raise form_trigger_failure;
end if;
--
-- End default enforce data integrity constraint SYS_C0057806 section
--
5.
NON_FATAL_LOW_AMOUNT
WHEN_VALIDATE_ITEM
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. In-
house 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.
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