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 Design is realized

as a set of programs or program units. Unit 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 life-

cycle 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.

2.4 Summary

9

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.

Add or modify the salary sheet.

10

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.

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

11

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

Deployment

12

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

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.

Fig 4.2: Human Resource Chart

Duration:

1. Project Manager – 211.25 days

2. Customer Communication Personnel – 28.25 days

14

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

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.

15

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

4.3.1 Human Recourses Cost Estimation

Monthwise Expenditure Ledger:

Table 4.1: Human Resources Cost Estimation

Name of

Required

People

No. of

Required

People

Salary Tk.

( Per

Month)

1st

Month

2nd

Month

3rd

Month

4th

Month

5th

Month

6th

Mont

h

7th

Month

Project Manager

1 15000 15000 15000 15000 15000 15000 15000 15000

Customer CommunicationPersonnel

1 5000 4708

(28.25)

days

- - - - - -

Planning 1 8000 466 8000 666 - - - -

16

& Scheduling Personnel

(1.75)

Days

(2.5)

days

Risk Analysis Personnel

1 8000 - - 7333

(27.5)d

ays

600

(2.25)d

ays

- - -

Analysis & Design Personnel

1 12000 - - - 11100

(27.75)

days

12000 600

(1.5)d

ays

-

Coder 1 8000 - - - - - 6666

(25)da

ys

-

Tester 1 8000 - - - - - 933

(3.5)d

ays

7400

(27.75)

days

Deployment Personnel

1 5000 - - - - - - 500

(3)day

s

Messenger 2 1000 1000 1000 1000 1000 1000 1000 1000

Total 21174 24000 23999 27750 28000 24199 23900

4.3.2 Physical Facilities Cost Estimation

1. Building rent per month = 10000 Tk

House usage = 7 month

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

17

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

Software1. 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



Approximate Software cost = (11700/60) * 2 = 390 Tk

3. C#.net $109 = 7630 Tk



Approximate Software cost = (7,085/60) *2 = 236 Tk

4. Microsoft Visio 2007= $206 = 14420TkSoftware usage = 2 monthSoftware lifetime = 5 yearsApproximate Software cost = (21,385/60) *2= 712 Tk

5. Cristal Report 10.0 $100 = 7000TkSoftware usage = 2 monthSoftware lifetime = 5 yearsApproximate Software cost = (6500/60) *2= 216 Tk

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 = = = 43,478.26

18





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

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).

19

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.

5.1.1.1 The Context DFD of Automated Human Resource Management System:

20

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

Table 5.2: tb_empexper


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

33

exper_start Date/Time Yes

exper_end Date/Time Yes

Table 5.3: tb_employee


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


emp_id Text 10 Yes

emp_dob Date/Time Yes

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

34

emp_nationl Text 20 Yes

emp_bloodgrp Text 10 Yes

emp_nationnalid Text 25 Yes

emp_mobno Text 15 Yes

emp_phno Text 15 Yes

emp_email1 Text 40 Yes

emp_email2 Text 40 Yes

emp_photo OLE Object Yes

Table 5.5: tb_leave.


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

Table 5.6: tb_empedu


emp_id Text 10 Yes

exam_level Text 1 Yes

exam_name Text 40 Yes

exam_sub Text 40 Yes

35

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

exam_passyear Text 255 Yes

exam_resdate Date/Time Yes

Table 5.7: fac_info


fac_cod Text 3 No

fac_nam Text 50 Yes

fac_estd Date/Time Yes

fac_add Text 100 Yes

Table 5.8: tb_dept_info


dept_cod Text 3 No

dept_name Text 50 Yes

dept_estd Date/Time Yes

fac_cod Text 3 Yes

Table 5.9: tb_leave_info


lev_cod Text 3 No

lev_nam Text 50 Yes

36

Table 5.10: tb_promotion


promotion_cod Text 3 No

emp_id Text 10 Yes

pro_desifrom Text 50 Yes

pro_desito Text 50 Yes

effect_date Date/Time Yes

assign_date Date/Time Yes

Table 5.11: tb_retirment


emp_id Text 10 No



cause Text 50 Yes

Table 5.12: tb_terminate


emp_id Text 10 No



Cause Text 50 Yes

Description Text 100 Yes

37

Table 5.13: tb_transfer.


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

trns_workfrom Text 50 Yes

trns_workto Text 50 Yes



Table 5.14: tb_User


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


38

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].

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

39

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].

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 mission-

critical 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

40

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].

.

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

41

http://en.wikipedia.org/wiki/Relational_database_management_system

http://en.wikipedia.org/wiki/Graphical_user_interface

http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine

http://en.wikipedia.org/wiki/Microsoft

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

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

42

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).

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

43

testing process of all of the system’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,

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]

44

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

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

45

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

Password: admin

Test Output The attempt was successful. The system is now on the main

interface.


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

46

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’ details windows.

Result and expectation Success The Employee’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.


The system keeps the changes made by the user.

47

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.

Solution : Consulted with senior (former) student of EU.

48

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

49

Documents

Project final doc (leon)3