Annual Internal Department Ranking

System UAJK

By

Azmat Shah
2014-GMDB(B)-008316

Jazab Majeed Balooch

2014-GMDB(B)-008362

Supervisor
Dr Lal Hussain
Lecturer

DEPARTMENT OF COMPUTER SCIENCES & INFORMATION

TECHNOLOGY
FACULTY OF SCIENCES
UNIVERSITY AZAD JAMMU & KASHMIR
MUZAFFARABAD

Session :2016-18

i
 APPROVAL CERTIFICATE

It is certified that the project work presented in this report entitled “Annual Internal
Departmental Ranking System UAJK” submitted by Azmat Shah (Roll No. 01) and
Jazab Majeed Balooch (Roll No. 02) of Session (2016-18) supervised by Dr. Lal
Hussainin our opinion is fully adequate in scope and quality of Masters in Computer
Science (MCS).

_________________ __________________
(Supervisor) (External Examiner)
Dr. Lal Hussain
Lecturer
Department of CS & IT,
University of Azad Jammu & Kashmir
Muzaffarabad

_________________
(Chairman)
Mr. Sharjil Saeed
Department of CS & IT
University of Azad Jammu & Kashmir
Muzaffarabad

ii
 DEDICATION

Our Parents , Brothers , Sisters and Teachers whose prayer have a always been a source
of great inspiration for us and whose continuous hope in us has led us to where we stand
today.

Specially dedicated to our fellow Raja Zeeshan Naseer , May is soul rest in peace.

iii
 ABSTRACT

Previously there is no system of Annual Internal Departmental Ranking System In UAJK.

All the research and departmental work is done manually, which is very slow and
consuming much effort and time.it is required to design a computerized system (Annual
Internal Departmental Ranking System) which save the research work department wise
and by using this information we finally rank our department in UAJK. This system also
Provide a facilities for students and staff to check their research work and ranking. This
system will act as a central reservoir of information including all research work by
faculty members and user can save a research work and departmental work in pdf file. It
will also enable its to generate reports of ranking of department base on their work at the
end of year. The Idea of ranking between department is totally based on some major
parameter that is used by HEC to rank universities , by this application we know well
which Department is playing their highest effort for university ranking which is done by
HEC.

iv
 DECLARATION

We declare that this system , neither as a whole nor as a part has been copied from any

other source.it is further declared that we have completed our project entirely on the basic

of our personal effort made under the sincere guidance of our supervisor .No portion of

the work presented in this report has been submitted in support of any application for any

other degree or qualification of this or any other university or institute of learning. If any

part of this project and write up is proved to be copied out or these is any duplication of

code , then we will be responsible for the consequence

1. Azmat Shah

Signature

2. Jazab Majeed Baloch

Signature

v
 ACKNOWLEDGEMENTS

If oceans turn into ink and all of the wood become pens , even then the praises of “Allah

Almighty” cannot be expressed .He is who created the universe and knows whatever is

there in it , hidden or evident and who bestowed upon us the intelligence ability and

wisdom to search for the secrets .We must bow our heads before Allah Almighty who is

compassionate and merciful and whose help enabled us to complete this job , which

marks an important turning point in our life.

Countless salutation is upon the “Holy Prophet Muhammad (Sallallah-o-

AliahWassalam)” , the city of knowledge who has guided his “Umma” to Seek

Knowledge to grave.

The word are inadequate to express my deepest sense of appreciation and devotion to our

worthy supervisor Dr. Lal Hussain .We are extremely grateful to his scholastic and

sympathetic attitude , inspiring guidance , generous assistance , accomplishment of this

manuscript.

Special regards to the Chairman of DCS&IT , faculty members , our colleagues and our

parents whose continuous has led us to the path of learning.

Azmat Shah

vi
 Jazab Majeed Baloch

vii
 TABLE OF CONTENTS

Dedication........................................................................................………...iii
Abstract...........................................................................................................iv
Declaration.......................................................................................................v
Acknowledgment............................................................................................vi

Chapter I: ..................................................................................Introduction

1.1 General.......................................................................................1
1.2: Problem......................................................................................1
1.3: Objectives..................................................................................2
1.4: Scope..........................................................................................2
1.5: Feasibility Study ......................................................................3
1.5.1: Technical Feasibility..................................................................3
1.5.2: Scheduling Feasibility................................................................4
1.5.3: Operational Feasibility...............................................................4
1.6.: Software Process Model.............................................................4

Chapter 2: ...……………………………….……... Requirement Analysis

2.1 Overview.....................................................................................6
2.2: Objectives of Requirement Analysis...........................................7
2.3: Purpose.......................................................................................7
2.4: Existing System..........................................................................8
2.5: Proposed System ......................................................................9
2.6: Advantages of Proposed System.................................................9
2.7: Functional Requirements.............................................................9
2.8: Non-Functional Requirements..................................................10
2.9 Developments Tools..................................................................10
2.9.1: Hardware Requirements............................................................11

viii
 2.9.2: Software Requirements.............................................................11

Chapter 3: ..............................................................................System Design

3.1: Entity Relationship Diagram.....................................................12

3.2: Use Case Diagram.....................................................................15
3.3: Sequence Diagram....................................................................16
3.4: Activity Diagram.......................................................................24
3.5: Physical Design ......................................................................31

Chapter 4: ...........................................................................Implementation

4.1: Implementation Strategy...........................................................37

4.1.2: Language Selection...................................................................38
4.2: Software Development Process.................................................39
4.2.1: Coding.......................................................................................39
4.2.2: Debugging ..............................................................................40
4.2.3: Testing.......................................................................................40
4.3: Implementation Issue................................................................40
4.4: Conversion Technique...............................................................40
4.5: Technique to be Used .............................................................41
4.6: Justification to be Used ..........................................................41

Chapter 5: ...........................................................................Testing Strategy

5.1: Introduction...............................................................................42
5.1.1: Testing Strategy Used................................................................42
5.2: Unit Testing...............................................................................43
5.3: Integrity Testing........................................................................43

ix
 5.4: Regression Testing ..................................................................44
5.5: Validation Testing......................................................................44
5.5.1: Validation Testing Criteria.........................................................44
5.6: Block-Box and White-Box Testing...........................................45
5.7: System Testing..........................................................................45

Chapter 6: ....................................................Conclusion and Future Work

6.1 Achievements............................................................................52
6.2: Limitation..................................................................................52
6.3: Future Work..............................................................................53
6.3: Software as its Best...................................................................53
6.4: Snap Shot..................................................................................54

x
 LIST OF FIGURES

Number Page

Fig 1.1 Iterative Water Fall Process Model..............................................5

Fig 3.2 ERD Diagram............................................................................13

Fig 3.1.2 EERD of System........................................................................14

Fig 3.2 Use Case Diagram.....................................................................16

Fig 3.3.1 Login Sequence Diagram..........................................................17

Fig 3.3.2 Add Teacher Sequence Diagram................................................18

Fig 3.3.3 Save Teacher Contribution Sequence Diagram.........................19

Fig 3.3.4 Delete Teacher Sequence Diagram............................................20

Fig 3.3.5 Rank Department Sequence Diagram........................................21

Fig 3.3.6 Update Record Sequence Diagram............................................22

Fig 3.3.7 Logout Sequence Diagram........................................................23

Fig 3.4.1 Login Activity Diagram.............................................................24

Fig 3.4.2 Add Teacher Activity Diagram..................................................25

Fig 3.4.3 Add Conference Activity Diagram............................................26

Fig 3.4.4 Add Research Paper Activity Diagram......................................27

Fig 3.4.5 Rank Department Activity Diagram..........................................28

Fig 3.4.6 Save Teacher Contribution Activity Diagram............................29

Fig 3.4.7 Admin Activity...........................................................................30

xi
 LIST OF TABLES

Number Page

Fig 3.5.1 Faculty.......................................................................................31

Fig 3.5.2 Department................................................................................31

Fig 3.5.3 Accreditation..............................................................................31

Fig 3.5.4 Self Assessment Reports............................................................32

Fig 3.5.5 Student Teacher Ratio................................................................32

Fig 3.5.6 Teachers.....................................................................................32

Fig 3.5.7 Awards.......................................................................................33

Fig 3.5.8 Teacher’s Awards.......................................................................33

Fig 3.5.9 Collaboration.............................................................................33

Fig 3.5.10 Teacher’s Collaborations...........................................................34

Fig 3.5.11 Conference.................................................................................34

Fig 3.5.12 Teacher’s Conference................................................................34

Fig 3.5.13 Research Paper...........................................................................35

Fig 3.5.14 Research Project........................................................................35

Fig 3.5.15 Supervision................................................................................35

Fig 3.5.16 Workshops.................................................................................36

Fig 3.5.17 Teacher’s Workshops.................................................................36

xii
 CHAPTER 1

Introduction

1.1 General

In these days every one is in competition with other , in the current situation the
ranking is done by HEC at universities level only .To familiar with the parameters
mainly used by HEC we build a system know as Annual Internal Departmental
Ranking System to rank department of UAJK. If this ranking is being done
manually its is time consuming and hard effort , the faculty, students and staff don’t
know about their Department work. Our project make a platform where user will
consume less amount of time compared to manual paper work through the automated
system. Data storing is easier. It will be able to check any record at any time . Paper
work and manual work is reduced. This system is user friendly and easy to use.

1.2 Problem statements

Previously there is no system for internal departmental ranking in UAJK ,but research

and department work of is saved totally manually students and staff don’t know these

work but very rare and its taking a long process and consume a lot of time. The

problem of planning, organization, time management on proper use of resource,

budget, resource and space. If ranking work is done manually this is too much time

consuming and a lot of chance of error and everybody is not access the result and

record of department.

1
1.3 Objectives

The objectives of Annual Internal Departmental Ranking System is to provide

system which manage the activity of many teacher and department at a time. It also

rank the department by using the information of departments and its teacher without

consuming human power and time that is wasted in paper work. The system will take

care of all the servicing in a quick manner. Data storing is easier. User will be able to

check any report at any time. Paper work and manual work is reduced. This system is

user friendly and easy to use.

1.4 Scope

Before designing a computer base system it is essential and helpful to establish the

objective that system will fulfil. It is the goal of our proposed system to keep

everything as simple as possible. System should be designed in such a way that user

can use it with great ease and comfort.

The system will be menu driven with all option available at each input screen.

• Some basic features and functionalities that are considered in Departmental

Ranking scope include:

 Assessment of Program

 Accreditation of Program

 Research Contribution

 Seminars

 Conference(Held , Participate) ,

 Event , Workshops(Conduct , Held)

 Paper Presented

2
  Project Completed

 Students Teacher Ratio per Department

 Collaboration Made , etc.

1.5 Feasibility Study

Automation of Annual Internal Department Ranking System UAJK

is a good solution to serve the purpose of ranking in universities offering the project

is technically and operationally feasible and does not have any ethical issue. The

problem is never before addressed in DCS&IT, and solving it will be the service to

the institute.

1.5.1 Technical Feasibility

The project does not need such hardware for development, design and continues

operation that is not to be bought, but only the hardware that is developers and the

organization use in their daily life like laptops or PC, so the project is technical

feasible with respect to hardware.

Also the software requirement f design and development, that is window

8.1,Microsoft SQL SERVER 2014(Express Edition) and Visual Studio 2013 are easily

achievable. Same is true for Software requirement of operation, that is, Window 8.1

and .NET Framework 4.5 .

3
1.5.2 Scheduling Feasibility

The project is to build from scratch; its detailed plan is given in upcoming section of

the Document. With hard work and full dedication, we will be able to deliver the

system on time.

1.5.3 Operational Feasibility

Development cost of software are not so compelling as:

 No new hardware is to be purchased

 Software needed as easily available

1.6 Software Process Model

Software process model is an abstract representation of a software process, which is

a set of activities that led to the production of Software product. Some of the generic

process model are Waterfall Process Model, evolutionary development and

component based software engineering. For this project we will follow iterative

waterfall process model, because of clear and unchanging work.

4
Figure 1.1 : Iterative Water Fall Process Model

5
 CHAPTER 2

Requirement Analysis

2. 1 Overview

analysis is a fact finding technique where studies like user’s need , system

requirement specification, feasibility analysis and cost-benefit analysis are carried

out.

Client/User Needs

Problem Analysis

Requirement Analysis

Validation

Validated SRS

6
The purpose of this project is to identify , analysis and document the exact

requirements for the system. The developer, user may perform such study. It is

extremely important the developer of the system study the existing system

thoroughly otherwise it is impossible to satisfy the needs of the user.

During the requirement analysis phase, the development team analyses the

requirements to be fulfilled by this project and identifies the probable approach for

meeting these requirements.

2.2 Objectives of Requirement Analysis

Requirement analysis was conducted with the following objectives in minds:

 Identification of needs

 Information gathering

 Evaluate system concept of feasibility

This document, software requirement specification (SRS), describes the overall

requirement of this project. It states the scope of the project and detail its functional

and non-functional requirement.

2.3 Purpose

Purpose of this documentation is to describe the behavior of the system being

developed, its functional and non-functional requirement , design constraints and

other miscellaneous factors effecting the project. So the documentation servers as a

guide to designers ,developers and tester who are responsible for the engineering of

7
the Annual Internal Departmental Ranking System project. Through this chapter nor

includes the specific designing requirement , but it should give the engineers all of the

information necessary to design , develop and the test the software.

2.4 Existing System

Previously there is no system for internal departmental ranking in UAJK ,but research

and department work of is saved totally manually students and staff don’t know these

work but very rare and its taking a long process and consume a lot of time. The

problem of planning, organization, time management on proper use of resource,

budget, resource and space. If ranking work is done manually this is too much time

consuming and a lot of chance of error and everybody is not access the result and

record of department.

 There is no Existing System of Internal Departmental Ranking System.

 The Record of Department is totally Manual .

 Research Work and Department Work is not available to the Whole

Department and UAJK.

 If we Rank department manually it is time Consuming.

 It is quite difficult to get accurate statistical result.

 It is difficult to get timely information.

8
2.5 Proposed System

Previously there is no system of Annual Internal Departmental Ranking System In

UAJK. All the research and departmental work is done manually, which is very slow
and consuming much effort and time.it is required to design a computerized system
(Annual Internal Departmental Ranking System) which save the research work
department wise and by using this information we finally rank our department in
UAJK. This system also Provide a facilities for students and staff to check their
research work and ranking. This system will act as a central reservoir of information
including all research work by faculty members and user can save a research work
and departmental work in pdf file. It will also enable to generate reports of ranking of
department base on their work at the end of year. The Idea of ranking between
department is totally based on some major parameter that is used by HEC to rank
universities , by this application we know well which Department is playing their
highest effort for university ranking which is done by HEC.

2.6 Advantages of Proposed System

The Advantages of the proposed system are as follow

 Less time consuming

 Effortless

 User friendly interface

 Secure

 Record Keeping

2.7 Functional Requirements

• Some basic features and functionalities that are considered in Departmental

Ranking scope include:

 Assessment of Program

9
  Accreditation of Program

 Research Contribution

 Seminars

 Conference(Held , Participate) ,

 Event , Workshops(Conduct , Held)

 Paper Presented

 Project Completed

 Students Teacher Ratio per Department

 Collaboration Made , etc.

2.8 Non-Functional Requirements

 Secure

 User Friendly

 Reliability

 Understandable

 Quick Response

 Portability

2.9 Development Tools

The most important factor is to find out what the hardware and software requirement

of the organization are. The cost of the system is also an important matter. We have

suggested the following system device. The system we have suggested it less

10
expensive and efficient in working. The hardware suggested for the proposed system

contain following specifications.

2.9.1 Hardware Requirement

 Minimum 2.4GHZ Processor

 Minimum 512MB Ram

 40GB Hard Disk

2.9.2 Software Requirement

 Window 8.1 Pro

 C#

 Visual Studio 2013

 SQL Server 2014

11
 CHAPTER 3

System Design

System design is the process of defining the architecture, components, modules,

interfaces, and data for a system satisfy specified requirements. System design could

be seen as an application of system theory to product development. There is some

overlap with the disciplines of system analysis, system architecture and systems

engineering.

3.1 Entity Relationship Diagram:

An entity-relationship diagram is a graphical representation of an information system

that shows the relationship between people, object, places, concepts or events within

the system. An ERD is a data modeling technique that can help define business

process and can be used as a foundation of a relational database. While useful for

organization data that that can be represented by a relational structure, an entity

relationship diagram can’t sufficiently represent semi-structured or unstructured data,

and an ERD is unlikely to be helpful on its own in integrating data into pre-existing

information system.

Three main component of ERD are the entities, which are object or concepts that can

have data stored about them, the relationship between those entities, and the

cardinality, which define the relationship in AIDRS. After identify the entities , their

12
relationship and cardinality, the system’s ERD is provide in figure 2. The ERD with

relative entities along with their major attributes is provided in figure 3.

13
relative entities along with their major attributes is provided in figure 3.

14
Figure 3.1 ERD of AIDRS

15
Figure 3.1.2 ERD of AIDRS with all attributes

16
3.2 Use Case Diagram:

The use case diagram is a representation of a user’s interaction with the system that

shows the relationship between the user and the different use case in which the user is

involved. A use case diagram can identify the different type of user of the system and

the different use case and will often be accompanied by other type of diagrams as

well. Use case are essential design tool that help us in laying down the design of an

application. We have produced the use cases which represent the potential actors and

their corresponding functionalities. The use case diagram for the Annual Internal

Departmental Ranking System is provided in figure below

17
 Figure 3.2: Use Case of AIDRS

3.3 Sequence Diagram:

A sequence diagram is an interaction diagram that shows how processes operate with

one another and what is their order. It is a construct of a message sequence chart. A

18
sequence diagram show the object interaction arranged in time sequence. It depicts

the classes and objects involved in the scenario and the sequence of message

exchange between the objects needed to carry out the functionality of the scenario.

The following section includes the sequence diagram of main identified use case.

Admin Login Sequence Diagram

Figure 3.3.1: Sequence diagram for Login

19
Sequence diagram for add Teacher

Figure 3.3.2: Sequence diagram for add Teacher

20
Sequence diagram for Save Teacher’s Contribution

Figure 3.3.3: Sequence diagram for Save Teacher Contribution

21
Sequence diagram for Delete Teacher

Figure 3.3.4: Sequence diagram for Delete Teacher

22
Sequence diagram for Rank Department

Figure 3.3.5: Sequence diagram for Rank department

23
Sequence diagram for Update record

Figure 3.3.6 Sequence diagram for Update record

24
Sequence diagram for Logout

Figure 3.3.7: Sequence diagram for Logout

25
3.4 Activity Diagram

1: Login Activity Diagram :

3.4.1 Login Activity Diagram

26
2: Add Teacher Activity Diagram

3.4.2 Add Teacher Activity diagram

27
3: Conference Activity Diagram

3.4.3 Conference Activity Diagram

28
4: Research Paper Activity Diagram

3.4.4 Research paper Activity Diagram

29
5: Rank Department Activity Diagram

3.4.5 Rank Department Activity Diagram

30
6: Save Teacher Contribution Activity Diagram

3.4.6 Save Teacher Contribution Activity Diagram

31
7: Admin Activity Diagram

3.4.7 Admin Activity Diagram

32
3.5 Physical Design:

A data type is a detailed coding scheme recognized by system software, such as a

DBMS, for representing organizational data. The space to store data and the speed

required to access data, related with these data type are of consequence in physical

database design.

3.5.1 Faculty

3.5.2 Department

33
3.5.3 Accreditation

3.5.4 Self Assessment Report

3.5.5 Student Teacher Ratio

34
3.5.6 Teacher

3.5.7 Award

3.5.8 Teacher’s Award

35
3.5.9 Collaboration

3.5.10 Teacher’s Collaboration

3.5.11 Conference

36
3.5.12 Teacher’s Conference

3.5.13 Research Paper

3.5.14 Research project

37
3.5.15 Supervision

3.5.16 Workshops

3.5.17 Teacher’s Workshops

38
 CHAPTER 4

Implementation

4.1 Implementation Strategy

According to initial study and design phase, we have to decide about the

implementation strategy which include application type, Language selection and the

proposed system requirements

 Proposed System Requirements

 Language Selection

Propose System Requirement

According to the system requirement and end-user requirement, we have to select

such language which make such an interface that us user-friendly and help to achieve

required goal.

The main requirement of user is that we make such software for the organization

which provides maximum security, easy to operate, modifiable according to new

needs, so we analyze many software development tools and found Microsoft SQL

2014 and Visual Studio 2013 fulfill requirement fully so we choose that tool to make

this system.

39
4.1.2 Language Selection

The selection of most suitable language is important step in software development.

So, such a language I chosen which is user friendly and platform independence.

C#.NET

C# is a programming framework built on the common language runtime that can be

used on a System to build powerful Windows form. C# offers several important

advantages over previous development tool.

 Enhanced Performance

 Power and Flexibility

 Simplicity

 Scalability and Availability

Tool and Technologies

The following tools and technologies are used to build the software.

Microsoft Visual Studio 2013.

Microsoft SQL Server 2014

SQL Server 2014

The tool use to create database is SQL server. It is most powerful tool used to create

database which maintain data accuracy and high level of security. Each table made in

database is referred as entity. User can add, delete and update data in SQL Server.

40
One of the most powerful and dominant feature of SQL Server database is that it

provide high level of security and data accuracy while inserting or updating data

when user work in central singular user environment, also when SQL Server used in

distributed environment when number of user are adding , deleting or updating data at

same time then it also provides same level of security and replication as it provides in

single user environment.

4.2 Software Development Process

After the completion of all steps including design, database creation and Language

selection, actual software development process start which if Programming.

This step include the following stages

 Coding

 Debugging

 Testing

4.2.1 Coding

For coding phase, we choose SQL Server 2014 foe database creation and to design

interface we choose C#.NET in visual Studio 2013. In coding phase , the developer

gives a lot a facilities while coding. It give many build-in functions such as built-in

triggers, even, procedures to run any function, facility of attach libraries where we

can use same code in many places without writing it again and protect us from coping

and pasting again and again.

41
4.2.2 Debugging

The tool selected for software development includes the facility of automatic

debugging during compilation of code. While writing new codes, functions,

procedure, alerts and other function such as adding , deleting and updating database

table, debugging facility help us to avoid writing error code and malfunctions.

So developer strong capability of debugging facility help us to perform work in

correct way.

4.2.3 Testing

The testing is considered as the backbone of software development and discussed

below with details.

4.3 Implementation Issue

Implementation means assuring operational feasibility. This mean assurance that

business tactics are performed to assure reaching business objectives. During this

stages, the software design is realized as a set of program of program units. Unit

testing is also involve verifying that each unit meet its specification.

4.4 Conversion Technique

Direct: Direct conversion means that user simply stops using the old system and starts

using the new one, a somewhat risky method, since there is no other system to tall

back on if anything goes wrong. This procedure is best followed only if the old

system is in.

42
Parallel: Two system operating at the same time so that old system continues working

till the user are satisfied that new system perform to their standards.

Phased: In this method organization ease into the new system one step at a time so

that all the user are using some of the system.

4.5 Technique to be used

The new system of works department uses direct conversion or implementation

technique. The previous system is entirely manual. It is easily switched over the new

system. Department’s work of UAJK uses this system and it facilitates both to the

department and as well as to the contractor.

4.6 Justification of technique to be used

We just direct conversion technique for Department of work over network because

the traditional system is totally manual and new system is completely automated and

network based system and these two system cannot run parallel. Secondly with the

implementation of a fully computerized system there is no need of a manual system.

It has to be omitted in order to achieve better results.

43
 CHAPTER 5

Testing Strategy

5.1 Introduction

A strategy for software testing integrates software test case design methods into a

well-planned series of steps that result in the successful construction of software.

The strategy provides a road map that describes the step to be concluded as a part of

testing, when these steps are planed and then undertaking, and how much effort,

timing and resource will be required. A software testing strategy should be flexible

enough to promote a customized billing approach. At the same time it must be rigid

enough to promote reasonable planning and management tracking as the project

progress.

5.1.1 Testing strategy used

 Unit testing beings at the vertex of the spinal and concentrates on each unit of

the software as implemented in source code.

 Integrity testing focus on the design and construction of the software

architecture.

44
  Outward on the spiral validation testing is encountered, where requirements

established as part of software requirements analysis are validated against the

constructed software.

 Finally system testing is being met, where the software and the other system

elements are tested as a whole.

5.2 Unit Testing

Unit testing focuses verification effort on the smallest unit of software design, the

software component of module. Unit testing strategy is used for testing the windows

Based system of works departments of UAJK because it is developed in modules.

Each modules is developed and tested properly making sure that they are working

properly. All the input form are tested to ensure that they are taking the valid entries

and no unauthorized access is made e.g. the input field for the name should not take

integer type value.it is also tested to make sure that it shows the desired output.

5.3 Integrity Testing

Integrity testing is a systematic technique for constructing the program structure

while at the same time conducting test to uncovers error associated with interfacing.

The objective is to take unit tested component and build a program structure

according to design.

During integration testing the focus is on design and construction of the software

architecture. Integrity testing is done to make sure that the modules are integrated to

45
the main system in a proper way and their operations are not affected during the

integration.

5.4 Regression Testing

Each time a new modules is added as a part of integration testing, new data flow parts

are established, new I/O may occur, and new control logic is invoked, these changes

may cause problem with functional that previously worked properly.

5.5 Validation Testing

Validation testing is done to ensure that requirements established as a part of software

requirements analysis are validated against the software that has been constructed.

5.5.1 Validation Testing Criteria

Software validation is achieved through a series of black-box test that documentation

conformity with requirements. The plan and procedures are designed to ensure that all

function requirements are satisfied, all behavioral characteristics are achieved, and all

performance requirement are met.

The test start by validating all those option that are design in software requirements

specification. Validity testing will be successful if the user will be able to do required

operation successfully. For example , if the administrator wants to enter records and

those are properly saved into the system then the validation testing will be successful.

46
5.6 Black Box and White Box Testing

White-box testing also called glass-box testing that use the control structure of the

procedural design to derive test case. Using white-box testing methods, the software

engineer can derive test case that grantee all independent paths within a module have

been exercised at least once, execute all loops at their boundaries bounds, and

exercise internal data structure to ensure their validity.

Black-box testing is also called behavioral testing that focuses on the functional

requirements of the software. Black-box testing enable the software engineer to

derive sets of input conditions that fully exercise all functional requirements for a

program.

Black-box testing attempt to find error in following categories.

 Incorrect or missing function

 Interface error

 Error in data structures or external data base access

 Behavior or performance error

 Initialization and termination error

5.7 System Testing

In system testing the software and other system elements are tested as a whole.

System testing is done to ensure that all the modules of the system are working

efficiently.

For example, when the administration click on view bids of tender it should work

properly and should display the desired output. Similarly all the option and features

47
provides by the system are tested one by one to ensure proper and efficient working

of the system. All the inputs of the system are validated. Security testing is ensured by

entering irrelevant data into the user login and password fields to make sure that these

fields only accept the specific data entered by the registered user.

5.7.Test Case

Table 5.1: test case to Login The System

Test Case# 1
Date of test 5 November 2018
Description Admin Login Into System
Input Admin ID , Admin Password
Expected Output Login Successfully
Actual output Login Successfully
Test Conductor Dr Lal Hussain

Table 5.2: test case to Add Teacher

Test Case# 2
Date of test 5 November 2018
Description Add Teacher
Input Teacher ID, Name, Department,

Qualification, Designation
Expected Output Teacher will be added
Actual output Teacher added
Test Conductor Dr Lal Hussain

Table 5.3: test case to Add Department

Test Case# 03
Date of test 5 November 2018
Description Add Department

48
Input Name, Faculty ,Chairman Name,

No of Program
Expected Output Department will be added
Actual output Department Added
Test Conductor Dr Lal Hussain

Table 5.4: test case to Add Conference

Test Case# 04
Date of test 5 November 2018
Description Add Conference Detail
Input Id, Name, Paper Title, Mode, Country, Type, Date
Expected Output Conference detail will be added
Actual output Conference Detail Added
Test Conductor Dr Lal Hussain

Table 5.5: test case to Add Collaboration

Test Case# 05
Date of test 5 November 2018
Description Add Collaboration Detail
Input ID, Project Title, Nature of Collaboration, Industry Name, Type
Expected Output Collaboration will be added
Actual output Collaboration Added
Test Conductor Dr Lal Hussain

Table 5.6: test case to Add Research Paper

Test Case# 06
Date of test 5 November 2018
Description Add Research Paper
Input Teacher ID, Department, Project ID, Journal Name, Paper Title,

Impact factor, volume , Date , Authorship, Page No

49
Expected Output Research Paper will be added
Actual output Research Paper Added
Test Conductor Dr Lal Hussain

Table 5.7: test case to Add Research Project

Test Case# 07
Date of test 5 November 2018
Description Add Research Project
Input Teacher ID, Department, Project ID, Project Title, Project

Amount, Funding Agency, Start Date, End Date, Status ,Type

Expected Output Research project will be added
Actual output Research Project Added
Test Conductor Dr Lal Hussain

Table 5.8: test case to Add Supervision

Test Case# 08
Date of test 05 November 2018
Description Add Student’s Supervisor
Input Teacher ID, Department , Class Name, Project Title, Status,

Year
Expected Output Supervision detail will be added
Actual output Supervision Detail Added
Test Conductor Dr Lal Hussain

Table 5.9: test case to Add Workshop

Test Case# 09
Date of test 05 November 2018
Description Add Workshop Detail
Input Title, City, Date, Teacher ID, Department, Role
Expected Output Workshop detail will be added
Actual output Workshop Detail Added
Test Conductor Dr Lal Hussain

50
 Table 5.10: test case to Add SAR

Test Case# 10
Date of test 05 November 2018
Description Add Self Assessment Report
Input Department, Program, Status, Date, Cycle No
Expected Output SAR will be added
Actual output SAR Added
Test Conductor Dr Lal Hussain

Table 5.11: test case Save Teacher Contribution

Test Case# 11
Date of test 05 November 2018
Description Save Teacher Contribution in PDF
Input Teacher ID, Department
Expected Output File will be Created
Actual output File created & Save
Test Conductor Dr Lal Hussain

Table 5.12: test case for Ranking Department

Test Case# 12
Date of test 05 November 2018
Description Ranking of Department
Input Ranking Year
Expected Output Ranking will be Done
Actual output Ranking Done Successfully
Test Conductor Dr Lal Hussain

51
 CHAPTER 6

Conclusion and Future Work

6.1 Achievements

During the development of the project we have achieved the following benefits.

 Project management and scheduling

 How to interact with the user

 System analysis and data collection

 A good knowledge of system designing and modeling

 Latest tool and technique

 Testing Strategies

 User documentation

6.2 Limitations

The software is developed keeping in view the development oriented requirement of a

final year project. So it may lack some elegance or sophistication. It is designed

specifically for UAJK. However, it may be enhanced or replicated in other

Universities of Pakistan.

52
6.3 Future Work

The due course of time as we started our work understand the minute details of our

work, we significantly realized that our software would be tremendously important in

the future world. Our project “Annual Internal Departmental Ranking System”

will be able to implement in future after making some changes and modifications.

Similarly, Various modification can be done to enhance the usability of the given

project as suitable for user’s requirements.

6.3.1 Software as its Best

The Pros of our software are as below:

 The software is reliable because it produce accurate result and there is no

probability of loss of data.

 The software is user friendly; because its design is made as user friendly as

possible, keeping in mind the diversity of its users.

 The software has all of the helping aspects that are covered while developing

the software, so its comes with a complete helping text.

 The software also generate proper error message for the convenience of the

user. This enable the user to interact more easily with the software.

 The rate of error is considerably reduced as forms and reports are used and

data validation checks that have been provided to ensure the correct storage

information.

 The system is secure, fault tolerant and efficient.

53
SNAP SHOTS
Login

Guest User Interface

54
55
Home Page

Teacher Form

56
Department Form

57
Conference Form

Collaboration Form

58
Research Paper

Research Project

59
Supervision

Workshops

60
Accreditation

Self Assessment

61
Student Teacher Ratio

View Records

62
Ranking Result

Teacher Contribution

63
Teacher Contribution Result

Reports

64
About Us

65
CONCLUSIONS & RECOMMENDATIONS

Annual Internal Departmental Ranking System is not only rewarding but it also helps

the programmer to quickly organized the Research events and Rank of department in

short interval of time. I personally see this as a great way to find even more

information for my topic. It will be able to check anything related to Research and

Ranking of department at any time. Paper work and manual work is reduced through

this system. This system is user friendly and easy to use. I hope that user would not

only enjoy this system, but also get satisfaction from finding how each and every

thing of ranking is implemented.

66
REFERENCES

We have studies books to make this language understandable and then we learn this

language with the guidance of videos tutorials and PDF documents, many of the sites

played also a key role in the development of the project. We got help especially from

our teachers and universities fellows.

Some most remarkable sites from where we got much help are as followed.

WEB Sides:

www.google.com

www.w3schools.com

www.wikipedia.com

www.stackoverflow.com

www.youtube.com

www.github.com

Books

Introduction to Programming using C#.NET

Introduction to Database Management System.

67