Employee Information Management System c++Eims

DESCRIPTION OF THE SYSTEM

1

EMPLOYEE INFORMATION MANAGEMENT SYSTEM

(EIMS)

In today’s world everything is being automated and driven by the technology, and

those which are not yet automated to enjoy the advantages of technology are getting

or already they are in the process of getting automated.

Here is one of the classic problems of automation. There are many organisations

which are providing support for many activities but are, managing its employee’s

information and its other information manually which has been quite burdensome. In

organisations having large number of employees, managing their data manually has

been a big problem and error prone. Also updating and modifying the changing details

of each and every employee was quite huge which was not feasible for a single person

entrusted to do it on his own.

The idea for developing a customized system, like EIMS, is to make a user friendly

software for organisations who have been managing employee records manually.

STANDARD OPERARTING FUNCTIONS (SOF)

The standard menu allows the user to operate the system with much ease and

simplicity. Following is a list of the menu items and their description.

The system supports four standard operating functions (SOF) used for managing data

efficiently. These standard functions have been described below and may be used as

and when required, singularly or in a combination, to perform specific tasks.

2

A comprehensive list of the SOF’s has been given below

1. Searching a record

2. Adding a new record

3. Deleting a record

4. Modifying a record

5. Show all records

6. Delete all records

7. Count total no. of records in the file

8. Change password

SEARCHING A RECORD:

This is one of the most widely used functions. As the name suggests this function is

simply used to fetch/find a particular record. The user may do so by using the main

menu .

Records can be searched by either entering the unique Employee ID or by Entering

the name of the Employee.

3

ADDING A NEW RECORD

The system allows the user to add a new record. The process involves simple steps

and can be executed using the main menu Screen. Users must be careful while adding

new data/records as addition should not violate the integrity rules of the records in the

file. User can simply select the option from the main menu and enter data for the new

employee .After necessary information has been typed against their respective fields

user has the choice to continue entering records for some new employees.

This completes the addition process and the system shows a message confirming the

acceptance of new data.

DELETING A RECORD

The system allows the user to delete data/records .The deletion process is a simple

one and can be done following simple steps:

The user has to select the delete record option from the main menu, enter the

employee id of the record to be deleted and then press enter. The system will show a

confirmation of deleting the record.

MODIFYING A RECORD

Modifying a record requires the user to be very careful since once modified the

previous set of data/records are overwritten, thus rendering them irretrievable.

Select the modify record option from the main menu, enter the employee id of the

record to be modified and the enter the new modified data for the employee .The

system will show a confirmation of modifying the record.

4

SHOW ALL RECORDS

Choose show all records option from the main menu and then press enter to navigate

through the records. When all records are finished the system will give a choice to

either return to the main menu or exit .

DELETE ALL RECORDS

This choice of operation is dangerous as this will delete all the records present in the

file. And once deleted the records cannot be brought back. Hence the user should be

extremely careful while executing this operation.

COUNT TOTAL NO. OF RECORDS

This choice of option can be selected from the main menu and this will show the user

the total number of records present in the file. The user can move to the main menu

for further operations or can exit the system.

CHANGE PASSWORD

This choice of operation can be selected from the main menu . This will allow the

user to change the password which is required to access EIMS. The user will have to

first enter the old password and then the new password .The system will show a

confirmation of changing the password and then the user can move to the main menu

or exit from EIMS.

The Employee Information Management System is developed keeping in mind that

any type of user can access the system. Not only have this but additional features also

been provided by the developers so as to make it user friendly as much as possible.

Following are some features, which have been focused during development of

EIMS: -

USABILITY

The catch phrase user friendliness ha becomes ubiquitous in discussions of software

products. If a program is not user friendly, it is often doomed to failure, even if the

functions that it performs are valuable. Usability is an attempt to quantify user

friendliness and can be measured in terms of four characteristics: -

5

The physical and/or intellectual skill required to learn the system

The time required to became moderately efficient in use of the system

The net increase in productivity (over the approach that the system replaces)

measured when the system is used by some one who is moderately efficient,

and

A subjective assessment (sometimes obtained a questionnaire) of users

towards the system.

Keeping in mind this kind of ease, the main emphasis is given on developing an easy

to use and understandable system.

6

CORRECTNESS

As this system is being built for managing Employee’s records therefore it should be

correct. A program must operate correctly and it should be reliable. Correctness is the

degree to which the software performs it’s required functions. The most common unit

to measure the error or defect is defects per KLOC, where a defect is defined as a

verified lack of conformance to requirements.

MAINTAINABILITY

Software maintenance accounts for much more effort than any other software

engineering activity. By maintenance of software we mean to say that to correct or to

remove the errors which are encountered by the user and to up grade the software

according to the user’s requirement or to make some changes in the software if the

user has some new requirements. In all we can say that maintainability is a software

engineering activity with which software can be corrected if an error is encountered,

adapted if its environment changes, or enhanced if the user desires a change in

requirements. This software, EIMS, which we have developed, is fully maintainable

in the sense that new features or functions can be added. Also you can upgrade the

previous functions.

SECURE

As this software deals with Records of Employees, therefore there is a need of a

security mechanism in the system. For that purpose we had added a feature of user

name and password. As the user access this software he will have to enter Username

and password. With this feature an invalid user can be denied of having access to a

system.

7

8

NEED OF THE SYSTEM

The Package is developed to help the department maintaining the employees details,

earlier where the records where maintained manually, with the help of this package

the concerned departments will be able to improve the productivity, reduce the time,

cost factors associated with the system. The automation of the system will help the

organization in proper maintenance of the record, less manpower, less man-days, less

cost, proper & accurate functioning.

The basic need for the package was to automate the whole procedure of maintaining

of employees details, earlier it was all done manually. By developing this package lot

of burden will be removed from the department, which was maintaining employees

details. It will improve the efficiency, reduce the cost, and reduce the time needed to

do the work manually. With the help of this package the past details of the officers

can be assessed and policies can be based on this details.

In brief we can say this system is required to automate the processing of employees

details, which was done manually before the development of the package. Earlier all

the information data pertaining to the employee details was maintained manually or

we can say it was on paper, hence it created a problem for the organization, how to

manage it properly. With the help of this system the organization is able to maintain

the data properly & accurately.

Why System was build…?

Earlier, data pertaining to employee details was maintained manually.

Manual system was not efficient.

Cost of maintaining data manually was bigger or huge.

Large manpower was required.

The procedure was error prone, it was not accurate.

9

Manual system was not suited for electronic exchange of data.

Solution…?

The solution for all this problem was to automate the system, automation of the

employee data maintenance would reduce the manpower, man days will result in

accurate data & above all increase the efficiency of the concerned department.

10

FEASIBILITY STUDY

11

FEASIBILITY STUDY

Many feasibility studies are disillusioning for both users and analysts. First, the study

often pre supposes that when the feasibility document is being prepared, the analyst is

in a position to evaluate solutions. Second, most studies tend to overlook the

confusion inherent in system development-the constraints and the assumed attitudes.

if the feasibility study is to serve as a decision document, it must answer three key

questions:

1. Is there a new and better way to do the job that will benefit the user?

2. What are the costs and savings of the alternative(s)?

3. What is recommended?

The most successful system projects are not necessarily the biggest or the most visible

in a business but rather those that truly meet user expectations. More projects fails

because of inflated expectation than for any other reason.

FEASIBILITY CONSIDERATIONS

The three considerations involved in the feasibility analysis: economic, technical and

behavioral.

12

ECONOMICAL FEASIBILITY

Economical analysis is the most frequently used method for evaluating the

effectiveness of the candidate system, commonly known as cost/benefit analysis. This

procedure is to determine the benefits and savings that are expected from a candidate

system and compare them with costs. If benefits outweigh costs, then the decision is

made to design and implement the system. Otherwise, further justification or

alterations in the proposed system will have to be made if it is to have a chance of

being approved. This is an ongoing effort that improves in a accuracy at each phase of

the system life cycle. Feasibility study of EMPLOYEE INFORMATION

MANAGEMENT SYSTEM states that this candidate system has more benefits than

the costs involved in it.

TECHNICAL FEASIBILITY

Technical feasibility centers on the existing computer system (hardware, software,

etc.) and to what extent it can support the proposed addition. For instance, If the

current computer is operating at 80% capacity-an arbitrary ceiling-then running

another application could overload the system or require additional hardware. This

involves financial consideration to accommodate technical enhancements. If the

budget is a serious constraint, then the project is judged not feasible.

EMPLOYEE INFORMATION MANAGEMENT SYSTEM is technically feasible

because it is memory efficient, it require less memory space. It will neither lead to

overloading nor does it require any additional hardware.

BEHAVIORAL FEASIBILITY

People are inherently resistant to change, and computers have been known to facilitate

change. An estimate has been made of how strong a reaction the user is likely to have

towards the development of a computerized system. It is common knowledge that

computer installation has something to do with turnover, transfers, retraining and

13

changes in employee job status. Therefore, it is understandable that the introduction of

a candidate system requires a special effort to educate, develop, and train the staff.

EIMS is behavioral feasible because of its user-friendly nature. It is made in a

interactive way to ease the user in using this system. A novice user with minimal

guidance can use it. Thus, training time and cost of the user is reduced. This system is

flexible to; further changes can be done easily. Data related changes can be made

easily. Thus increases the life of this system and reduces the related cost.

14

OBJECTIVE

15


(EIMS)

Objective for this system is to make user-friendly employee information managing

software, which can add, delete, modify, search Employee’s data/records.

EIMS helps in the automation of employee information like training Details, name,

employee id, training agency, department and designation, training duration etc and

hence creating a paper less environment. Modification, Addition, Deletion of the

information of the employees will not take much time as well, as it used to take

earlier.

16

HARDWARE & SOFTWARE REQUIREMENT

Hardware Requirements:

Hardware requirement are the basic need of the system or the package, which is been

developed and will be deployed upon the system, which should have these basic

components or fulfill these basic hardware needs of these package.

The following hardware is recommended for the user.

Microprocessor: PIII500 MHz.

Memory: 128 MB SDRAM DIHM

Cache Memory: 512 KBL2

Upgradeability: Processor, RAM and HDD Upgradeable

HDD: 9.1 GB Wide ultra SCSI-3 HDD

Floppy Drive: 24x CD ROM Drive (IDE)

Keyboard: 104 Keys Enhanced Keyboard

Mouse: 2 Button Scroll Mouse

Graphics: 1024x768, 256 colors non-interlaced on PCL Local Bus

Monitor: 15” SGA Color monitor

Software Requirements:

Software requirement are the basic software needs of the system or the package to

work properly & efficiently.

Operating System: Windows-98 & upper versions

17

For editing the code of the package:

Application program: Turbo c++

SYSTEM REQUIREMENT SPECIFICATION

The function and performance allocated to software as part of system engineering are

refined by establishing a complete information description, a detailed functional and

behavioral description, an indication of performance requirements and design

constraints, appropriate validation criteria, and other data pertinent to requirements.

The outlines of system requirement specification are:

Introduction:

This System Requirement Specifications Document forms the basis for the design and

development of the ”EIMS”. The purpose of this document is to define all the

processes Involved in the function of EIMS. The requirements of the software relating

to the functionality, interfaces, logical database requirements and various other aspects

of the software are also explicitly defined. The SRS document will also act as the basis

for understanding between the end-user and the designer/developer.

Information Description:

The development of this system assists in the maintenance of the information and to

fulfill the complete software requirements of the package.

Functional Description:

A processing narrative is provided for each function, design constraints are stated and

justified, performance characteristics are stated and diagram is included.

Validation and Criteria:

For successful implementation of the system we should define the performance

bounds, and expected software response. At the time of creating new entry, system

performs different types of validations like user can not overwrite the existing

information.

18

REQUIREMENT ANALYSIS

19

REQUIREMENT ANALYSIS

REQUIREMENT ANALYSIS is the first technical step in the software process. It is

at this point that a general statement of software scope is refined into a concrete

specification that becomes the foundation of all software engineering activities that

follow.

Software requirement engineering is a process of discovery, refinement, modelling

and specification. The system requirements and the role allocated to the software,

initially established by the system engineer are refined in detail. Models in the

required data, information and control flow and operational behaviour are created.

Both the developer and customer have to take an active part in software requirement

engineering. Requirement analysis is a software engineering task that bridges the gap

between the customer and the developers.

Facilitation Application Specification Techniques (FAST) was applied at the time of

requirement analysis as the developer and the customer or the user worked together as

a unit.

The success of a system depends largely on how accurately a problem is defined,

thoroughly investigated, and properly carried out through the choice of solution. User

requirement analysis and need identification are concerned with what the user needs

rather than what he/she wants. Not until the problem has been identified, defined, &

evaluated should the analyst think about solutions and whether the problem is worth

solving. This step is intended to help the user and the analyst understand the real

problem rather than its symptoms.

What kind of information do we require?

20

Before one determines where to go for information or what tools to use, the first

requirement is to figure out what information to gather. Much of the information we

need to analyse relates to the organization in general, like knowledge about the people

who run the present system-their job functions and information requirements the

relationship of their job to their existing system

For EIMS, system should be interactive & users friendly so that the training period

for users should be less & they can easily learn & use our system, because our job is

to reduce their complexity & workload not to increase it. The data related to the

employees changes frequently because of retirements, deputations, trainings and new

recruitments. So, the system should be flexible so that further changes without

affecting the current data can be done easily.

Strategies for determining information requirements

There are two key strategies or general approaches for eliciting information regarding

the user's requirements: (1) Asking, (2) Getting information from the existing

information system.

1. This strategy obtains information from users by simply asking them about the

requirements. It assumes a stable system where users are well informed and can

overcome biases in defining their problem.

a). What kind of information is required?

b). What fields should be included in the module?

c). What are qualification for particular designation?

d). What all information they want from the program?

e). What information they want to be automatically generated?

f). Different categories of the departments?

2. Brain storming is a technique used for generating new ideas and obtaining general

information requirement. This method is appropriate for eliciting non-

21

conventional solutions to problems. A guided approach to brain storming asks

people involved in the project to define ideal solutions and then select best

feasible one. It works well for users who have system knowledge but have

difficulty accepting new ideas.

Then with the help of the different methods of feasibility the best or the most feasible

approach is taken.

This debate is continued until participants responses have converged enough. This

method has an advantage over brainstorming in that participants are not subjected to

psychological pressure from others with presumed authority or influence.

Getting information from the existing information system

Determining information from an existing application has been called the data

analysis approach. It simply asks the user what information is currently received and

what other information is required. It relies heavily on the user to articulate

information needs. The analysts examine all reports, discusses with the user each

piece of information examined, and determines unfulfilled information needs by

interviewing the user. The analyst is primarily involved in improving the existing

flow of data to the user. In contrast to this method is decision analysis. This breaks

down a problem into parts, which allows the user to focus separately on the critical

issues. It also determines policy and organizational objectives relevant to the decision

areas identified and the specific steps required to complete each major decision. Then

the analyst and the user refined the decision process and the information requirements

for a final statement of information requirements. The data analysis method is ideal

for making structured decisions, although it requires that users articulate their

information requirements. A major drawback is a lack of established rules for

obtaining and validating information needs that are not linked to organizational

objectives.

In the decision analysis method, information needs are clearly linked to decision and

organizational objectives. It is useful for unstructured decisions and information

22

tailored to the user's decision-making style. The major drawback, though, is that

information requirements may change when the user is promoted or replaced.

SOFTWARE PLANNING AND

DESIGN

23

24

SOFTWARE PLANNING AND DESIGN

Software planning and design is an important stage in the development of software.

First of all a model needs to be selected for developing software. A process model for

software engineering is chosen based on the nature of the project and application, the

method and tools to be used, and the controls for deliverables that are required.

Keeping in mind the nature of the problem, it’s application and the language (c++) on

which the EMPLOYEE INFORMATION MANAGEMENT SYSTEM was supposed

to be developed on Evolutionary model was selected.

Evolutionary models have been explicitly designed to accommodate a product that

involves modifications over a time. Evolutionary models are iterative. They are

characterized in a manner that enables software engineers to develop increasingly

more complete version of the software. Among the versions evolutionary models

INCREMENTAL MODEL was used.

The incremental model of the linear sequential model with the iterative philosophy of

prototyping. The incremental model applies linear sequence in a staggered fashion.

Referring to the figure there are four steps in each increment.

Software requirement analysis: --The requirement gathering process is

intensified and focused specially on software. To understand the nature of the

program to be built, the software engineer must understand the information

domain for the software as well as the required function behavior, performance

and interface. Requirements for both the system and the software are documented

and revived with the customer.

Design: -- Software design is actually a multistep process that focuses on four

distinct attributes of the program, data structure, software architecture, and

interface representation and procedure retail. The design process translates

requirements into a presentation of the software that can be accessed for quality

25

before coding begins. Like requirements, the design is documented and becomes

part of the software configuration.

Code generation: -- The design must be translated into a machine-readable form.

The code generation step performs this task.

Testing: -- Once software has been generated testing begins. The testing processes

focuses on the logical internals of the software, ensuring that all the statements

have been tested, and on the functional external; that is, conducting test to uncover

errors and ensure that defined input will produce actual results that agree with

expected results.

The first increment of the incremental model produced the core product i.e. basic

requirements were addressed but many supplementary features remain

undelivered.

26

FIRST INCREMENT

DELIVERY OF FIRST INCREMENT

SECOND INCREMENT

DELIVERY OF SECOND INCREMENT

THIRD INCREMENT

DELIVERY OF THIRD INCREMENT

INCREMENTAL MODEL

27

ANALYSIS DESIGN CODE TEST



DESIGN MODEL

1. DATA FLOW DIAGRAM

2. ENTITY RELATIONSHIP DIAGRAM

3. FLOW CHART

4. BLOCK DIAGRAM

28

DATA FLOW DIAGRAM (DFD)

A DFD is a graphical representation that depicts information flow and the transforms

that are applied as data move from input to output. The basic form of a DFD is also

known as a data flow graph or a bubble chart.

DFD may be used to represent a system or software at any level of abstraction. DFDs

can be partitioned into levels that represent increasing information flow and

functional detail.

A level 0 DFD, also called a fundamental system model or a context model,

represents the entire software element or a single bubble with input and output data

indicated by incoming and outgoing arrows, respectively.

A level 1 DFD may contain five or six bubbles with interconnection arrows. Each of

the processes represented at level 1 is a subfunction of the overall system depicted in

the context model.

DFD Notations

: It represents a process or transform that is applied to data.

: It represents a data store-stored information that is used by

Software

: It represents one or more data items.

: It represents an external entities.

29

DATA FLOW DIAGRAM

ZERO DEGREE

INPUT

USERNAME AND

PASSWORD

SEARCH, ADDITION,

DELETION AND

MODIFICATION OF

EMPLOYEE DATA/RECORDS

OUTPUT

30

AccessTo Employee Data/Records

Through EIMS

DATA FLOW DIAGRAM

FIRST DEGREE

INPUT

(USER NAME AND PASSWORD)

ACCESS GRANTED ACCESS

DENIED

31

MAIN SCREEN

VERIFICATION OF

DATA

DELETE ONE OR ALL RECORD

ADD A

RECORD

MODIFYA

RECORD

SEARCHA

RECORD

EXIT

CHANGEPASSWORD

UPDATED EMPLOYEE’S DATA/RECORDS

ER-DIAGRAM

Entity – Relationship Diagram:

Depicts relationships between data objects. The object-relationship pair can be

represented graphically using the Entity-Relationship Diagram. A set of primary

components is identified for the ERD: data objects, attributes, relationships, and

various type indicators. The primary purpose of the ERD is to represent data objects

and their relationships.

Data Objects, Attributes, and Relationships

The data model consists of three interrelated pieces of information: the data object,

the attributes that describe the data object, and the relationships that connect data

objects to one other.

Data Objects:

A data object is a representation of almost any composite information that must be

understood by software. By composite information, we mean something that has a

number of different properties or attributes. A data object encapsulates data only there

is no reference within a data object to operations that act on the data. The data object

description incorporates the data object and all of its attributes. Data objects are

related to one another.

Attributes:

Attributes define the properties of a data object and take on one of three different

characteristics. They can be used to name an instance of the data object, describe the

instance, or make reference to another instance in another table. The set of attribute

that is appropriate for a given data object is determined through an understanding of

the problem context. One or more of the attributes must be defined, as an identifier

that is identifier attribute becomes a “Key” when we want to find an instance of the

data object.

32

Relationships:

Data object are connected to one another in a variety of different ways. We can define

a set of object-relationships pairs that define the relevant relationships. Object-

relationship pairs are bi-directional. Different data objects and their attributes are

described in data dictionary and their relationships between these data objects are

given in ER diagram of next section.

Cardinality and Modality

Cardinality: The data model must be capable of representing the number of

occurrences of objects in a given relationship. The cardinality of an object-

relationship pair are:

1. One-to-one (1:1): An occurrence of object ‘A’ can relate to one and only one

occurrence of object ‘B’ and an occurrence of ‘B’ can relate to only one

occurrence of ‘A’.

2. One-to-many (1:N): One occurrence of object ‘A’ can relate to one or many

occurrences of object ‘B’ but an occurrence of ‘B’ can relate to only one

occurrence of ‘A’.

3. Many-to-many (M: N): An occurrence of object ‘A’ can relate to one or more

occurrences of ‘B’, while an occurrence of ‘B’ can relate to or more

occurrences of ‘A’.

Cardinality defines “the maximum number of object relationships that can participate

in a relationship”.

Modality:

The modality of a relationship is zero if there is no explicit need for the relationship to

occur or the relationship is optional. The modality is 1 if an occurrence of the

relationship is mandatory.

33

ENTITY RELATIONSHIP DIAGRAM

34

GetsTRAINE

D

TRAININGCOURSE

TRAININGAGENCY

COURSENAME

EMPLOYEE

EMPLOYEEIDDATE OF

BIRTH

EMPLOYEEEDUCATIO

N

EMPLOYEEDESIGNATION

EMPLOYEENAME

EMPLOYEESALARY

DURATION

SEXDEPARTME -NT

FLOW CHART

Flow chart:

A flow chart depicts pictorially the sequence in which instructions / processes are

carried out in a system. Flow charts are graphical representation of the processes that

are carried out by the system, it depicts inputs, output and processing of the inputs and

the stages at which processing is done. Flow chart not only helps in accessing the

system but also in designing the algorithms for the system.

Objects used:

Start / Termination Box

Processing Box

Input / Output Box

Decision Box

Connector

35

FLOW CHART OF EIMS

START

Read User Name& Password

Matching of Password

Main menu

Employee Record Processing

36

No

Yes

Stop

BLOCK DIAGRAM

Block Diagram:

Block diagram is a representation of the system as a whole. It depicts the system as

modules; basically block diagram is representation of the system in block, which is

represented in diagram. It breaks the system into sub modules & then depicts their

behaviours & functions. Block diagram is over view of the system like what are its

modules, its function & etc.

37

BLOCK DIAGRAM FOR EIMS

38

ADD A RECORD

EXIT

DELETE A REORD

SEARCH A RECORD

MODIFY A RECORD

CHANGE PASSWORD

SHOW ALL RECORDS

EIMS

TOTAL NO. OF RECORDS

MAIN MENU

1. ADD A NEW RECORD

2. SHOW ALL RECORDS

3. SEARCH A RECORD BY NAME

4. SEARCH A RECORD BY EMPLOYEE ID

5. MODIFY A RECORD

6. DELETE A RECORD

7. DELETE ALL RECORDS

8. TOTAL NUMBER OF RECORDS

9. CHANGE PASSWORD

39

CODING

40

CODING

#include<iostream.h>

#include<conio.h>

#include<fstream.h>

#include<stdlib.h>

#include<string.h>

#include<stdio.h>

#include<graphics.h>

const int len=90;

class company

{

private:

struct employee

{

char

name[len],emp_id[len],sex[len],edu[len],desig[len],dep[len],trainc[len],traina[len],fla

g,age[len],salary[len],duration[len];

}e;

fstream file;

public:

company();

void emp_getdata();

void emp_showdata();

void emp_search();

void emp_searchn();

void emp_modify();

void emp_delrec();

void emp_packrec();

void emp_total();

41

};

class security

{

private:

struct secure

{

char username[len],password[len];

}s;

public:

security();

fstream file1;

void check1(void);

void changepass(void);

};

security::security()

{

file1.open("TEST.DAT",ios::binary|ios::in|ios::out);

if(!file1)

{

clearviewport();

outtextxy(200,200,"YOUR FILE FOR USERNAME AND PASSWORD DOSN'T

EXIST ");

exit(0);

}

}

void security::check1()

{

42

char uname[50],passw[50];

int count=0;

file1.close();


clearviewport();

settextstyle(SANS_SERIF_FONT,0,1);

outtextxy(200,200,"ENTER THE USERNAME");

gotoxy(30, 16);

fflush(stdin);

gets(uname);

clearviewport();


outtextxy(200,200,"ENTER THE PASSWORD");

gotoxy(32, 16);

fflush(stdin);

gets(passw);

file1.seekg(0L,ios::beg);

while(file1.read((char*)&s,sizeof(s)))

{

if ( (strcmp(s.username,uname)==0)&&(strcmp(s.password,passw)==0) )

{

clearviewport();


outtextxy(110,200,"YOUR USERNAME AND PASSWORD HAVE

MATCHED");

getch();

clearviewport();

settextstyle(TRIPLEX_FONT,0,1);

outtextxy(220,200,"ACCESS GRANTED");

getch();

}

else

{

43

clearviewport();


outtextxy(220,200,"ACCESS DENIED");

getch();

exit(0);

}

}

count++;

file1.clear();

file1.close();

}

void security::changepass()

{

char passw[50];

int count=0;

file1.close();


clearviewport();


outtextxy(200,200,"ENTER THE OLD PASSWORD");

gotoxy(32, 16);

fflush(stdin);

gets(passw);

file1.seekg(0L,ios::beg);

while(file1.read((char*)&s,sizeof(s)))

{

if ( (strcmp(s.password,passw)==0) )

{

clearviewport();


44

outtextxy(200,200,"ENTER THE NEW PASSWORD");

gotoxy(32, 16);

fflush(stdin);

gets(s.password);

file1.seekp(0L,ios::beg);

file1.write((char*)&s,sizeof(s));

clearviewport();


outtextxy(220,200,"PASSWORD UPDATED");

getch();

}

else

{

clearviewport();


outtextxy(220,200,"INCORRECT PASSWORD");

getch();

}

}

count++;

file1.clear();

file1.close();

}

company::company()

{

file.open("PRDPROJ.DAT",ios::binary|ios::in|ios::out);

if(!file)

{

clearviewport();

outtextxy(180,200,"YOUR DATABASE DOES NOT EXIST");

exit(0);

45

}

}

void company::emp_getdata()

{

file.close();


char ch;

file.seekp(0L,ios::end);

do

{

clearviewport();


outtextxy(130,200,"ENTER THE EMPLOYEE ID OF THE EMPLOYEE");

gotoxy(33,16);

fflush(stdin);

gets(e.emp_id);

clearviewport();


outtextxy(150,200,"ENTER THE NAME OF THE EMPLOYEE");

gotoxy(28,16);

fflush(stdin);

gets(e.name);

clearviewport();


outtextxy(150,200,"ENTER THE SEX OF THE EMPLOYEE");

gotoxy(33,16);

fflush(stdin);

gets(e.sex);

clearviewport();


outtextxy(120,200,"ENTER THE DATE OF BIRTH OF THE EMPLOYEE");

46

gotoxy(32,16);

fflush(stdin);

gets(e.age);

clearviewport();


outtextxy(140,200,"ENTER THE SALARY OF THE EMPLOYEE");

gotoxy(32,16);

fflush(stdin);

gets(e.salary);

clearviewport();


outtextxy(70,200,"ENTER THE EDUATIONAL QUALIFICATION OF THE

EMPLOYEE");

gotoxy(25,16);

fflush(stdin);

gets(e.edu);

clearviewport();


outtextxy(130,200,"ENTER THE DESIGNATION OF THE EMPLOYEE");

gotoxy(30,16);

fflush(stdin);

gets(e.desig);

clearviewport();


outtextxy(70,200,"ENTER THE NAME OF THE DEPARTMENT OF THE

EMPLOYEE");

gotoxy(28,16);

fflush(stdin);

gets(e.dep);

clearviewport();


outtextxy(65,200,"ENTER THE TRAINING COURSE ATTENDED BY THE

EMPLOYEE");

47

gotoxy(26,16);

fflush(stdin);

gets(e.trainc);

clearviewport();


outtextxy(130,200,"ENTER THE NAME OF THE TRAINING AGENCY");

gotoxy(29,16);

fflush(stdin);

gets(e.traina);

clearviewport();


outtextxy(140,200,"ENTER THE DURATION OF THE COURSE");

gotoxy(32,16);

fflush(stdin);

gets(e.duration);

e.flag=' ';

file.write((char *)&e,sizeof(e));

clearviewport();


outtextxy(35,200,"DO YOU WANT TO ENTER DATA FOR THE NEXT

EMPLOYEE(y/n)?");

gotoxy(32,16);

cin>>ch;

} while(ch=='y' || ch == 'Y');

file.close();

}

void company::emp_showdata()

{

file.close();

48


int a;

file.seekg(0L,ios::beg);

while(file.read((char *)&e,sizeof(e)))

{

if (e.flag =='*')

{

}

else

{

clearviewport();


outtextxy(85,10,"EMPLOYEE INFORMATION MANAGEMENT SYSTEM");

settextstyle(DEFAULT_FONT,0,1);

outtextxy(75,100,"EMPLOYEE ID:");

gotoxy(38,7);

cout<<e.emp_id;


outtextxy(75,135,"NAME:");

gotoxy(38,9);

cout<<e.name;


outtextxy(75,170,"DATE OF BIRTH:");

gotoxy(38,11.9);

cout<<e.age;


outtextxy(75,205,"SEX:");

gotoxy(38,13.95);

cout<<e.sex;

49


outtextxy(75,240,"SALARY:");

gotoxy(38,16.05);

cout<<e.salary;


outtextxy(75,275,"EDUCATIONAL QUALIFICATION:");

gotoxy(38,18);

cout<<e.edu;


outtextxy(75,310,"DESIGNATION:");

gotoxy(38,20.2);

cout<<e.desig;


outtextxy(75,345,"DEPARTMENT:");

gotoxy(38,22.7);

cout<<e.dep;


outtextxy(75,380,"TRAINING COURSE:");

gotoxy(38,24.99);

cout<<e.trainc;


outtextxy(75,415,"TRAINING AGENCY:");

gotoxy(38,27);

cout<<e.traina;

50


outtextxy(75,450,"DURATION OF THE COURSE:");

gotoxy(38,29);

cout<<e.duration;

getch();

}

}

file.clear();

file.close();

clearviewport();


outtextxy(160,200,"PRESS ANY KEY TO CONTINUE");

getch();

}

void company::emp_modify()

{

file.close();


char id[10];

int count =0;

long int pos;

clearviewport();



gotoxy(33,16);

fflush(stdin);

gets(id);


while(file.read((char*)&e,sizeof(e)))

{

51

if ((strcmp(e.emp_id,id)==0)&&(e.flag==' '))

{

clearviewport();


outtextxy(130,200,"ENTER THE NEW RECORD FOR THE EMPLOYEE");

getch();

clearviewport();



gotoxy(33,16);

fflush(stdin);

gets(e.emp_id);

clearviewport();



gotoxy(28,16);

fflush(stdin);

gets(e.name);

clearviewport();


outtextxy(150,200,"ENTER THE SEX OF THE EMPLOYEE");

gotoxy(33,16);

fflush(stdin);

gets(e.sex);

clearviewport();


outtextxy(120,200,"ENTER THE DATE OF BIRTH OF THE EMPLOYEE");

gotoxy(32,16);

fflush(stdin);

gets(e.age);

clearviewport();


outtextxy(140,200,"ENTER THE SALARY OF THE EMPLOYEE");

52

gotoxy(32,16);

fflush(stdin);

gets(e.salary);

clearviewport();


outtextxy(70,200,"ENTER THE EDUATIONAL QUALIFICATION OF THE

EMPLOYEE");

gotoxy(25,16);

fflush(stdin);

gets(e.edu);

clearviewport();


outtextxy(130,200,"ENTER THE DESIGNATION OF THE EMPLOYEE");

gotoxy(30,16);

fflush(stdin);

gets(e.desig);

clearviewport();


outtextxy(70,200,"ENTER THE NAME OF THE DEPARTMENT OF THE

EMPLOYEE");

gotoxy(28,16);

fflush(stdin);

gets(e.dep);

clearviewport();


outtextxy(65,200,"ENTER THE TRAINING COURSE ATTENDED BY THE

EMPLOYEE");

gotoxy(26,16);

fflush(stdin);

gets(e.trainc);

clearviewport();


53

outtextxy(130,200,"ENTER THE NAME OF THE TRAINING AGENCY");

gotoxy(29,16);

fflush(stdin);

gets(e.traina);

clearviewport();


outtextxy(140,200,"ENTER THE DURATION OF THE COURSE");

gotoxy(32,16);

fflush(stdin);

gets(e.duration);

e.flag=' ';

pos = count * sizeof(e);

file.seekp(pos,ios::beg);

file.write((char*)&e,sizeof(e));

return;

}

count++;

}

clearviewport();


outtextxy(85,200,"NO EMPLOYEE FOUND IN THE FILE WITH ID =");

gotoxy(60,14);

cout<<id;

getch();

clearviewport();



getch();

file.clear();

file.close();

}

54

void company::emp_search()

{

file.close();


company cmp;

ifstream infile;

infile.open("PRDPROJ.DAT",ios::in|ios::binary);

char id[30];

int count =0,flag7 =0;

long int pos;

clearviewport();



gotoxy(33,16);

fflush(stdin);

gets(id);



{

if (strcmp(e.emp_id,id)==0)

{


file.seekg(pos,ios::beg);


{

if ((e.flag =='*')||(strcmp(e.emp_id,id)!=0))

{

}

else

{

clearviewport();

55





gotoxy(38,7);

cout<<e.emp_id;



gotoxy(38,9);

cout<<e.name;



gotoxy(38,11.9);

cout<<e.age;



gotoxy(38,13.95);

cout<<e.sex;



gotoxy(38,16.05);

cout<<e.salary;



gotoxy(38,18);

cout<<e.edu;

56



gotoxy(38,20.2);

cout<<e.desig;



gotoxy(38,22.7);

cout<<e.dep;



gotoxy(38,24.99);

cout<<e.trainc;



gotoxy(38,27);

cout<<e.traina;



gotoxy(38,29);

cout<<e.duration;

flag7++;

getch();

}

}

}

count++;

}

if(flag7==0)

57

{

clearviewport();



gotoxy(60,14);

cout<<id;

getch();

clearviewport();



getch();

}

file.clear();

file.close();

infile.close();

}

void company::emp_delrec()

{

file.close();


char id[30];

long int pos;

int count=0;

clearviewport();



gotoxy(33,16);

fflush(stdin);

gets(id);


58


{

if(strcmp(e.emp_id,id)==0)

{

e.flag='*';

pos=count*sizeof(e);

file.seekp(pos,ios::beg);

file.write((char*)&e,sizeof(e));

clearviewport();


outtextxy(95,200,"EMPLOYEE RECORD DELETED WITH THE ID =");

gotoxy(61,14);

cout<<id;

getch();

return;

}

count++;

}

clearviewport();



gotoxy(60,14);

cout<<id;

getch();

clearviewport();



getch();

file.clear();

file.close();

}

void company::emp_packrec()

59

{

file.close();


ofstream outfile;

outfile.open("PREP",ios::out);

file.seekg(0,ios::beg);

while(file.read((char*)&e,sizeof(e)));

{

if(e.flag !='*')

outfile.write((char*)&e,sizeof(e));

}

outfile.close();

file.close();

remove("PRDPROJ.DAT");

rename("PREP","PASS.DAT");

file.open("PRDPROJ.DAT",ios::binary|ios::in|ios::out|ios::nocreate);

}

void company::emp_searchn()

{

file.close();


company cmp;

ifstream infile;

infile.open("PRDPROJ.DAT",ios::in|ios::binary);

char name1[len];

int count =0,flag7 =0;

long int pos;

clearviewport();


60


gotoxy(28,16);

fflush(stdin);

gets(name1);



{

if (strcmp(e.name,name1)==0)

{


file.seekg(pos,ios::beg);


{

if ((e.flag =='*')||(strcmp(e.name,name1)!=0))

{

}

else

{

clearviewport();





gotoxy(38,7);

cout<<e.emp_id;



gotoxy(38,9);

cout<<e.name;

61



gotoxy(38,11.9);

cout<<e.age;



gotoxy(38,13.95);

cout<<e.sex;



gotoxy(38,16.05);

cout<<e.salary;



gotoxy(38,18);

cout<<e.edu;



gotoxy(38,20.2);

cout<<e.desig;



gotoxy(38,22.7);

cout<<e.dep;


62


gotoxy(38,24.99);

cout<<e.trainc;



gotoxy(38,27);

cout<<e.traina;



gotoxy(38,29);

cout<<e.duration;

flag7++;

getch();

}

}

}

count++;

}

if(flag7==0)

{

clearviewport();


outtextxy(105,200,"NO EMPLOYEE FOUND IN THE FILE WITH NAME");

gotoxy(27,16);

cout<<name1;

getch();

clearviewport();



63

getch();

}

file.clear();

file.close();

infile.close();

}

void company::emp_total()

{

file.close();


int a = 0;



{

if (e.flag =='*')

{

}

else

{

a++;

}

}

file.clear();

file.close();

clearviewport();


outtextxy(104,196,"THERE ARE TOTAL");

gotoxy(30, 13);

cout<<a;


64

outtextxy(262,196,"EMPLOYEE'S RECORDS IN THE FILE");

getch();

clearviewport();



getch();

}

//start of main function//start of main function//start of main function//start of main

function//

void main ()

{

int gm,gd=DETECT,ch1;

initgraph(&gd,&gm,"d:\\TC\\BGI");

security s1;

//s1.check1();

company cmp1;

char ch,ans;

do

{

clearviewport();




outtextxy(190,90,"WELCOME TO THE MAIN MENU");


outtextxy(230,150,"0. EXIT");

outtextxy(230,170,"1. ADD A NEW RECORD");

outtextxy(230,190,"2. SHOW ALL RECORDS");

outtextxy(230,210,"3. SEARCH BY EMPLOYEE ID");

65

outtextxy(230,230,"4. SEARCH BY EMPLOYEE NAME");

outtextxy(230,250,"5. MODIFY A RECORD");

outtextxy(230,270,"6. DELETE A RECORD");

outtextxy(230,290,"7. DELETE ALL RECORDS");

outtextxy(230,310,"8. TOTAL NO. OF RECORDS");

outtextxy(230,330,"9. CHANGE PASSWORD");

outtextxy(230,387,"ENTER YOUR CHOICE : ");

gotoxy(50, 25);

cin>>ans;

switch(ans)

{

case '1':

clearviewport();


outtextxy(150,200,"ENTER THE DATA FOR THE

EMPLOYEE");

getch();

cmp1.emp_getdata();

break;

case '2':

cmp1.emp_showdata();

break;

case '3':

cmp1.emp_search();

break;

case '4':

cmp1.emp_searchn();

break;

case '5':

66

cmp1.emp_modify();

break;

case '6':

cmp1.emp_delrec();

break;

case '7':

cmp1.emp_packrec();

break;

case '8':

cmp1.emp_total();

break;

case '9':

s1.changepass();

break;

case '0':

exit(0);

break;

default:

clearviewport();


outtextxy(220,200,"INVALID CHOICE");

}

clearviewport();


outtextxy(100,200,"DO YOU WISH TO RETURN TO THE MAIN MENU (y/n)");

gotoxy(32, 16);

cin>>ch;

67

}while(ch=='y'||ch=='Y');

cout<< endl;

}

68

OUTPUT

69

ENTER THE PASSWORD

70


WELCOME TO THE MAIN MENU

9. CHANGE PASSWORD

ENTER YOUR CHOICE:

71

0. EXIT1. ADD A NEW RECORD 2. SHOW ALL RECORDS 3. SEARCH BY EMPLOYEE ID4. SEARCH BY EMPLOYEE

NAME5. MODIFY A RECORD6. DELETE A RECORD7. DELETE ALL RECORDS 8. TOTAL NUMBER OF RECORDS

ENTER DATA FOR THE EMPLOYEEE

72

ENTER EMPLOYEE ID OF THE EMPLOYEE

73

ENTER NAME OF THE EMPLOYEE

74

ENTER SEX OF THE EMPLOYEE

75

ENTER DATE OF THE BIRTH OF THE EMPLOYEE

76

ENTER SALARY OF THE EMPLOYEE

77

ENTER EDUCATIONAL QUALIFICATION OF THE EMPLOYEE

78

ENTER DESIGNATION OF THE EMPLOYEE

79

ENTER NAME OF THE DEPARTMENT OF THE EMPLOYEE

80

ENTER TRAINING COURSE ATTENDED BY EMPLOYEE

81

ENTER NAME OF TRAINING INSTITUTE

82

ENTER DURATION OF THE COURSE

83

DO YOU WANT TO ENTER DATA FOR NEXT EMPLOYEE: y/n

84

TESTING

85

SYSTEM TESTING

INTRODUCTION: -

A system should always be tested thoroughly before its implementation, as regards its

individual programs, the system as a whole should be tested for user acceptance etc.

This is because implementing a new system is a major job, which enquires a lot of

man-hour and a lot of other resources, so an error not detected before implementation

may cost a lot. Effective testing early in the process translates directly into long term

cost savings from reduced number of errors. This is also necessary because in some

cases, a small error is not detected and corrected before installation, which may

explode into much larger problem.

Programming and testing is followed by the stage of installing the new computer

based system. Actual implementation of the system can begin at this point using either

a parallel or a direct changeover plan, or some blend of two.

Software testing is a critical element of Software Quality Assurance and represents

the ultimate review of specification, design and coding. The purpose of product

testing is to verify and validate the various work products viz. units, integrate unit,

final product to ensure that they meet their respective requirements.

TESTING OBJECTIVES: -

The testing objectives are summarized in the following three steps:

Testing is a process of executing a program with the intent of finding an error.

A good test case is one that has a high probability of finding an as yet

undiscovered error.

A successful test is the one that uncover an as yet undiscovered error.

86

Our objective is to design tests that systematically uncover different classes of

errors and do so with a minimum amount of time and effort.

87

TESTING PRINCIPLES: -

All tests should be traceable to customer requirement. Tests should be planned long

before testing begins that is the test planning can begin as soon as the requirement

model is complete.

Testing should begin “in the small” and progress towards testing “in the large”. The

first plan and executed generally focus on individual program modules. As the testing

progresses, testing shifts focus in an attempt to find errors in integrated clusters of

modules and ultimately in the entire system.

The number of path permutations for even a moderately sized program is

exceptionally large. For this reason, it is impossible to execute every combination of

paths during testing. It is possible, however to adequately cover program logic and to

ensure that all conditions in the procedural design have been exercised. To be more

effective, testing has highest probability of finding the errors.

The following are the attributes of a good test:

A good test has the high probability of finding the errors.

A good test is not redundant.

A good test should be “best of breed”.

A good test should be neither too simple nor too complex.

This process has two parts:

(a) Planning: This involves writing and reviewing unit, integration, functional,

validation and acceptance test plans.

Execution: This involves executing these test plans, measuring, collecting data and

verifying if it meets the quality criteria set in the Quality Plan. Data collected is used

to make appropriate changes in the plans related to development and testing.

The quality of a product or item can be achieved by ensuring that the product meets

the requirements by planning and conducting the following tests at various stages.

88

LEVELS OF TESTING: -

Unit Tests at the unit level, conducted by the development team, to verify individual

stand alone units.

Integration Tests after two or more product units are integrated, conducted by the

development team, to test the interface between the integrated units.

Functional Tests prior to the release to validation manager, designed and conducted

by the team independent of designers and coders, to ensure the functionality provided

against the customer requirement specifications.

Acceptance Tests prior to the release to validation manager, conducted by the

development team, if any supplied by the customer.

Validation Tests prior to the release to customers, conducted by the validation team to

validate the product against the customer requirement specifications and user

documentation.

MODULE TESTING: -

The testing of individual modules was completed during the development itself.

Creating some test data at the time of coding tested each module and necessary

change was made there on to make sure that the module is working satisfactorily.

LOOP TESTING: --

Loops are the corner stone for the vast majority of all algorithms,

implemented in software. And yet we often pay them little need while

conducting software tests.

Loop testing is a white box testing technique that focuses exclusively on

the validity of the loop constructs. Four different classes of loops can be

defined: --

89

Simple loops

Concatenated loops

Nested loops

Unstructured loop.

SIMPLE LOOPS: -- The following sets of tests were applied to simple loops.

Where n is the maximum number of allowable passes through to the loop.

Skip the loop entirely.

Only one pass through the loop.

M passes through the loop where m<n.

N-1, N+1 passes through the loop.

NESTED LOOPS: -The following tests were applied as nested loops.

1. Start at the innermost loop. Set all the others loop to minimum value.

2. Conduct simple loop tests for the innermost loop while holding outer loops at

there their minimum iteration parameter values.

3. Work outward, conducting tests for the next loop, but keeping all other outer

loops at minimum values and other nested loops to ‘typical’ values.

4. Continue until all loops have been tested.

CONCATENATED LOOPS: -- concatenated loops were tested using the same

approach as mentioned for simple loops if each of the loops was independent of other.

Otherwise in case of non-independent loops the approach mentioned for nested loops

was used.

CREATING TEST DATA: -

Though some test data were created at the time of testing individual modules, but this

may not be sufficient for further testing of the system as a whole. So, new test data

were created for all possible real life situations, which were though might occur.

90

TEST CASE DESIGN: -

Test case design focuses on a set of techniques for the creation of test cases that meet

overall testing objectives. In test case design phase, the engineer creates a series of

test cases that are intended to “demolish” the software that has been built.

Any Software Product can be tested in one of the two ways:

Knowing the specific function that a product has been designed to perform, tests can

be conducted that demonstrates each function is fully operational, at the same time

searching for errors in each function. This approach is known as Black Box testing.

Knowing the internal working of a product, tests can be conducted to ensure that

internal operation performs according to specification and all internal components

have been adequately exercised. This approach is known as White-Box testing.

Black box testing is designed to uncover errors. They are used to demonstrate that the

Software functions are operational; that input is properly accepted and output is

correctly produced; and that integrity of external information is maintained (e.g. Data

Files). A black box examines some fundamental aspects of a system with little regard

for the internal logical structure of the software.

White box testing of Software is predicted on close examination of procedural details.

Providing test cases that exercise specific sets of conditions and / or loops tests logical

paths through the software. The “state of the program” may be examined if the

expected or asserted status corresponds to the actual status.

A combination of white box testing and black box testing was applied in order to find

as many errors as possible and debugging them and checking the working of the

program.

A bottom-up approach was used during the testing as testing was started from the

smallest unit or function and then integrating with others and in the end checking a

testing the whole program together as a single entity.

91

The customer also applied a series of alpha tests at the developer’s site. The software

was used in its natural setting with the developer looking over the shoulder of the user

and recording errors and usage problem.

“EIMS” TESTING: -

As this project was to be done in three phases (Analysis, Design, and Coding) so the

testing for the EIMS was more of unit testing and module testing. As the modules got

complete the testing was done. The modules once integrated can be test in one go.

The basic idea is to check the modules individually and to see that the concatenation

of the modules is done properly. Each and every module was checked thoroughly and

then the whole system was checked in one go to see the integration between the

modules.

92

LIMITATION OF THE SYSTEM

Limitations of the system and future development areas:

As such the system doesn’t pose any technical limitations. It does require

a minimum hardware and software requirement. Therefore no practical

limitations of the system have been found yet. However the user

friendliness of the system can be further increased by embedding mouse

programming in the code.

93

BIBLIOGRAPHY

1. Object Oriented Programming --E.Balaguruswamy

2. Let Us C++ --Yashwant kanitkar

3. Complete Reference C++ --Robert L.

4. Computer Science, C++ --Gautam Sarkar, Sumita Arora

5. Software Engineering –Roger S.Pressman

94

Documents

Employee Information Management System c++Eims