DILLA UNIVERSITY PROPERTY ADMINISTRATION AUTOMATE SYSTEM

PREPARED BY: CHERE LEMMA ESKINDIR DEMELASH MERON TESHOME ZEMENU AGUMAS ZERIHUN TADESSE RCS 015/08 RCS 021/08 RCS 034/08 RCS 052/08 RCS 054/08

PROJECT ADVISOR: Mr. TILAHUN MELAK (MSc.)

PROGRAM OF COMPUTER SCIENCE SCHOOL OF MATHEMATICAL AND COMPUTER SCIENCE DILLA UNIVERSITY

January 2012 Dilla, Ethiopia

1. Introduction
1.1 Background Dilla University is one of governmental higher educational institute in Ethiopia.
Property Administration is one part of DU which has the mission of properly managing and controlling every property of the University to facilitate the education process run inside the University. It was established in October 28, 1989E.C. Even though there was a gradual change from time to time, until now there are problems and still the system almost all runs manually and partially use Microsoft Access. As result, it is slow and prone to errors.

1.2 Statement of the problem

Lack of immediate information storage Lack of immediate report generation Lack of immediate data retrievals Lack of data security Lack of updating record about the property Difficulties of controlling inflow and outflow goods

1.3 Objectives of the project

1.3.1 General objective Developing automated property administration system of Dilla University 1.3.2 Specific objectives To make the system to have immediate information storage To allow immediate data retrievals To make the system to be more secure To provide ways of updating record about the property To reduce time, manpower and other resources required To make easy the controlling process of inflow and outflow goods

1.4 Purpose of the project

The proposed system will have a centralized database. So it increases the reliability and efficiency of the system. The database will be accessed by using interactive and user friendly GUI. It will provide user privileges to keep the records secured and safe. It will provide a means for records to be stored in organized way. It will provide way of report generation timely. It will provide an easy way to store, retrieve, update property record and perform related processes. It will reduce manpower required. It will reduce the cost that is spent for resources which are used for different tasks and man power.

1.5 Scope of the project

This project will be limited on developing a new automated property administration system. Registration of inflow and outflow goods (properties) Checking the availability of goods in the store for current request of user Registration of user Calculating the balance of inflow and outflow of goods Controlling the expiration date of exhaustive goods Generating report about properties and users when necessary

1.6 Methodology
1.6.1 Data gathering techniques An interview : We use this technique to allow the informants to respond in any manner and the interviewers to observe verbal and non-verbal behavior of the respondents. Observation : we conducted physical observation to see how data are handled and information of property kept in the system. Secondary document analysis technique to review various documents. 1.6.2 Design Methodology Object oriented approach

1.6.3 Implementation Methodology A) Hard ware: Desktop computer with 500MB RAM and above as well as 80GB Hard Disk Device and above to install different software we use to develop the system. Network cable, CD and Flash disk to take backup B) Software: Front end: - VB.Net 2008 Back end: - SQL server 2002 Documentation: Adobe Photoshop, Star UML, MS office 2007

1.6.4 Testing Methodology

A) Unit testing
We use this testing technique to verify the functionality of a specific section of code, usually at the function level.

B) Integration testing we use this testing method to verify the interfaces between components against a software design.

C) System testing This another technique we use by completely integrating the system to verify that to ensure if it meets its requirements. Alpha testing: is simulated by the developer of the system Beta testing: is stimulated by clients

10

2. Requirement Analysis Description 2.1 Overview of the existing system

DUPA is one of the main departments of DU that handles its day-to-day activities to give service for the community of the University. But still these activities are done by using traditional manual handling of files. 2.1.1 Activities of the system Store keeping Registration of inflow goods , outflow goods and user Coordination and management Calculating balance Preparing user profile Categorizing goods and Assigning Identification Number
11

2.1.2 Problem of Existing System Security Problem Time wastage Manpower Balancing Problems Lack of Immediate data retrieval Lack of immediate updating of record about the property

12

2.1.3 Weakness and strength A) Weakness: There is no available organized document that shows work flow of the system Security problem Work load and time consumption Less satisfaction of users by the service they get B) Strength: To make auditing easy, they use Bin card Give receipt for customer when issuing goods and return goods after usage Cross check request of user with their proposal Use decentralized management system for controlling and ensuring the proper uses of the properties
13

2.1.4 Business Rule Every goods/properties of the University must be registered If the head of department allows and signs, any staff member has the right to withdraw Non-exhaustive goods. Only head of department or secretary have the right to withdraw exhaustive goods. If user loses the property he/she pay based on duration of service of the goods When properties are loaned if the borrowed bodies do not return the goods within specified date they shall penalized 50 Birr per day. When user leaves the University he/she shall return any Non-Exhaustive goods

14

2.2 Overview of the proposed system

2.2.1 Functional Requirement

Recording proposal Registration of inflow goods, outflow goods and user Checking availability of goods in the store Calculating balance of inflow and outflow of goods Searching , Updating and deleting records when necessary Generating report when necessary Controlling return date of loaned and expiration date of exhaustive goods and alarming Enable the Head (Administrator) to know activities of Recorder on daily basis Restrict unauthorized person from accessing the system
15

2.2.2 Non-Functional Requirement User Interface Timeliness: The software helps to give timely information for the user. Error Handling: Security issues Quality Issues System Modifications Resources Management Issues 1. Backups: It should be undertaken on a daily basis 2. System Installation: Project team will be responsible for the installation 3. System Maintenance: System administrator will be responsible for this task
16

2.2.3 Systems Requirement 1) Hard ware requirement Processor: - with speed of greater than 3.0GHz 1GB RAM and above 150GB Hard Disk Device (HDD) and above to for data storage Printer 2) Software requirement Operating system: - Windows XP/2000 and any higher version Microsoft SQL server 2005:- for data base storage

17

3. Constraints and Assumptions

3.1 Constraints A) End product constraint: is the limitation of end product of this project GUI support only English alphabet and Arabic and Roman number Authentication in to the system is only available for the staff of DUPA The system is run only for DUPA system B) Project development Constraint Lack of available written documents about the work procedure Shortage of resource such as laboratory Lack of advanced experience Lack of efficient review related literature

18

3.2 Assumptions It is assumed that compatible computers will be available before the system is installed. It is assumed that the DUPA will have enough trained staff to take care of the system The users have sufficient knowledge of computers. The users know the English language, as the user interface will be provided in English The product can access the university purchase system database

19

4. System Modeling
4.1 Use case Diagram
System
Returned goods Registiration Non-Exhaustive goods

<<extend>>
Purchased goods Registiration

<<extend>>
Exhaustive goods

<<extend>> <<extend>>
Inflow goods Registiration Donated goods Registiration

<<include>>
Recording Proposal Borrowed goods Registiration

Organization

<<include>>
Login Loaned goods Registiration Recorder Update record

<<include>>

<<include>>

<<include>>
Inservice goods Registiration

Auditing Outflow good Registiration

<<include>> Auditor

Exhaustive good Registiration

Employee

User registration

Fig 4.1: Use case Diagram One

20

Use case Diagram contd.

System

Backup Dat a base

Cleanrance Employee

<<include>>
Search Recorder

<<include>>

<<include>>
Report generat ion

Login

<<include>>

View Notification

<<include>> <<include>>

User account

Head

Cross checking proposal

Fig 4.2: Use case Diagram Two

21

4.2 Sequence Diagram

Login form
: Head : Recorder enter username and password()

Login btn

Login control

Main window

submit() create()

submitted() validate()

x
View()

X
create()

22

Sequence Diagram contd

Proposal Button : Recorder Proposal Control Proposal form Proposal T able Acknowledgement

click() create() create()

x
fill() submit() submitted()

Validate() Record_Stored() Create()

view()

23

Sequence Diagram contd

E-Inflow dropdown menu : Recorder E-Inflow dropdown ctrl Dropdown list E-Inflow Reg. form Database

Message

click()
create()

create() select()

selected() create()

x
fill() submit()

submitted() validate() store_record() create() view()

X x
24

Sequence Diagram contd

: Head : Recorder

Sreach Button

Search control

Search form

Table : Record

Record

click() create() Create()

Insert search key() submit()

x
submitted()

X
Validate() fetchrecord() dispaly() view()

X X
25

Sequence Diagram contd

Update Button : Recorder click() create() create() Update control Update form Table : Record Acknowledgement

fill() submit() submitted() Verify() Updated() create()

view()

26

Sequence Diagram contd

: Head

Notification Button

Notification control

Database

Notification

click() create() fetchrecord()

x
dispaly()

view()

print()

X
27

4.3 Class Diagram

PROPERTY ADMINISTRATOR +User Name: String +password: String +User Type: String +login()

HEAD +1 Manage USER ACCOUNT +1

RECORDER +1 Register 1..* +getCreate() +getChange() +getRemov e() GOODS +Item Name: String +Serial: String +Item Rank: String +Item Description: String +Balance: Integer +Unit Price: Double +Total Price: Double +Measurement: String +Quantity: Integer +getRegister() +getUpdate() +getSearch() +getDelete() +Calculate_balance() PURCHASED NON EXHAUSTIVE GOODS PURCHASED INFLOW EXHAUASTIVE GOODS +Expeired Date: Date

cross check

1..*

PROPOSAL +Department name: string +Item Name: string +Item Type: string +Quantity: Integer 1..* +Balance: Integer +Acadamic Year: Integer +Calculate_ balance() +getRecord() +getSearch() +getDelete() +getUpdate() OUT FLOW GOODS +Date Out: Date +Quantity out: Integer

Record

OUTFLOW NON EXHAUASTIVE GOODS +ID No.: String +Remark: String +Serv ice duration: Integer

OUTFLOW EXHUASTIVE GOODS INFLOW GOODS 1..* +Date in: Date +Quantity in: Integer

+Category No.: String

Withdraw +1 INSERVICE GOODS 1..* Withdraw +1 USER(EMPLOYEE) +User Name: String +User ID: String RETURNED GOODS +Position: String +Departement: String +ID No.: String +1 Return +Address: String +Remark: String 1..* +Serv ice Duration: String +Goods ID: String +Education Lev el: String +getRegister() +getSearch() +getDelete() 1..* Loan Donate DONATED GOODS +Experied Date: Date 1..*

LOANED GOODS +Return date: Date

1..* Borrow +1 ORGANIZATION +Organization +Organization +Organization +Organization Name: String Type: String Address: String +1 location: string

BORROWED GOODS +Category No.: String +Return date: Date

+1

28

5. System Design
5.1 Design Goal The following goals were kept in mind while designing the system: Make system user-friendly Security Performance (Response Times) Usability (Human Factor) Reliability (Frequency of Failure) Timeliness Reducing error System Modifications

29

5.2 System Decomposition

Dilla University Property Administration Automate System

<<Subsystem>> Administration Subsystem

<<Subsystem>> Edition Subsystem

Record

<<Subsystem>> Registration Subsystem

<<Subsystem>> Information Subsystem

<<Subsystem>> Control subsystem

Application

<<Subsystem>>

Database Subsystem

Figure 5.1: General Subsystem Decomposition of the system

30

5.3 Deployment Diagram

User Interface
Administiration

Application

Database

Registiration Application Control DUPA Database

Record Edition

Information

Figure 5.2: Deployment Diagram (One tier architecture)

31

5.4 Persistence Data Management

More than anything data is precise resource and need effective management and handling. Information regarding goods, User account, users and other data stored persistently in Relational Database by Recorder and Head. In RDB data is stored in tables and the relationships among the data are also stored in tables.
Returned goods Non-exhaustive purchased goods pk Category no Item description Item rank Item category Measurement unit Quantity in Date in Unit price Total price Whole price Balance Exhaustive purchased goods Item description Item category Item rank Measurement unit Date in Quantity in Total quantity in Unit price Total price Whole price

User Account Pk User Name User Type Pass word

Pk

Goods IdNo Item description Item category Item rank Measurement unit Quantity in Total quantity in Date in Durability Balance Remark

32

Donated goods Fk Organization name Date in Item description Item category Measurement unit Unit price Total price

Organization pk Organization name Organization type Location User Id User name Department Position Sex

Loaned goods pk good IdNo Fk Organization name Item description Item category Measurement unit Quantity out Date out Unit price Total price In-service goods Pk ID No(serial) Fk User ID Item description Item category Measurement unit Quantity out Date out Status Pre-service duration Unit price Total price
33

Borrowed goods
pk Fk good IdNo Organization name Item description Item category Measurement unit Quantity out Date out Unit price Total price

Address Outflow exhaustive goods Fk User ID Item description pk Item category Measurement unit Quantity out Total quantity out Date out Unit price Status Pre-service duration Total price

User user ID User name Department Education level Position Sex Address

5.5 Access Control and security

Actors Inflow record goods outflow record Login() Head Search() View() Search() View() Search() View() Create() Change() Remove() goods User record User account Proposal record Update() Delete() Read() Register() Backup() Generate() View() Print() Database Report

Update() Search() Update() Recorder Delete() Register() View() Search()

Update() Search() Login()

Update() Search() Delete() View() Register()

Generate() View() Print()

Delete() View() Delete() Register() View() Register()

Auditor

View()

View()

Access control matrixes for DUPA system access control model

34

5.6 User Interface Design Login window Proposal record window Exhaustive inflow goods registration window Exhaustive outflow goods registration window Non-exhaustive inflow goods registration window This includes purchased goods , Returned goods, Borrowed goods and Donated goods registration window Non-exhaustive outflow goods registration window This includes Loaned goods and Inservice goods registration window User Administration window Search window Delete window Update window
35

THANK YOU!!!!!

36