Project final doc (leon)3

Requirement Engineering and Process model CHAPTER ONE Introduction Human Resource Management System of University is a large database system which can be used for managing the regular activities of a University. Human Resource Management System of University allows users to store almost all the University Employee information electronically.

1.1 Motivation We have chosen database as our project area because of our well understanding of database and programming rather than other fields like Networking, Image Processing, Graphics etc. We have decided to develop a University management database because University Management System is a crucial area from service delivery perspective and people have started realizing the importance of process automation in University’s sand it’s IT application that is used to empower Universities in managing their activities. University Management System is configurable and can be configured to meet most individual University’s needs. It makes University staff's life easier than ever. Using University Management System, finding university’s employee information is just a few seconds away which might have cost hours, or even days, manually. Now a day, in our country most of the Universities are running all their managerial activities manually and the problem of a manual system is that it very time consuming, inefficient and error prone. That’s why we have chosen the automation of University Management System as our project topics.

1.2 Overview School Management System is imagined by first truly scalable, windows-based school management package with the power to revolutionize the way that schools are run. School management software is more than just a technology solution - it is an educational system that will improve the way school is managed.

The School Management System basically divided into 4 modules such as Office Management, Academic Management, Library Management and Finance & Accounts Management. The functions of these modules are given below.

1

1.2.1 Office Management This module starts functioning once an employee gets a job into the university. The module “employee information” the complete profile of an employee in a very systematic way from personal information to alumni information. The module helps the human resource staff to save much of their time in data entry and record maintenance.

Some functions of office management module are given below: • New Recruitment process.

• Maintaining employer’s data.

• Issuing Leave, Transfer to the employees.

• Providing information like category wise list of employees, full time as well as part time.

1.3 Objective The main objective of this project is to develop an automation system for managing university activities by applying software engineering principles, tools and techniques in an efficient way. We have chosen a reputed private University named “Eastern University” (EU) as our study case.

1.4 Outline Chapter 1 will discuss a general overview of the nature and purpose of the software.

Chapter 2 will discuss the Requirement Engineering & Process Model.

Chapter 3 will discuss the Existing System Analysis & Proposed Database System for School Management.

Chapter 4 will discuss the Project Estimation.

Chapter 5 will discuss the System Design & Tools required for this project.

Chapter 6 will discuss the Implementation & Testing procedure of this project.

Chapter 7 will discuss the Conclusion & Future Scope of this project. CHAPTER TWO Requirement Engineering & Process Model

Introduction

2

Requirement engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to on understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the system. Requirement engineering must be adapted to the needs of the process, the project, the product and the people doing the work. From a software process perspective requirement engineering is a software engineering action that begins during the communication activity and continues into the modeling activity.

2.1 Requirement Engineering Requirement engineering is the primary major activity following the completion of a statement of need ensuing from the predevelopment process in a software process. Requirement engineering is defined in terms of its major activities – •

Perceptive problems

•

Solution resolve

•

Specification of a solution that is testable, understandable, maintainable and that satisfies project quality strategy.

The principle of a reasonable requirement engineering process is software requirements specification. Requirement engineering process initiates with requirements of problem analysis.

Requirements engineering process is accomplished through the execution of seven distinct functions:

inception,

elicitation,

elaboration,

negotiation,

specification,

validation

and

management are given below.

2.1.1 Inception At project inception, software engineers ask a set of context-free question to the customer. The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired and the effectiveness of preliminary communication and collaboration between the customer and the developer [1].

2.1.2 Elicitation

3

It certainly seems simple enough-ask the customer, the users, and others what objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally how the system or product is to be used on a day-to-day basis.

2.1.3 Elaboration The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. The end result of elaboration is an analysis model that defines the informational, functional and behavioral domain of the problem.

2.1.4 Negotiation The requirement engineer must reconcile these conflicts through a process of negotiation.

Customers, users and other stakeholders are asked to rank requirements and then discuss conflicts in priority.

2.1.5 Specification The specification is the final work product produced by the requirements engineer. It serves as the foundation for subsequent software engineering activities and describes the function and performance of a computer-based system and the constraints that will govern its development.

2.1.6 Validation Requirement validation examines the specification to ensure that all software requirements have been stated unambiguously that inconsistencies, omissions and errors have been detected and corrected and that work products conform to the standards established for the process, the project and the product.

2.1.7 Requirement Management The requirement management is a set of activities that help the project team to identify, control and track requirements and changes to requirements at any time as the project proceeds.

Requirement management begins with identification and each requirement is assigned a unique identifier.

2.2 Risk Analysis

4

Risk is the chance that outcomes will not turn out as planned and risk analysis are a series of steps that help a software team to understand and manage uncertainty [1].

2.2.1 Software Risk Risk always involves two characteristics •

Uncertainty – the risk may or may not be happen that is, there are no 100% probable risks.

•

Loss – if the risk becomes a reality, unwanted consequence or losses will occur.

When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk. To accomplish this, different categories of risks are considered.

•

Projects risk threatens the project plan. That is, if projects risk become real it is likely that project schedule will slip and that cost will increase. Projects risk identifies potential budgetary, schedule, personnel (staffing and organization), resource, stakeholder, and requirements problem and their impact on a software project.

•

Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible.

•

Business risks threaten the viability of the software to be built.

2.2.2 Risk Identification Risk identification is a systematic attempt to specify threats to the project plan (Estimates, schedule, resource loading etc). One method for identifying risk is to create a risk item checklist that can be used for risk identification and focuses on some subset of known and predictable risks in following generic subcategories [1].

•

Product size – risk associated with the overall size of the software to be built.

•

Business impact – risks associated with constraints imposed by management or the marketplace.

•

Customer’s characteristics – risk associated with the sophistication of the customer and the developer’s ability to communicate with the customer in a timely manner.

•

Process definition – risk associated with the degree to which the software process has been defined and is followed by the development organization.

•

Development environment – risk associated with the availability and quality of the tools to be used to build the product.

5

•

Staff size and experienced – risks associated with the overall technical and project experienced of the software engineers who will do this work.

2.2.3 Risk Mitigation, Monitoring and Management All the risk analysis activities presented to this point have a single goal – to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: Risk avoidance, Risk monitoring and Risk management contingency planning.

To mitigate the risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are•

Meet with current staff to determine causes for turnover.

•

Mitigate those causes that are under our control before the project start.

•

Once the project commences, assume turnover will occur and develop technique to ensure continuity when people leave.

•

Organize project team so that information about each development activity is widely dispersed.

•

Define documentation standard and establish mechanisms to ensure that documentations are developed in a timely manner.

•

Conduct peer reviews of all work.

•

Assign a backup staff member for every critical technology.

The project manager monitors factors that may provide an indicator of whether the risk is becoming more or less likely. The following factors can be monitored: •

General attributes of team members based on the project pressures.

•

The degree to which the team has jelled.

•

Interpersonal relationships among team members.

•

Potential problems with compensation and benefits.

6

The flowchart of risk analysis is given in Figure 2.1.

Figure 2.1: Flowchart of Risk Analysis Here, Fig 2.1 shows the step by step functions of risk analysis. In step-1 risks are identified, step-2 analyzes those risks, step-3 prioritizes those risks according to some criteria, step-4 designs plan for those risks, and step-5 monitors risk and mitigation the plan. If any new risk occurs then again step-2 is executed and same procedures (discussed above) are followed. If there is no risk occurs then all risks are solved.

2.3 Software Process Models A structured set of activities are required to develop a software system. A software process model is an abstract representation of a software process. Each process model represents a process from a particular perspective that only provides partial information about the process.

There are several popular process models such as •

Waterfall Model

•

Incremental Model

7

•

Rapid Application Development

•

Prototyping Model

•

Spiral Model

•

Extreme Programming (XP)

2.3.1 Waterfall Model Among these, the Waterfall Model [2] is followed in this project. It is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of Requirements Analysis and Definition, System and Software Design, Implementation and Unit Testing, Integration and System Testing and Operation and Maintenance.

The phases are described in next page: a) Requirements Analysis and Definition: The system’s services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. b) System and Software Design: The system’s design process partitions the requirements to either hardware or software systems. It establishes overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. c) Implementation and Unit Testing: During this stage, the software as a set of programs or program units. Unit

Design is realized

testing involves verifying that each unit

meets its specification. d) Integration and System Testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met.

After testing, the software system is delivered to the customer. e) Operation and Maintenance: Normally (although not necessarily) this is the longest lifecycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle and improving

8

the implementation of system units and enhancing the system’s services as new requirements are discovered.

The flowchart of the Waterfall Model is given in Figure 2.2.

Figure 2.2: Flowchart of Waterfall Model Some major advantages and disadvantages of Waterfall Model are given below.

Advantages: •

Having fewer errors.

•

System requirements are identified before programming starts.

•

Changes are minimized to the requirements as the project proceeds.

Disadvantages:

•

Most time consuming process model.

•

Huge amount of paperwork is necessary.

•

Does not allow going next stage before finishing the previous stage.

9

2.4 Summary This chapter is presented to provide the readers a clear view of the SDM. When developing the software a software developing model has to be chosen. For this software the Waterfall Model has been chosen. Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty.

CHAPTER THREE Existing System Analysis & Proposed System

Introduction: Requirement analysis is a software engineering task that bridges the gap between system engineering and software design. It allows the software engineer to refine the software allocation and builds the models of the data, functional and behavioral domains that will be treated by software. Among the entire software process models that have been discussed in the chapter 2, the Waterfall process model has been chosen for this particular project because of its relatively simple structure. Another feature of this model is that it is easy to follow.

3.1 Existing System Analysis As we told in chapter-1 that we have chosen a university named Eastern University as our study case. It is situated at Dhanmondi in Dhaka and was established in 2002. The human resource management system of eastern university manage the recruitment, training, promotion, transfer, retirement etc of an employee.

The existing system analysis is the first step for requirement analysis. Currently the existing system is running manually.

3.1.1 Some Major Functionalities of the Existing System •

Keep record of all the previous and current employees’ information.

•

Search a particular employee.

•

Update the status of employees.

•

Add, delete and modify the information of employee.

•

Keep record of all the salary of employee.

10

•

Add or modify the salary sheet.

3.1.2 Drawbacks of the Existing System •

The manual system is very slow considering the growth of data and its vast management specification of the system required.

•

The amount of the data is increasing day-by-day. But the system needs more manpower to get the whole management intact, though still it remains very slow.

•

Any required information needed by authority need to wait a long delay of time and linked information searching is a cumbersome and tedious work to do.

•

Updating any information is cost incuses because it requires checking of multiple files.

•

The updating becomes unreliable due to mistakes sometimes.

3.2 The Proposed System The Proposed system means a new system that should have the ability to overcome the problems of existing one. After analyzing the problem of existing system, the following modules for the proposed system have been established.

3.2.1 Some Major Advantage of the Proposed System • • • • • • •

Manage your own Security.

The system will be user friendly with the informative graphical user interface.

The system can give current and updated information to its user group.

This system will save the time and work load to the management.

The system will provide security facility to restrict unauthorized access.

The system will provide the option to view and print all the necessary reports.

The system will give the option to search necessary information.

3.2.2 User Groups of the Proposed System Two types of user groups have been proposed for this project. These are Administrative user and Normal user.

•

Administrative user o

Add new user and give authority to a normal user.

11

•

o

Add, modify and delete a employee and all of their relevant information.

o

Generate all kinds of report.

o

Check all kinds of information.

Normal User o

Add employee information.

o

Generate authorized report.

o

Generate cash transaction.

o

Add, modify, delete and search authorized information.

3.3 Summary This chapter has discussed about the Existing System Analysis and Proposed System. Next chapter will discuss about the Project Estimation.

CHAPTER FOUR Project Estimation

Introduction Before starting the project the project manager and software team must estimate the works to be done, the resources that will be required and finally the time that will be elapsed from start to finish.

4.1 Methodology When the software process model had selected, the common process framework had been adapted to it. A Common Process Framework is established by defining a small number of framework activities that are applicable to all software projects regardless of their size or complexity. Common Process Framework consists of several software engineering activities [1]: •

Customer Communication

•

Planning

•

Risk Analysis

•

Analysis and Design

•

Engineering: a) Coding b) Testing

12

•

Deployment

Customer communication is required to perform requirements engineering activities. To engineer the requirements of software the following customer communication activities have been performed: •

Reviewed the customer request.

•

Conducted several informal and formal meeting with the authority.

•

Developed a statement of scope and prepared the list of features of DST.

4.2 Task Scheduling Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering task or activities.

There ware four managerial charts we had to consider for our project and the project manager was responsible for observing all. The managerial chats are: 1. Activity Chart 2. Human Resource Requirement Chart 3. Physical Facility Requirement Chart 4. Finance Management Chart 4.2.1 Activity Chart Activity chart shows which task has to do when and how much time will be allocated for each activity. As we told in chapter 3 that we have chosen waterfall process model for our project and first we collected the requirements from the DST authority. Then we planned & gathered risk for all of those requirements and after analyzing all requirements the design part started. The coding and testing part has been completed one after another.

The activity chart of our project is given in Fig 4.1.

13

C u s t o m e r C o m m u n ic a t io n

2 8 .2 5 d ay s

P la n n i n g & S c h e d u lin g

3 4 .2 5 d ay s

R is k A n a ly s is

2 9 .7 5 d ay s

A n a ly s i s

3 1 .5 0 d ay s

D e s ig n

2 7 .7 5 d a y s

C o d in g

2 5 .5 0 d ay s

T e s t in g

3 1 .2 5 d a y s 3 days

D e p lo y m e n t

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200

210

220

D ays

Fig 4.1: Activity Chart 4.2.2 Human Resource Requirement May people can be involved in a single software project, in our project Md. Mahfuzul Islam and Siddika Mustafiz ware responsible for completing the project. To develop the project we had acted as system analyst, database administrator, programmer as well as tester but two messengers had to hire. First the customer communicator person had collected the requirement then the analyst analyzes current system and related risk. After analyzing the current system, a new system had proposed and deigned. The programmer implements the software by completing the code. For any software project, the most important and difficult part is to finding errors. The tester was responsible to do so. The most important role was the project menagerie and this person involved to the whole project duration. In case of a real life situation, the following chart depicts the human resource requirement for this project and the time duration for each of the resource personnel required.

14

Fig 4.2: Human Resource Chart

Duration: 1.

Project Manager – 211.25 days

2.

Customer Communication Personnel – 28.25 days

3.

Planning & Scheduling Personnel – 34.25 days

4.

Risk Analysis Personnel – 29.75 days

5.

Analysis & Design Personnel – 59.25 days

6.

Coder – 25.50 days

7.

Tester – 31.25 days

8.

Deployment Personnel – 3 days

9.

Messenger – 211.25 days

4.2.3 Physical Facility Requirement The physical facility requirement chart shows the physical facilities needed during the development of the project and also for how long each resource is required.

Hardware Requirements: # Personal Computer: 2 Processor

:

Pentium dual core 2.5GHz

15

RAM

:

3GB

Hard Disk

:

320GB

# Personal Printer: 1 Software Requirements: •

Microsoft Widows XP

•

Microsoft Access 2007 (for developing back end)

•

C#.Net (for developing front end)

•

Crystal Report 10.0 (for reporting)

•

Microsoft Word 2007 (used as editor)

•

Microsoft Visio 2007( for drawing charts)

The physical facility chart of our project is given in Fig 4.3 in next page.

C o m p u te r

E n t ir e P r o je c t

S o f tw a r e

E n t ir e P r o je c t

P r in t e r

E n t ir e P r o je c t

B u ild in g

E n t ir e P r o je c t

F u r n it u r e

E n t ir e P r o je c t

D e c o r a t io n / O t h e r s

E n t ir e P r o je c t

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200

210

220

D ays

Fig 4.3: Physical Resources Chat

4.3 Software Cost Estimation For the estimation of the total cost of software, several categories of cost should be considered.

After calculating the total cost estimation of our project, a cost benefit analysis had been performed to observe whether our project is feasible or not.

The software development cost for this project includes – •

Human Recourse Cost

•

Physical Facilities includes: o

Computer/Printer Cost, Software Cost, Building Rent, Furniture, Decoration/ Others

16

4.3.1 Human Recourses Cost Estimation Monthwise Expenditure Ledger: Table 4.1: Human Resources Cost Estimation Name of

No. of

Salary Tk.

1st

2nd

3rd

4th

5th

6th

7th

Required

Required

( Per

Month

Month

Month

Month

Month

Mont

Month

People Project Manager Customer Communicatio n Personnel Planning & Scheduling Personnel

People 1

Month) 15000

15000

15000

15000

15000

15000

h 15000

15000

1

5000

4708

-

-

-

-

-

-

8000

666

-

-

-

-

Risk Analysis Personnel

1

days 7333

600

-

-

-

(27.5)d

(2.25)d

ays -

ays 11100

12000

600

-

(28.25) days 1

8000

466 (1.75)

Analysis & Design Personnel

1

Coder

1

8000

12000

Days -

-

(2.5) -

-

(27.75) 8000

-

-

-

days -

(1.5)d -

ays 6666

-

(25)da Tester

1

Deployment Personnel

1

Messenger Total

2 21174

8000

5000 1000 24000

-

1000 23999

-

1000 27750

4.3.2 Physical Facilities Cost Estimation 1.

Building rent per month = 10000 Tk House usage = 7 month

17

-

1000 28000

-

1000 24199

-

1000 23900

ys 933

7400

(3.5)d

(27.75)

ays -

days 500

1000

(3)days 1000

Approximate House rent = (10000* 7) = 70000 Tk 2.

Decoration / Others (electric, gas, water, news paper & others) For 7 month per month cost is =1000 Tk Approximate cost (1000* 7) = 7000 Tk

3.

Furnishers cost (sofa set, chair-Tables, air cooler etc) =15000 Tk Usage = 7 months Furnishers lifetime = 5 years Approximate Furnishers cost = (15000/60) * 7 = 1750 Tk

4.

Desk top PC & Printer Computer & printer cost = 31620 Tk Required number 2 computer, 1 Pinter Total life time=4 years Usage = 7 months Approximate cost = (31620/48)*7*2*1= 9222 Tk

Software 1.

WinXP Operating System = $299 = 20930 Tk (Includes MS Word 2003) Software usage = 7 month Software lifetime = 5 years Approximate Software cost = (19435/60) * 7 = 2267 Tk 2.

MS Access 2007= $217 = 15190 Tk Software usage = 2 month Software lifetime = 5 years Approximate Software cost = (11700/60) * 2 = 390 Tk

3.

C#.net $109 = 7630 Tk Software usage = 2 month Software lifetime = 5 years Approximate Software cost = (7,085/60) *2 = 236 Tk

4.

Microsoft Visio 2007= $206 = 14420Tk Software usage = 2 month Software lifetime = 5 years Approximate Software cost = (21,385/60) *2= 712 Tk

5.

Cristal Report 10.0 $100 = 7000Tk Software usage = 2 month Software lifetime = 5 years Approximate Software cost = (6500/60) *2= 216 Tk

18

4.4 Cost Benefits Analysis We assume that our project life time is about 5 years and we have estimated that our project need about 1,88,790 Taka to complete the software. So according to cost benefit analysis we had to check our project is feasible or not.

Feasibility Calculations: Initial investment, F0 = -1,88,790 and IRR (Internal Rate of Return) i = 15% PV1, Present value for F1 =

F1 1 ×50,000 = = 43,478.26 (1 + i ) (1 +0.15)

PV2, Present value for F2 =

F2 2 ×60,000 = = 90,737.24 (1 + i ) 2 (1 + 0.15)2

PV3, Present value for F3 =

F3 3 ×50,000 = = 98,627.44 (1 +i )3 (1 + 0.15)3

PV4, Present value for F4 =

F4 3 ×40,000 = = 68,610.39 (1 + i ) 4 (1 + 0.15)4

PV5, Present value for F5 =

F5 2 ×40,000 = = 39,774.14 (1 +i )5 (1 + 0.15)5

NPV (Net Present Value) = F0 + PV1 + PV2 + PV3 + PV4 + PV5 = -1, 88,790+ 43,478.26+ 90,737.24+ 98,627.44+ 68,610.39+ 39,774.14 = - 1, 88,790 +3, 41,227.47 = 1,52,437 > 0 Our calculated NPV is getter than zero so, we can say that our project is economically feasible.

4.5 Summary This chapter has discussed about the Project Estimation and cost benefit analysis. Next chapter will discuss about the System Design and Tools of the project.

CHAPTER FIVE System Design &Tools

19

Introduction System Design is the most creative and challenging phase in software development. System Design describes the final system and the process by which it is developed. It refers to the technical specifications that can be applied to implement the new system.

5.1 Analysis Modeling To accomplish analysis model objectives we had to consider some basic schema such as – Data Flow Diagram (DFD), Entity Relationship Diagram (ERD) and Normalized Schema (NS).

5.1.1 Data Flow Diagram (DFD) Data Flow Diagram is a picture of the movement of data between external entities and the process and data stores within a system [2]. DFD helps the analyst to understand the entire system and helps in preparing the coding phase. There are two standards for drawing DFD: •

The DeMarco & Yourdan Symbol set

•

Gane & Sarson DFD Symbol set

The Gane & Sarson Symbol set have been used to draw the DFD for our project.

In our project four symbols ware used for drawing the DFD. These are: Source / Sink: The origin and / or destination of data, sometimes refers to as external entities.

Process: The work of the actions performed on so that they are transformed, stored, or distributed.

Data store: Data at rest, which may take the form of many different physical representation.

Data Flow: Indicate from where to where data is flowing.

Figuer: DFD Symbol The preparation of DFDs can go upto several levels deep. In each level the breakdown of a process of the previous level is shown in details.

20

5.1.1.1 The Context DFD of Automated Human Resource Management System:

5.1.1.2 The Level 2 DFD (File Management Processing System):

21

5.1.1.3 The FDD of Automated Human Resource Management System:

5.1.1.4 The Level 3 DFD (Department):

22

5.1.1.5 The Level 3 DFD (Faculty):

5.1.1.6 The Level 3 DFD (Designation):

23

5.1.1.7 The Level 3 DFD (Leave):

5.1.1.8 The Level 3 DFD (Promotion):

24

5.1.1.9 The Level 3 DFD (Transfer):

5.1.1.10 The Level 3 DFD (Training):

25

5.1.1.11 The Level 3 DFD ( Retirement):

5.1.1.12 The Level 3 DFD (Termination):

26

5.1.2 System Flow Chart of Human Resource Management System: By this System Flow chart a user will able to work on with the Human Resource Management System easily. Here in this system flow chart show every points and fields of this software.

5.1.2.1 System flow chart of HRM System Main

Figure 5.13: System flow chart of HRM System 5.1.2.2 System Flow Chart of File Maintenance

27

Figure 5.14: System Flow Chart of File Maintenance

28

5.1.2.3 System Flow Chart of Processing

Figure 5.15: System Flow Chart of Processing

29

5.1.2.4 System Flow Chart of Report (Output)

Figure 5.16: System Flow Chart of Report

5.1.2.5 System Flow Chart of Query

Figure 5.17: System Flow Chart of Search

5.1.3 Entity Relationship Diagram (ERD) A detailed, logical representation of the entities, associations, and elements for an organization or a business area is known as E-R model and the graphical representation of E-R model known as Entity Relationship Diagram [2]. It will be use for designing the database. It will make a clear understanding of the database for the system.

Some of the basic component we have used in ERD are given below: Entity: An entity is designated by a rectangle.

30

Relationship: A relationship is designated by a diamond.

Attribute: Attributes are the piece of information describing a particular entity.

Fig 5.18: ERD Symbol Cardinality: The number of instances of one entity that can be associated with each instances of other entity.

The cardinality ratios are: 1

One to One: ( | …. | )

2

One to Many: ( | …. < )

3

Many to Many: ( > ….. < )

Primary Key (PK) A primary key is an attribute or a collection of attributes that allow us to identify an entity uniquely.

Foreign Key (FK) A foreign key is an attribute of a relation which refers to an exciting attribute of another relation.

Fig 5.19 shows the partial ERD of the HRM system.

31

Fig 5.19: Partial ERD of HRM System

32

5.1.4 Data Dictionary Table 5.1: Tb_empaddress Name

Data Type

Length

Null

emp_id

Text

10

Yes

emp_pre_add

Text

60

Yes

emp_pre_div

Text

50

Yes

emp_pre_dist

Text

50

Yes

emp_pre_thana

Text

50

Yes

emp_pre_pcod

Text

4

Yes

emp_pre_pnam

Text

50

Yes

emp_par_add

Text

60

Yes

emp_par_div

Text

50

Yes

emp_par_dist

Text

50

Yes

emp_par_thana

Text

50

Yes

emp_par_pcod

Text

4

Yes

emp_par_pnam

Text

50

Yes

Data Type

Length

Null

Table 5.2: tb_empexper Name emp_id

Text

10

Yes

exper_level

Text

1

Yes

exper_pos

Text

50

Yes

exper_org

Text

60

Yes

exper_type

Text

20

Yes

exper_res

Text

100

Yes

exper_start

Date/Time

Yes

exper_end

Date/Time

Yes

33

Table 5.3: tb_employee Name

Data Type

Length

Null

emp_id

Text

10

No

emp_name

Text

60

Yes

emp_sts

Text

50

Yes

emp_type

Text

50

Yes

emp_desi

Text

50

Yes

emp_fac

Text

50

Yes

emp_dept

Text

50

Yes

emp_work

Text

50

Yes

emp_joindate

Date/Time

Yes

emp_photo

OLE Object

Yes

Table 5.4: tb_emppersonal Name

Data Type

Length 10

Null

emp_id

Text

emp_dob

Date/Time

emp_faname

Text

60

Yes

emp_moname

Text

60

Yes

emp_husname

Text

60

Yes

emp_marital

Text

15

Yes

emp_gender

Text

10

Yes

emp_religion

Text

20

Yes

emp_nationl

Text

20

Yes

emp_bloodgrp

Text

10

Yes

emp_nationnalid

Text

25

Yes

emp_mobno

Text

15

Yes

34

Yes Yes

emp_phno

Text

15

Yes

emp_email1

Text

40

Yes

emp_email2

Text

40

Yes

emp_photo

OLE Object

Name

Data Type

Length

Null

leave_cod

Text

15

No

emp_id

Text

10

Yes

lev_name

Text

50

Yes

Remainday

Number

Integer

Yes

Start

Date/Time

Yes

lve_end

Date/Time

Yes

Total

Number

Integer

Yes

description

Text

255

Yes

Yes

Table 5.5: tb_leave.

Table 5.6: tb_empedu Name

Data Type

Length

Null

emp_id

Text

10

Yes

exam_level

Text

1

Yes

exam_name

Text

40

Yes

exam_sub

Text

40

Yes

exam_class

Text

20

Yes

exam_marksper

Text

4

Yes

exam_lettergra

Text

4

Yes

exam_gpa

Text

6

Yes

exam_outgpa

Text

4

Yes

exam_institu

Text

50

Yes

35

exam_passyear

Text

255

exam_resdate

Date/Time

Yes Yes

Table 5.7: fac_info Name

Data Type

Length

Null

fac_cod

Text

3

No

fac_nam

Text

50

Yes

fac_estd

Date/Time

fac_add

Text

Yes 100

Yes

Table 5.8: tb_dept_info Name

Data Type

Length

Null

dept_cod

Text

3

No

dept_name

Text

50

Yes

dept_estd

Date/Time

fac_cod

Text

Yes 3

Yes

Table 5.9: tb_leave_info Name

Data Type

Length

Null

lev_cod

Text

3

No

lev_nam

Text

50

Yes

Table 5.10: tb_promotion Name

Data Type

Length

Null

promotion_cod

Text

3

No

emp_id

Text

10

Yes

pro_desifrom

Text

50

Yes

pro_desito

Text

50

Yes

36

effect_date

Date/Time

Yes

assign_date

Date/Time

Yes

Table 5.11: tb_retirment Name

Data Type

Length 10

Null

emp_id

Text

effect_date

Date/Time

Yes

assign_date

Date/Time

Yes

cause

Text

50

No

Yes

Table 5.12: tb_terminate Name

Data Type

Length 10

Null

emp_id

Text

No

effect_date

Date/Time

Yes

assign_date

Date/Time

Yes

Cause

Text

50

Yes

Description

Text

100

Yes

Table 5.13: tb_transfer.

Name

Data Type

Length

Null

transfer_cod

Text

3

No

emp_id

Text

10

Yes

trns_facfrom

Text

50

Yes

trns_facto

Text

50

Yes

trns_deptfrom

Text

50

Yes

trns_deptto

Text

50

Yes

37

trns_workfrom

Text

50

Yes

trns_workto

Text

50

Yes

effect_date

Date/Time

Yes

assign_date

Date/Time

Yes

Table 5.14: tb_User Name

Data Type

Length

Null

UserID

Number

Integer

No

UserName

Text

50

Yes

UserPassword

Text

10

Yes

Employee

Number

Integer

Yes

Services

Number

Integer

Yes

Maintainence

Number

Integer

Yes

Report

Number

Integer

Yes

UserSetting

Number

Integer

Yes

Table 5.15: tb_workplace Name

Data Type

Length

Null

workplc_cod

Text

3

No

workplc_nam

Text

50

Yes

5.1.5 Normalized Schema (NS) Normalization is a step-by-step decomposition of complex record into simple record.

Normalization reduces redundancy using the principles of non-loss decomposition. Non-loss decomposition is the reduction of a table to smaller tables without loss of information [2].

38

Redundancy is the unnecessary repetition of data. It causes problems with storage and retrieval of data. Redundancy can lead to, •

Inconsistencies, because errors are more likely to occur when data are repeated

•

Update anomalies because of inserting, modifying and deleting data may cause inconsistencies

A fully normalized record consists of •

a primary key that identifies an entity

•

a set of attributes that describe the entity

There are few rules for database normalization. Each rule is called normalization. If the first rule is observed, the database is said to be first normal form (1NF). Similarly, if the second rule is observed, the database is said to be second normal form (2NF) and if the third rule is observed, the database is said to be third normal form (3NF).

First Normal Form (1NF) The purpose of the first normal (1NF) form is to eliminate repeating group of attributes of an entity. Remedy is to create a new relation for each repeating group and create primary key for new relation [2].

Second Normal Form (2NF) The purpose of the second normal form (2NF) is to eliminate partial key dependencies for relations where primary key composed of more than one attributes, no non-key attributes should be functionally dependent on a part of the primary key. Remedy is to create a new relation for attributes which are not dependent on the whole key, copy the part of the primary key into the new relation that has link with the new attributes and create primary key for new relation [2].

Third Normal Form (3NF) The purpose of the third normal form (3NF) is to eliminate interdependencies between non-key attributes. Relations should not have a non-key attribute functionally determined by another non key attribute [2].

39

5.2 Design Tools The system is expected to serve all the purpose that it has been developed for. The design tools are used for designing the front end and back end interface and also generating the relevant report.

We use the following tools for develop our project.

•

Microsoft’s Visual Studio C#.NET 2005 (for front end design)

•

MS Access 2003 ( for back end database design)

•

Crystal Reports 10.0 (for generating report)

5.2.1 Microsoft’s Visual Studio .NET 2008 Visual studio C#.NET is Microsoft’s integrated development environment (IDE) for creating, documenting, running and debugging problems written in a variety of .NET programming languages. Visual studio .NET also offers editing tools for manipulating several types of files. Visual studio .NET is also a powerful and sophisticated tool for creating business-critical and missioncritical application [3].

Advantages of Microsoft’s Visual studio .NET 1. It is simple language. Things that may be difficult to program with other language, can be done in visual studio .NET very easily.

2. Because Visual studio .NET is so popular, there are many good resources (Books, Web sites, News groups and more) that can help one to learn about the language. You can find the answers to your programming problems much more easily than other programming languages.

3. You can find many tools (Sharewares and Freeware) on the internet that will spare you some programming time. For example, if you want to ping a user over the internet in your program, Instead of writing the ping function yourself.

5.2.2 Microsoft Access 2007 [1]

Microsoft Access, is a relational database management system from Microsoft that combines the relational Microsoft Jet Database Engine with a graphical user interface and software development tools [8].

.

40

Advantage of MS Access 2007  Easy to use  Familiar to the user 5.2.3 Crystal Reports 10.0 [2]

Crystal Reports 10.0 is the world standard in high-performance reporting software. Deliver rich, interactive content from virtually any data source with crystal reports. Developer can create reports in multiple languages because crystal reports now fully support Unicode data types.

Advantage of Crystal Reports 10.0 •

The reports that are created can be viewed in many file formats.

•

Possible to convert a report to Microsoft Word, Adobe Portable Document Format (PDF), Hyper Text Markup Language (HTML).

•

Allows developer to control how reports are cached on servers setting timeouts, restrictions etc.

5.3 Summary This chapter has discussed about the System Design & tools. Next chapter will discuss the Implementation & Testing.

CHAPTER SIX Screen Shot & Verification

Introduction:

Software Testing is the process of executing program or system with the intent of finding errors.

Or, it involves any activity aimed at evaluating an attribute or capability of a program or system a

41

determining that it meets its required results. 5 Software testing is intended to show that a system conforms to its specification and the system meets the expectation of the customer buying the system. It involves the checking process, such as inspection and reviews, at each stage of the process from user requirements definition to program development.

6.1 Tasting:

Tasting is the process of exercising a program with the specific intent errors prior to delivery to the end user. This area is concerned with verifying that a correct solution to the problem, embodied in the statement of the requirements, has been developed. Testing is a multi-stage process that consists of activities for validating the software product, from the most primitive elements up to the fully integrated system. This area includes activities such as unit testing, integration testing, system testing, performance testing, acceptance testing. [5]

•

Unit testing

•

Integration testing

•

System testing

•

Performance testing

•

Acceptance testing

•

Installation testing

•

Test document

6.1.1 Unit testing:

The unit testing is concerned with knowledge about testing a peogram unit, typically developed by a single individual, to determine that it is free of data, logic or standards error. This unit includes knowledge of dynamic analysis (equivalent partitioning, boundary value analysis, logic-based tasting, random testing, and syntax testing) and static analysis (complete path testing, decision testing, condition testing, and data-flow testing).

42

In the case of this project each of the modules were tested individually.

6.1.2 Integration testing:

The integration testing is concerned with knowledge about validating that software components, which have been unit tested separately, interact correctly when they are put together to perform a higher order function. This unit also includes knowledge about dependency checking for calls, data, and processes. And about interface checking in terms of range, type compatibility, representation, number and order of parameters and method of transfer, after the unit testing has been done, the units have been integrated and the module was tested. After successful results from the module testing, the modules were integrated and Integration testing was performed to check the stability and consistency of the entire software.

6.1.3 System testing:

System testing is concerned with knowledge about validating specified functional requirements of a system. This unit includes knowledge about techniques to design and enact an independent testing process of all of the systemâ&#x20AC;&#x2122;s functions described in the software requirements specification.

6.1.4 Performance testing:

Performance testing is concerned with knowledge about validating the performance requirements of a system. This unit includes knowledge about techniques to instrument performance measures like losing, events counts, event duration, and sampling. It also includes knowledge about methods for tuning a system for optimum saturation, load, and throughput threshold. In this project,

43

performance testing was tested at one level. At the first phase of the performance testing the back end of the software or the MS Access (2007) Database performance in respect to this application was tested. Among the test related to the database tasting was

•

Data add testing

•

Data deletion testing

•

Data edit testing

•

Data exit testing

•

Stored procedure executing testing

6.1.5 Acceptance testing:

Acceptance testing Performance testing is concerned with knowledge about validating the functional and non- functional requirements of a purchased or acquired system.

•

Functional requirements: Statements of service the system should provide how the system should react to particular inputs and how the system should behave in particular situations. [7]

•

Non- functional requirements: Constraints on the service or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. [5]

This unit includes knowledge about techniques for using the statement of work, the software requirements specification, and the request for proposal to ensure that the delivered system meets all of the requirements.

6.2 Test Case

44

Each scenario will be described in a test case. The format of the testing case will be description of the test case, expected results, test action/input, test output and compare Result and expectation.

Here five test cases have been discussed. Other cases will be tested in the same manner.

TEST CASE 1 Description

Test the login module of the system. Each time user will enter the username and password the system will check them with the database. This test is based on exploratory techniques. The first test will be with an invalid username and password.

Expected result

For each unsuccessful attempt, there will be a warning message and the number of attempts will decrease by one

Test Data/input

Username: admin Password: admin

Test Output

Invalid username/password. Please try again.

Warning you have only 2 attempts

Result and expectation

Success The username and the password were not in the database. So, the system denied to login.

TEST CASE 2 Description

Test the login module of the system with valid user name and password.

Expected result

After successful attempt, the system will go to the main system interface.

Test Data/input

Username: admin

45

Password: admin Test Output

The attempt was successful. The system is now on the main interface.

Result and expectation

Success The user successfully login to the system.

TEST CASE 3 Description

Test the Employee module. Add new employee into the database using add button from Employee details windows.

Expected result

There will be a message: Information Added. The Employee name will appear in their details windows.

Test action/input

Fill in individual form and clicks save.

Test Output

There is a message: Information is added.

The record if showing on employeeâ&#x20AC;&#x2122; details windows.

Result and expectation

Success The Employeeâ&#x20AC;&#x2122;s record is now added in to the database.

TEST CASE 4 Description

Modify an existing record from employee record by updating some require field.

Expected result

Message: information updated.

The system will keep the changes.

Test action/input

Modify city from the register individual form and click save.

Test Output

Message: Information Updated.

Result and expectation

Success The system keeps the changes made by the user.

46

CHAPTER SEVEN Conclusion and Future Scope

7.1 Conclusion This project’s aim was to develop an automated system for HRMS, case study “Eastern University (EU)”. It provides users with a friendly interface and easy access to the database. It saves time and makes record easier to manage. Security is a big issue when there is question of record. This system provides user authentication facility, which makes this system more reliable to the organization. It also records the user login information, which may help monitor the system user.

Overall the system has adequate functionality to run any school management system internals.

7.2 Discussion Problem 1 : Inserting image in database.

Solution

: Solution was found from internet.

Problem 2 : Designing security module.

47

Solution

: Consulted with senior (former) student of EU.

Problem 3: Managing employee educational information.

Solution

: Set together and solved.

Problem 4: Designing Salary system.

Solution : Some complexities were eliminated.

7.3 Limitation Like other applications, proposed system has some restriction and limitations. One of the important limitations for this system is portability. The system will run on Microsoft platform. It is not compatible with other platform such as UNIX and Linux. As this is a client/server base system, all the client computer will be needed an addition software to run the developed system. Security and usability are other issues to consider for the system.

The constraint of time is another limitation. After applying the software engineering procedures, it is very difficult to develop the software in a complete standard within the duration of the time. If we had enough time, we would have expanded it more and make it more standard.

7.4 Future Scope While developing this system, the technology was chosen carefully in terms of further modification. The system was developed by C#. According to the research, both of these are very reliable language tool. Modification is rather easy than other languages. The project has focused on a small scale management system for the hospital management. However; more functionality can be added to improve the system likes  Student Management  Total Accounting  Inventory Management  Payroll  Budget and Planning.  Web version

48