WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

SOFTWARE ENGINEERING DEPARTMENT

ON
“PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM
FOR CCI”
By

Student Id
Samuel Bedane CIR/388/07
Aklilu Iyasu CIR/043/07
Wubete Gobeze CIR/491/07
Shumitu Bejiga CIR/413/07
Gemechis Nesha CIR/204/07

UNDER GUIDANCE OF
ADVISOR Mr. Eyuel Ajebu

Wolkite University, Wolkite, Ethiopia.

February, 2018
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Acknowledgment
First of all, we would like to thank God for helping us. Secondly we would like to express our
deepest gratitude to our advisor Eyuel Ajebu. He always motivated and criticized us to do
something extraordinary. Respectively, we would like to thank other people give the
information about how to store the project flows up and repositories management system of
CCI. Finally, we would like to thank our parents for giving us their constant and precious
guidance, moral support and motivation during the course of completion of our project.

i
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Abbreviation, acronyms and definitions

BR ------------------------------Business Rule
CCI------------------------------------------- College of Computing and Informatics
CPU-------------------------------Central Process Units
CS6---------------------------Adobe Creative Suit 6
CSS---------------------------------------------------Cascading style sheets
DBMS-----------------------------------Database Management System
ETB---------------------------------------------------Extended Trial Balance
IDE----------------------------------------Integrated Development Environment
MySQL--------------------------------My Structured Query Language
MS word 2016 --------------------------------------Micro-soft office word
OOA ------------------------------------------------ Object-Oriented Analysis

PHP--------------------------------------------------------Hypertext Preprocessor
PDF---------------------------------------------Portable Document Format
PFRMS------------------Project Flows up and Repositories Management System
RAM -----------------------------------------Random Access Memory
RSC & IL---------------------------Roll Stability Control and Information Literacy
RSD---------------------- ------------------Requirement Specification Document
UC------------------------- ---------------Use case
US--------------------------------------------Use Case Scenario
URL---------------------------------- -Uniform Resource Locator.
UML---------------------------------------------Unified modeling language
WKU--------------------------------------------------Wolkite University

ii
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Abstractions
This final year senior project is done for the partial fulfillment of B.sc degree in department of
Software Engineering to graduate. Now a day’s CCI Office works are done in manual while
some of them are performed using automated system. PFRMS runs its activities using manual
process and we are initiated to change this manual working into automated web based
application to minimize the major problems found in the office and, student in this colleges
have more problems regarding to the final project work descriptions. We have clearly identified
the problems that face the office and the students using different data gathering methodologies
and tools. The project is developed by using Php programming language for the front end of
the application and MySQL database system for the back end. Other Html and java script client
side scripting languages are used. The newly automated system provides fast and reliable
service for the office employees and students by minimizing time and resource wastage. Our
project identifies the weakness of the existing system and by highly investigating the problems
of the existing system the document has clear and concise solutions for those problems. Under
this document we specify the functional and non-functional requirements of the system and by
carefully applying the functional requirements users can get quality service from the newly
Automated system.

iii
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Table of Contents Page

Acknowledgment ..................................................................................................................................... i
Abbreviation, acronyms and definitions ................................................................................................. ii
Abstractions ........................................................................................................................................... iii
List of tables .......................................................................................................................................... vii
List of Figure ......................................................................................................................................... viii
Chapter One: Introduction of whole project process ............................................................................. 1
1. Introduction ......................................................................................................................................... 1
1.1. Background of the project ........................................................................................................... 1
1.2. Statement problems of the project ............................................................................................. 2
1.3. Team composition for the project ............................................................................................... 3
1.4. Objective ...................................................................................................................................... 3
1.4.1. General Objectives of the project ......................................................................................... 4
1.4.2. Specific Objectives of the project .......................................................................................... 4
1.5. Functional and non-functional requirements .............................................................................. 4
1.5.1. Functional requirements....................................................................................................... 4
1.5.2. Non-functional requirement ................................................................................................. 6
1.6. Scope and limitation .................................................................................................................... 7
1.6.1. Scope ..................................................................................................................................... 7
1.6.2. Limitation .............................................................................................................................. 8
1.7. Significant and Target beneficiary of the system ......................................................................... 8
1.7.1. Significant of the project. ...................................................................................................... 8
1.7.2. Target beneficiaries............................................................................................................... 8
1.8. Methodology of the Project ......................................................................................................... 9
1.8.1. Data Collection/Gathering Methodology.............................................................................. 9
1.8.2. Data Analysis Methodology .................................................................................................. 9
1.8.3. Implementation methodology ............................................................................................ 10
1.9. Feasibility analysis ...................................................................................................................... 10
1.9.1. Operational feasibility ......................................................................................................... 10
1.9.2. Technical feasibility ............................................................................................................. 11
1.9.4. Political feasibility ............................................................................................................... 11
1.10. Budget and scheduling ............................................................................................................. 11
1.10.1. Budget ............................................................................................................................... 11
1.10.2. Schedule ............................................................................................................................ 11
1.11. Document organization ........................................................................................................... 12
Chapter Two: Description of the existing system ................................................................................. 13

iv
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2. Introduction ...................................................................................................................................... 13
2.1. Organizational structure ............................................................................................................ 14
2.2. User of the existing system ........................................................................................................ 15
2.3. Major function of the current system........................................................................................ 15
2.4. Existing system workflow structure ........................................................................................... 17
2.5. Report generated in the existing system ................................................................................... 18
2.6. Forms and other documents of the existing systems. ............................................................... 19
2.7. Bottlenecks of the existing system ............................................................................................ 19
2.7.1. Performance........................................................................................................................ 19
2.7.2. Input and output ................................................................................................................. 20
2.7.3. Security and control ............................................................................................................ 21
2.7.4. Efficiency ............................................................................................................................. 21
Chapter Three: Proposed System ......................................................................................................... 22
3.1. Introduction to proposed system .............................................................................................. 22
3.2. Business rules ............................................................................................................................. 23
3.3. Functional requirement ............................................................................................................. 24
3.3.1. Input related requirements ................................................................................................ 24
3.3.2. Process requirements ......................................................................................................... 24
3.3.3. Output related requirements ............................................................................................. 25
3.3.4. Storage related requirements............................................................................................. 25
3.4. Non-functional requirements .................................................................................................... 26
Chapter Four: System Analysis ............................................................................................................ 28
4.1. Scenarios .................................................................................................................................... 28
4.2. System model............................................................................................................................. 30
4.2.1. User class and characteristics (actor identifications).......................................................... 30
4.2.2. Use case diagram ................................................................................................................ 31
4.2.2.1. General use case diagram ............................................................................................ 32
4.2.2.2. Detailed diagram and description of each use case .................................................... 34
4.2.3. Object model....................................................................................................................... 51
4.2.4. Class Diagram ...................................................................................................................... 51
4.2.5. Sequence Diagram .............................................................................................................. 53
4.2.6. Activity Diagram .................................................................................................................. 58
4.2.7. State Diagrams .................................................................................................................... 65
Chapter Five: System Design ................................................................................................................. 71
5.1. Introduction ............................................................................................................................... 71
5.2. System overview ........................................................................................................................ 71

v
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

5.3. The Design Consideration .......................................................................................................... 72

5.3.1. The Design Goals ................................................................................................................. 72
5.3.2. The Design Trade-Offs......................................................................................................... 74
5.4. The Architecture of the Proposed System ................................................................................. 75
5.4.1. Sub-system Decompositions ............................................................................................... 77
5.4.2. Deployment Diagram .......................................................................................................... 79
5.4.3. Persistence data management system ............................................................................... 80
5.4.4. Class Interface ..................................................................................................................... 85
5.5. User interface............................................................................................................................. 93
Conclusion ............................................................................................................................................. 97
References ............................................................................................................................................. 98

vi
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

List of tables
Table 1: Team composition ....................................................................................................... 3
Table 2: Target beneficiary ........................................................................................................ 8
Table 3: Budget for hardware tools ......................................................................................... 11
Table 4: user or existing system............................................................................................... 15
Table 5: Business rule .............................................................................................................. 23
Table 6: User class and characteristics: ................................................................................... 31
Table 7:general use case dicrptions ......................................................................................... 38
Table 8: schedule use case descriptions ................................................................................... 39
Table 9: generate report use case ............................................................................................. 40
Table 10: View report use case descriptions............................................................................ 41
Table 11: Post notification use case ......................................................................................... 41
Table 12: Send data use case descriptions ............................................................................... 42
Table 13: Inbox use case descriptions ..................................................................................... 42
Table 14: generate letter use case descriptions ........................................................................ 43
Table 15: View sent use case descriptions ............................................................................... 43
Table 16: Update file use case descriptions ............................................................................. 44
Table 17: Add file use case descriptions.................................................................................. 45
Table 18: Search use case descriptions .................................................................................... 45
Table 19: Form group use case descriptions ............................................................................ 46
Table 20: Download file use case descriptions ........................................................................ 46
Table 21: View descriptions use case descriptions .................................................................. 47
Table 22: View notification use case descriptions ................................................................... 48
Table 23: Change profile use case descriptions ....................................................................... 48
Table 24: Login use case descriptions ..................................................................................... 49
Table 25: View information use case descriptions .................................................................. 49
Table 26: Logout use case descriptions ................................................................................... 50
Table 27: Create account use case descriptions ....................................................................... 50
Table 28: Delete Account use case descriptions ...................................................................... 51

vii
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

List of Figure
Figure 1: schedule in Gantt chart ............................................................................................. 12
Figure 2: Organizational structure ........................................................................................... 14
Figure 3: Existing system work flows ..................................................................................... 17
Figure 4: Report generating existing system ........................................................................... 18
Figure 5: Form and other document for existing system ......................................................... 19
Figure 6: General use case diagram for PFRMS ..................................................................... 32
Figure 7: general use case b for PFRMS ................................................................................. 33
Figure 8:Schedule use case ...................................................................................................... 34
Figure 9: Create account use case ............................................................................................ 35
Figure 10:generate report ......................................................................................................... 35
Figure 11: Generate letter use case .......................................................................................... 36
Figure 12: Add deadline use case ............................................................................................ 36
Figure 13: Class diagram for PFRMS ...................................................................................... 53
Figure 14: Login sequence diagram ......................................................................................... 53
Figure 15:.Form group sequence diagram ............................................................................... 54
Figure 16: Evaluation sequence diagram ................................................................................. 55
Figure 17: Create account sequence diagram .......................................................................... 56
Figure 18: Post file sequence diagram ..................................................................................... 57
Figure 19: Generate report sequence diagram ......................................................................... 58
Figure 20: evaluate task activity diagram ................................................................................ 59
Figure 21: Add new task activities diagram ............................................................................ 60
Figure 22: Generate weakly report activity diagram ............................................................... 61
Figure 23: Generate letter activities diagram ........................................................................... 63
Figure 24: Form group activities diagram ............................................................................... 63
Figure 25: Add file activities diagram ..................................................................................... 64
Figure 26: Update activities diagram ....................................................................................... 65
Figure 27: Login system state diagram .................................................................................... 66
Figure 28: Create account state diagram .................................................................................. 67
Figure 29: Inbox state diagram ................................................................................................ 68
Figure 30: Delete account state diagram .................................................................................. 69
Figure 31: Change profile state diagram .................................................................................. 70
Figure 32: system overview ..................................................................................................... 72
Figure 33: shows three tier of architecture of the system ........................................................ 75
Figure 34: Three-Tier architecture in deployment ................................................................... 76
Figure 35: subsystem decomposition for PFRMS ................................................................... 78
Figure 36:deployment diagram for our project ........................................................................ 80
Figure 37: database design ....................................................................................................... 81
Figure 38:perisitance data management class mappings ......................................................... 84
Figure 39:Home page user interface ........................................................................................ 93
Figure 40:Generate new letter user interface ........................................................................... 94
Figure 41:Create account user interface .................................................................................. 94
Figure 42:Generate report user interface ................................................................................. 95
Figure 43:Upload file from the system user interface ............................................................. 95
Figure 44:Repository user interface ......................................................................................... 96
Figure 45:Generate letter user interface ................................................................................... 96

viii
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Chapter One: Introduction of whole project process

1. Introduction
The project flows up and repository managing system has been developed to handle the problems
prevailing in manual system. This system will support to eliminate and, in some cases, reduce the
hardships faced by the existing system. Moreover, this system is designed for the particular need
of the college to carry out operations in a smooth and effective manner. The system is reduced as
much as possible to avoid errors while data is flow in the system. Thus, by this all it proves it is
user-friendly. Project flows up and repository managing system, as described above can lead to
error free, secure, reliable and fast management system. It can assist the user to concentrate on
their other activities rather to concentrate on the record keeping. Thus, it will help organization in
better utilization of resources.

The main modules of the projects are group of student module, which performs all the operations
related to student such as create account, submit project, search the previous title, view and
download the previous projects and report submission about their weekly progress.

The advisor module, which performs the operation related with advisor like create account, report
the student weekly progress, communicate with students, give recommendation to the student
project progress, sign to the document. The department module which performs the operation
related with account create, receive project title, reply notification to the students, evaluate the
project title, formulate schedule for defense, assign advisor for the student and formulate student
group. The college module which performs a task related with create account, receive and evaluate
the project title if they are passed from dep’t, make it pass, reject and pend the project title and
proposal, forward it to the department, post project proposal template and final documentation
template and assign the examiner for the final project documentation. The Examiner module which
perform the operation related with such as account create, examine project and evaluate it, report
the result to department.

1.1. Background of the project

College of Computing and Informatics is one of the major college which is found in Wolkite
University. It is established when the university has been started to enrolls students and teaching

1
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

them in 2004 E.C. In College of computing and informatics there are four departments. At the first,
three departments established first when the college has been started to enroll students, but
software engineering department is started after one year at 2005 E.C. Currently four departments
are found:

 Department of Software engineering

 Department of Computer Science
 Department of Information System
 Department of Information Technology

In College of Computing and Informatics graduating students submit their project title manually
by coming to office. And student also has no idea about the previous project title. Selected one
projects are, the college project manager also views all the previous title in order to approve the
current project title of graduating students. The project proposal also submits to the department
and advisor using paper. The department head also submits the student project documentation by
face to face communication to the college administrator. Assigning advisor and examiner is also
by using letter paper format and fill a form by department and college. The project documentation
is stored on the shelf and most students are not able to get as a reference.

1.2. Statement problems of the project

College of CCI has not been used a project flow up and repository managing system. Currently,
the college use a system that controlled or manipulated by a human operator (not automatically,
such as by a computer) to manage flow up and store student graduation project paper and
graduation papers are not publicized for the students as they want.

As we have observed, there is no research that indicates those problems but as we have tried to
investigated this Controlled or manipulated by a human operator (not automatically, such as by a
computer) at the university has identified the following problems.

 Time and space consuming: In hand-operated system the flow up process is slow since
it requires much stake holders meeting. And also paper is store in the shelf and a user
cannot get the paper easily. When the papers are increase in number it takes much time
to find and also its take more space in the shelf.

2
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Based on paper circulation: To perform different activities, paper is generated at each

process steps which consume resources and man power.
 Unable to find project related papers: In hand-operated system the project paper may
lost through stolen by thief, the store may be damaged or destroyed by man-made or
natural disaster.
 The project paper not disseminate: the project paper not distribute too many
people. The availability of the project paper is limited to the university compound as a
result of the existed hand-operated system. So the user cannot see the project paper in
different media like internet.
 Final documents are not publicized: In College of CCI Proposal papers, and research
papers are not publicized for the student to assess themselves.
 Data redundancy: currently the same titles are submitted and asks to check and filtrate
it.

1.3. Team composition for the project

The project team has 5 members for the accomplishment of the Project Flows up, and Repository
managing system for CCI. Generally, the task of each member can be expressed in the table below;

Project Flows up, and Repository Managing System (PFRMS) for CCI
No Student name Student id Work composition
1 Samuel Bedane CIR/388/07 Programmer
2 Wubete Gobeze CIR/491/07 Designer
3 Aklilu Iyasu CIR/043/07 Data gathering
4 Gemechis Nesha CIR/204/07 Data gathering
5 Shumitu Bejiga CIR/413/07 Type writer
Table 1: Team composition

1.4. Objective

We put general and specific objectives for what we develop this project and to clarify our final
goal.

3
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

1.4.1. General Objectives of the project

Project is intended to automate managing current semi manual system and to develop web-based
system to riposte data’s and information.

1.4.2. Specific Objectives of the project

The aim of this project is to help CCI colleges to manage information and to serve it for users in
the university by developing the following specific objectives in one side.

 Analyze the current systems exists in the college in order to have further information.
 Distinguish and identify an action to be taken for problem solving.
 Apply software process with software practice in order to develop and approve an
application and system.
 To manage flow up process in project management.
 To manage the resources like projects and research papers in the university.
 Develop database in order to has an efficient storage system and resource reusability.
 To prevent users from waste time and resources, by using internet-based system to get
information’s.
 To give effective and efficient service for the user’s and administrators (both sides).

1.5. Functional and non-functional requirements

1.5.1. Functional requirements

Functional requirements are tasks done by the system and application through graphical user
interface. This group of requirements have functionalities that the system should support for the
users.

Student user functionality

Student users perform functionality with limited access after login to system. And there is public
and private access to information and data’s.

Some of those functionality: -

 Search and filter data’s, we want.

 View all permitted papers like projects papers from system store.

4
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Download papers.
 Submit titles and proposal.
 View new sent messages or announcements from department or from his/her advisor.
 Sign on weekly report papers that generated from their advisor.
 View notification that released on their accounts as private access.
 Send and reply messages to their advisor as a means of communication.
Instructor functionality
As advisor user
Advisor user is advisor in the college. Some of functionality:

 View message and different paper sent from department including for whom group he/she
assigned.
 Generate weekly reports and submit to department.
 Download data sent from student.
 Upload and send comment or advice on project for student group.
 Finally approve and sign for final project accomplishment and send to department with
comment.

As Examiner user
Examiner user perform an examine student group and put down the result of assessment.

 View message and different paper sent from department including for whom group he/she
assigned. Message may include time, place, proposal, documents, and list of groups.
 Download data and print a sent document.
 Search and download title related previous projects from server if existed, to compare with
currently working on.
 Send feedback and assessment result sheet with sign to department. Result sheet may
contain date, time, signature, and real assessment result from defense presentation.

Department Head user functionality

Department Head user is head of department. Department head manages works at department
levels.

 Formulate students into groups.

5
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Download titles and proposals sent from each group of students.

 Schedule or assign advisors and examiners for each group.
 Generate letter and sent to advisor and examiner in order to announce them. Paper may
contain list of groups, their section, and at list three titles.
 Post templates for whole groups if project title is done at department level.
 Send information to announce each group of students what is their advisor, examiner,
scheduled time and date, title or proposal is approved or rejected, and so on.
 View all inboxed, file, and information that sent from system stake holder.

College user functionality

This user is represented by one coordinator for all department in the college level. And participate
in the process if project work at the college level.

 Filter out title and proposal to make sure there is no data redundancy. Delete if happen.
 Assign examiner for each group of students in the college and send to each department.
 Post out templates and new information regards to project held in the colleges.
 Repos it and store final project documents, by uploading and adding it to the server database.
The process of uploading data may contain title of project, date, short description, name of
advisor, result and comment of the project, year, department and who did the project.

1.5.2. Non-functional requirement

Non-functional requirements define the overall quality or attributes of the resulting system. it
identifies and place restriction on the system being developed, the development process, and
specify external constraints that the system must reach.

 Information: information requirement represent that is pertinent to the user in terms of content,
accuracy and format. When we say

 Accuracy: mean that we can get right information at right time.

 Economic: a good system reduces the cost and we can get maximum benefit with minimum
time and minimum resource.

 Security: this system has very secured due the username and password for administrative
activity.

6
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Efficiency: the system is very fast in terms time and space and has capability storing high data.

 Control: nobody can access the database without the permitted person with respective data.

 Services: the system must have its own ways that makes reliable and flexible.

 Performance requirement: the system most host many users at same time with remote distance

 Usability: Easy to understand and user friendly and provides some training on the site for
students.

 Reliability: the system provides to the user correct information. When the user entered wrong
inputs, it notifies to correct the input data.

 Performance: the system has performed all operation through single pressing button it response
in short period of time.

 Maintainability: the system is maintainable to improve the ability and it is non-functionality.

1.6. Scope and limitation

1.6.1. Scope
This project is going to solve the problems occur in existing system by following tasks. The system
will provide service where our website can be accessed to the user.

The system authenticates the college admin, advisor, examiner, and department heads, and
students by matching the User ID and the password.
 Submit data’s: student user submits different data related to project and research.
 Generate report: user generates various reports.
 Upload information: admin upload to store data’s and information on the server.
 Update information: the information or data’s will be updated when the detail is needed to
be add, extra information added over the current title.
 Delete information: the admin can also delete information titles when the data is not correctly
uploaded due to data redundancy and when the title is not being describe the detail.
 Retrieve information: user can retrieve and list out data they searched.
 Select the category: users can select category in order to see the specific information related
with what the user select from the category.
 View sent information: user can see information sent from system stake holders.
 Scheduling and assignation: department or college can schedule and assign examiners.

7
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Download the data: user have permission to download data’s and information from the server
through media page.
 Maintain the system app: the system administrator can have a right to change the color of
the web-app page and the icons that is viewed over the user’s side.

1.6.2. Limitation
Some limitation of this project are:

 The proposed system is not accessed by blind people.

 The system Reposit data based on CCI curriculum.
 Users can not access beyond the limits.

1.7. Significant and Target beneficiary of the system

1.7.1. Significant of the project.

 It minimizes load of work, saving time and spaces.
 It improves quality by giving appropriate information.
 It provides a fast access for the student.
 It addresses and avoid the loss of documents.
 It can able to make easy to search and find the desired information.

1.7.2. Target beneficiaries

Targeted Persons Benefits
System users  Save time
 Get sufficient information
 Effectiveness

College of CI  It minimizes load of work.

 To improve the quality of service
 Save money-out for paper, printer ink, pens, and etc.

Developers  Knowledge
 Experience
 Promotion
 BSc degree award.

Others  Inspiration

Table 2: Target beneficiary

8
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

1.8. Methodology of the Project

1.8.1. Data Collection/Gathering Methodology

The project we proposed will be started using requirements elicitation technique. The software
process that we will be using is object orientation development approach type.

When eliciting requirements, we will follow those steps.

1. Observation: We have to observe physically by going to the place. Also, the team will
see that what system they use for work.
2. Literature review: This technique provides information on how the existing system
works. There for documents related to the existing system of the organization will be
assessed.
3. Interview: The other most important method that helps us to get most important and
critical information about the general view of the existing system by interviewing
persons close to system.
We ask some questions for Example: -
 How do you work currently?
 Have you any computerized system?
 What is the problem of the current system?
1.8.2. Data Analysis Methodology
The data analysis model applied in this project is an object-oriented approach and structure
approach. Object oriented method is select because of the process of analyzing a task (also known
as a problem domain) to develop a conceptual model that can then be used to complete the task. A
typical OOA model would describe computer software that could be used to satisfy a set of
customer-defined requirements. For designing purpose, we use object oriented because a developer
applies implementation constraints to the conceptual model produced in object-oriented analysis.
Object oriented based system analysis and design methodology is a software development
methodology by building self-contained modules or objects. This methodology has the following
futures increased reusability, increased extensibility, proved quality, and reduced maintenance
burden and managed complexity (Booch, 2015).

9
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

1.8.3. Implementation methodology

In this method we will use some software and hardware tools to implements the project.
A) Hardware
 Personal computer
 Flash card
 Printer
 Paper and pens

The minimum hardware requirements based on the customer need and wants as shown below: -

 CPU:
 RAM > 2 GB in size.
B) Software
 Bootstrap templates
 Bootstrap studio framework
 Xampserver
 Google chrome web browser
 Edraw Max application tool
 Operating system- Window 10
 Adobe Photoshop CC 2017
 Microsoft word 2016

1.9. Feasibility analysis

Feasibility analysis is the process of confirming that a strategy, plan or design is possible and
makes sense. This can be used to validate assumption, constraints, decisions, approaches and
business cases. The following are common types of feasibility analysis.
1.9.1. Operational feasibility
The system to be developed will provide accurate, active, secured service and decreases labor of
workers and also it is not limited to particular groups or body. The system will easily operational,
as it doesn’t affect the existing organizational structure and support the current system. So, the
system will be operationally feasible.

10
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

1.9.2. Technical feasibility

The system to be developed by using technologically system development techniques such as PHP,
Java script, CSS, and MySQL database without any problems and the group members have enough
capability to develop the project. Our focus is to develop well organized dynamic web site that is
technically efficient and effective. Therefore, it can be concluding that the system is technically
feasible.

1.9.3. Economic feasibility

The system to be developed is economically feasible and the benefit is outweighing the cost. Since
this project already computerizes the existing system and more advanced than the current system
reduces and change the labor force to computerize system. Reduces the cost of the material used.

1.9.4. Political feasibility

The system to be developed is not conflict with any government directives, because it gives
services for the students effectively and efficiently, all the colleges are also agreed before the
system developed. So, the government is profitable and the system will be politically feasible.

1.10. Budget and scheduling

1.10.1. Budget
To develop this Project flow up and Repository managing System, we will use the tools described
below. Hardware tool as Resource and their cost

Resources Amount Price(ETB)

A4 paper 4 packet 480 birr
Pen 10 pcs 50 birr
Printing 5 times 200 birr
Flash disk 2 340 birr
Computer 3 60,000 birr
Other --- 2500 birr
Total --- 63,400 birr
Table 3: Budget for hardware tools

1.10.2. Schedule
The project will accomplished as follow in Gantt chart.

11
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 1: schedule in Gantt chart

1.11. Document organization

This document is structured in the format that is given by Wolkite University Computing and
Informatics collage final year documentation guideline. The first chapter discusses the various
parts of why we do this project like objectives, background of the project and organization and
feasibility study. Chapter two discusses currently operating existing system of the project and its
bottlenecks of the system. Chapter three discusses the proposed system’s functional and
nonfunctional requirements. Chapter four discusses system analysis that is what the system should
with the features of Use case diagram, object diagram and dynamic diagrams. Finally, chapter five
discusses system design of proposed system that is how the system do intended functions.

12
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Chapter Two: Description of the existing system

2. Introduction
In current Wolkite University, the college of computing and informatics is one of the colleges
which teaches number of students under different departments. For case CCI is one of the best
college that focuses on Information technology and computer science. CCI provides different
services and tasks. From main of them, we are considered on project and research paper follow up
management up to repost it. This task currently done in each department manually and through
long process. Managing the follow up of different projects and research papers has several
challenges, since there are various problems we observe. From those problems some of them are,
there is disutility, and austere because user always work on papers, gather them, sent for other
users, and riposte it manually.

The follow up process of project and project paper management is not free from manual system
till this day. As we observe follow up process, data flow system between stake holders is depend
on papers to give direction, post out templates, report generates, post out schedules and so on. So
to perform all tasks that mentioned above, paper is needed, and they have to print all data to
distribute for stake holders. In addition to this they finally store in one place. This by itself it has
challenges.

The benefit of Reposit projects and related papers that done in each departments is to provide a
reference for students and teachers. So there must be an efficient management system for the sake
of repositing and access files. Currently reposting process is not flexible and hardcore problem for
departments. Now a day they are storing such data’s in their department header bureau and some
of it is on library. Because of this it is not easy to have a chance to reference those data’s.

So after we meet the requirements and feasibility we are planned to develop PFRMS for CCI from
the beginning to end we are to computerize all manual follow up process of project and research
management up to reposition.

13
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.1. Organizational structure

Under this topic we consider and explain an organ structure of Computing and Informatics College
(CCI). As shown below we put CCI structure in terms of project flows and related aspects but not
in real stand of college since it is so broad. In CCI there are college dean and project coordinator,
which acts among departments at college level. And there are also four departments with one head
for each of them. Teachers (instructors) are placed under their department with specific subject
types.

Figure 2: Organizational structure

14
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.2. User of the existing system

In existing system there are four users that participate in the system with different activity and
roles.
User Description
College RSC and IL Control the system, coordinate project related
activities like manage project flow up and so
on.
Header (Department heads) Manage all process at the department level.

Teachers Responsible for advising, examining students.

Student They use provided services and resources.
Table 4: user or existing system

2.3. Major function of the current system

Major activities and functionality that taken by users in existing system is mentioned below.
Those activity also as mentioned above is activities in project flow system, i.e. from submit
proposal to Reposit final project documents.

 Department head formulate student group.

 Student refer and view previously done projects.
 Student submit their title, proposal and document.
 Department assign instructor as an advisor.
 Department head perform schedule for proposal defense by assigning examiner.
 Department head can approve, reject based on defense result, if project is done at
department level.
 Department submit or forward project file to college coordinator, if project is at
college level.
 Advisor submit weekly report and progress of the student to department header.
 Department announce the status of the project information to students, i.e. approved
or rejected.
 Instructor can advise and examine student and project respectively.

15
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Instructor interact with the students as advisor for the success of the project and
evaluate student project as examiner.
 Instructor submit result sheet, i.e. as examiner submit the evaluation result and report.
 College manage and control all projects flow process of each department.
 College assign examiner for the final project defense at college level.
 Department give grade as the yield of final result of project developing.
 Finally, college store the project documentation in library and most of them in their
bureau store.

In project develop process in computing and Informatics College those mentioned activities are
some of the major activity that take either by student, instructor, department head, or college
coordinator.

16
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.4. Existing system workflow structure

Figure 3: Existing system work flows

17
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.5. Report generated in the existing system

Here is one report form that advisor generates once a week and submitted to department head. It
contains discussed tasks of particular week and new tasks that planned for the next week.

Figure 4: Report generating existing system

18
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.6. Forms and other documents of the existing systems.

Figure 5: Form and other document for existing system

2.7. Bottlenecks of the existing system

2.7.1. Performance

 It is not fast and it is time consuming in terms of;

19
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Submitting title and proposal.

 Report for submission.
 Assigning advisor and examiner.
 View and release the status of proposal and title.
 Display the status of the project title formulation and printing.
 Finding advisor on office.
 Low available to get previously done projects and research’s.
 Report generation from student and advisor is so late.
 The project submission is even take time /consume time/, i.e. the process may take 1-2
days.
 Difficult to search the research and project from the store.
 Scheduling /assignation process/ for advisors and examiners is difficult.

2.7.2. Input and output

 Input
 Most report paper is lost.
 The required data is not filled.
 The data is not clearly written good hand writing.
 The report is not submitting at the given time.
 Redundant data is captured.
 Non-essential data is captured.
 Report and other data are paper formatted.
 Output
 Incorrect data is reported
 No data is submitted
 No report is generated if lost
 Redundant data is reported
 Lack of fast report generation
 Difficult to analysis report since required data is not filled
 Difficult to view project title, research title and reports since it is paper formatted.

20
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

2.7.3. Security and control

 Report is accessed by unauthorized person.

 The project data and research data are faced to stole.
 The report and other forms can be edited by another person.
 Data privacy is not secured.
 Stakeholders communication is poor.
 Lacks reliability in data store.
 The form paper can be fake profile since the paper is not privately transferred.

2.7.4. Efficiency

 Time waste
 Resource waste like paper and printing color
 Data are faced to damage
 Report and project title with proposal is redundantly generated
 Project proposal, research proposal with their documentation take more space.

21
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Chapter Three: Proposed System

3.1. Introduction to proposed system

The proposed system is planned to automate managing and to facilitate the works of departments
in terms of project follow up process in a simple manner. It provides a service through online web
based system. And each stake holder participates in the system and access the services using
computerized monitor.

Project follow up management system will perform all necessary procedures for its all users. It
provides several services for organization such as, it allows users to communicate easily among
them, those who participate on project management process form title submission to riposte a final
document. As described in chapter two, in the existed system most action is held using manual
mainly based on paper. An activity like student submit title, report being generated flows in the
system, new advertisement and templates post out, and final document stored all this is based on
manual.

By using this system student submit titles and proposal to their department and browse a system if
new thing is posted on. Like project templates, approval or reject of proposal, their advisor,
examiner, schedules, deadlines of project and so on. In addition, student access previously stored
data through system. And headers use this system for managing follow up like, see title and
proposal submitted by student, schedule advisor and examiner with time and place, unfold and
announce to advisor, examiner, and student’s current information. Plus, to see weekly report come
from advisor. Advisor see for what group he/she scheduled, give a direction for group he/she
advise and send weekly report for header through system.

So, our proposed system has the following advantage.

 Easy and user-friendly interface

 Fast access
 Easy navigation
 Security features like access using password, usernames, mobile phone, and so on
 Search catalog

22
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Send and receive message and data

 Filter same title, somehow description submitted before if existed
 Store approved data
 Show and provides all projects done in the college
 Reduce data redundancy
 Feedback mechanism

3.2. Business rules

Business is working principles and policies that we are try to specify in proposed system.

Business rule in Business rule details

BR 1 Users of the system should be authorized.
BR 2 Headers and coordinator should have registered.
BR 3 Users create an account in the system and must fill a form properly.
BR 4 The system must response to users.
BR 5 The system should have work 24/7 per week.
BR 6 The system should give a service for authorized person only.
BR 7 Not to register other users with the same username and password.
BR 8 The student must submit their title, proposal, report and project
documentation with in a given time.
BR 9 The advisor must submit report to department with in a given time.
BR 10 The project proposal and documentation must have an advisor
signature.
BR 11 The student must not directly copy and paste the previous project
documents rather than use that as a reference.
BR 12 The department must not accept the project documentation unless
document and proposal have the advisor signature.
Table 5: Business rule

23
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

3.3. Functional requirement

The system should do the functionality that is related to process the data, input the data that is
entered by the user, output it after processing user’s data and display it in visual, image and text
formats to the computer system. Input or output devices can be modified to provide access to
individuals with disabilities who cannot use standard input or output devices. Generally, in order
to provide a better understanding of input, output, Storage and processing, these concepts are
defined as follows:

3.3.1. Input related requirements

A functional requirement which is the information that is entered to the computer system. Inputs
have their own specified label name depending on the purpose of the input data field for each
information. Like the user may be asked to enter his user name and password so he can use the
specified purposeful input field of the required information. The input data will be used typically
by using type a text, attach image and mouse click etc.

 Submit proposal/project - especially student user submit project and another file for
department head and their advisor.
 Message - send message to user after insert information.
 Send file/templates - user send file like project template by insert it from local disk or
flash disk.
 Notify users - inserts an information to system to notify user as notification.

3.3.2. Process requirements

A functional requirement which occurs when the user enter an input data to the system and the
system is check and process it from the required table in order to verify the correctness of the
user’s data. If the user enters the data which is verified correctly the system display or notify the
success message to the user, unless the user input data is incorrect when it is processed the system
should show or display error message to the users. Like when the user trying to access unauthorized
account, sending data to the desired user and search and find the data form the system.

24
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Generate letter - when user insert information and press specified button, system generate
letter and preview a letter as an output.
 Generate report - when user insert information, system process’ to generate report
according to algorithm specified.
 Search file/data - after user insert character, system find for what is requested from user.

3.3.3. Output related requirements

This is also an output related requirement which is identified when the system is show or return
error or successful message to the user when the user interact with the system in order to perform
a given task. The system also display notification for the important data change and user requests
and actions. The output data will be provided in visual format auditory format and image format
that can be related with text printers. Like when a user wants to view and print the data that is
processed by the system, report will be generated, the desired information will be posted over the
system.

 Display preview - when report or letter generated, system display preview as an output.
 Print preview - after system display preview user can print it and display previewed data
as .pdf file.
 Display notification - display notification to notify news, advertisement and notes.
 Different messages – system display different messages because of different tasks done
entirely.

3.3.4. Storage related requirements

A requirement in which the important data should be stored in database and each database
operation also controlled by authorized user’s user name and password. The database should store
the most important information in to its storage place and also the data will have stored in a
catalogue format. The database server should be protected or placed from unintentional attacks,
natural disaster and any power surge damage.

 Add file - when user select file and add it to database, the file stored in the database until
it deleted or updated.

25
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Save data - when user save particular file, then data is stored in the database.
 Update file - data in database is updated and modified in terms of contents or attributes.
 Delete file - delete file from database store in order to clear such file.
 List file - if user request for file, that had been in the database system load it and display
for a user.

3.4. Non-functional requirements

Non-functional requirements define the overall quality or attributes of the resulting system. It
identifies and place restriction on the system being developed, the development process, and
specify external constraints that the system must reach.

 Accuracy: mean that we can get right information at right time.

 Economic: a good system reduces the cost and we can get maximum benefit with
minimum time and minimum resource.
 Security: this system has very secured due the username and password for administrative
activity.
 Efficiency: the system is very fast in terms time and space and has capability storing high
data.
 Control: nobody can access the database without the permitted person with respective
data.
 Services: the system must have its own ways that makes reliable and flexible.
 Performance requirement: the system most host many users at same time with remote
distance.
 Usability: Easy to understand and user friendly and provides some training on the site
for students.
 Reliability: the system provides to the user correct information. When the user entered
wrong inputs, it notifies to correct the input data.
 Performance: the system has performed all operation through single pressing button it
response in short period of time.
 Maintainability: the system is maintainable to improve the ability and it is non-
functionality.

26
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Availability: The PFRMS system is functional at a given time. The system provides
services for all system users without any time limitation at s given time.

27
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Chapter Four: System Analysis

4.1. Scenarios
Login Scenario
Scenario Name: Login

Participating actors: Samuel (Students, Department heads, College heads and Teachers)

Initial Assumption: The internet connection and electric power should available and open
browser.

Normal Flow of events:

 Samuel selects login to have access into the system in order to provide services.
 The system displays login page to same that enable to enter his username, password
and user type or role.
 Samuel enters username, password and select user type then press login.
 The system verifies Samuel’s username, password and user type then the user type
home page is displayed.

What if it goes wrong?

 If Samuel’s username and password doesn’t match from users account database,
the system display the error message “Your username or password is incorrect”
over login page.

Schedule Scenario

Scenario name: Schedule draft

Participant actors: Aklilu (Department heads, College Rsc)
Initial assumption: Aklilu is logged into the system. Instructor and students must be the registered
and member of this system.
Normal flow of events:
 Aklilu is select schedule in order to draft schedule for the time, place and evaluator
of student’s project proposal and final project documentation.

28
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 The system displays the schedule drafting table and allow to user write, edit, update
and delete operations.
 Aklilu is write, edit, delete and update schedule table and save it and forward to the
desired users.
 The system displays a message “The schedule is saved successfully!”, when the
drafter press save button.
 Aklilu is press forward button in order to distribute to the specified users.
 The system displays the choice box for selecting the users that needs this schedule.
 Aklilu is select the required users and press forward button.
 The system is Display the message “Successfully forwarded this schedule!”

What if it is wrong?

 If the header selects no user that can be forwarded this schedule and press the
forward button, then the system displays error message “Please select the desired
users!”

Generate report Scenario

Scenario name: Generate report

Participant actors: Gemechis (Teachers, students, Department heads and College heads)
Initial assumption: Gemechis is logged to the system and provide the report depending on his
role.
Normal flow of events:
 Gemechis select report button.
 The system displays the weekly report page and allow the user to fill the report
forms.
 Gemechis fill the given report form and press forward button to the desired user
types.
 The system checks the required form and display the message “Successfully
forward the report!”, if it is completely filled.

What if it is wrong?

29
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 If Gemechis does not fill all required report form field the system display error
message to the user as “You are not filling all fields, please fill the required fields!”

Send File Scenario

Scenario name: Send file

Participant actors: Wubete (Students, department heads)
Initial assumption: Wubete is logged to the system in order to get the system service.
Normal flow of events:
 Wubete is select and press send File button.
 The system displays fields and form that allow the user to send the required data or
file.
 Wubete is write titles, select process type and data files.
 Wubete press send button after selected file is loaded.
 System check if form has been correctly filled or not and display a message “You
sent data successfully!”
What if it is wrong?
 If Wubete doesn’t fill the required data field the system displays a message “You
are not fill the required submission field! Please try again!” into the page.

4.2. System model

PFRMS model is begin with identifying of use case after analyses requirement of system from
different stakeholders.

4.2.1. User class and characteristics (actor identifications)

In PFRMS there are four user classification with distinctive characters and different skills in order
to perform specific task. Below in the table user and their characters are listed.

30
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

User Characters/descriptions Skills for user

Student Responsible for using provided service Assumed to have basic

from the system. knowledge of the computers
and Internet browsing
Instructor Responsible for advising and examining Assumed to have basic
student on their project. knowledge of the computers
and Internet browsing
Rsc&IL Responsible for manage entire college on Assumed to have basic skills
project related situation and process’. for office’s work, and
knowledge of computer.
Department Head Responsible for assign advisor, Assumed to have basic
examiner, generate report and manage knowledge of the computers
department. and Internet browsing
Table 6: User class and characteristics:
4.2.2. Use case diagram
A system use case model describes the potential usage of the propose system. It is part of the
analysis document which consists of use case describes sequence of action that provide measurable
value to an actor and it’s drawn as horizontal ellipse.

An actor is a person that plays a role in one or more interactions with the system. Relationship
between actors and classes are indicated within use case diagrams. A relationship exists whenever
an actor is involved with an interaction described by a use case. The rectangle around the use cases
is called the system boundary box and the name suggests it indicates the scope of the system the
use cases inside the ellipse represent the functionally that the system intend to implement.

Use cases are used during requirements elicitation and analysis to represent the functionality of
the system. Use cases focus on the behavior of the system from an external point of view. A use
case describes a function provided by the system that yields a visible result for an actor. An actor
describes any entity that interacts with the system. Our system use case digram is shown as belows;

31
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

4.2.2.1. General use case diagram

Figure 6: General use case diagram for PFRMS

32
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 7: general use case b for PFRMS

33
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

4.2.2.2. Detailed diagram and description of each use case

Under this topic use cases of general use case covered in detail. Which use case related with which
use cases and how, in what relation is considered as big issue.

Some of use case list with detail views

 Schedule use case
 Create account
 Generate report
 Deadline use case
 Generate letter
A. Schedule use case

Schedule includes two use case in order to provide full functionality. Before schedule and assign
instructor as advisor or examiner, student must have formed to group and must editable.

Figure 8:Schedule use case

34
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

B. Create account use case

Figure 9: Create account use case

C. Generate report use case

Figure 10:generate report

35
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

a. Generate letter use case

Figure 11: Generate letter use case

D. Add deadline use case

Figure 12: Add deadline use case

36
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

4.2.1. Use case description

User case ID Use case Description

UC-1 Schedule Assigning and placing teachers as advisor or
examiner for particular group of student based on
title subject type.
UC-2 View report List and see weekly report that sent from different
users to mark as accepted and remark it.
UC-3 Generate letter Producing letter paper in order to send it. Letter may
send online with signature or by printing it.
UC-4 Generate report Producing a reports format for different type of
purposes. Then send, save or print it.
UC-5 Add file Insert data and new project file into database, after
each project is fully completed and approved.
UC-6 Update file Apply needed change to stored data with limited
access.
US-7 Send data Send particular data and file for specified users with
limited data capacity.
US-8 View sent data See sent data related information by current user like
time, for whom, what type of data, and title (send
type) of send process.
US-9 Inbox data Access a sent data for current user and related
information.
US-10 View See information of student group, teachers, and
information header. User may access information like private e-
mail address, phone number, name title, and role of
different users.
US-11 View history Provide task done history for the last five days.
US-12 Search To search services that are provided by the
organization.
US-13 Form group To formulate one to five student group format.
US-14 Download file Download available resources to have private soft
copy.

37
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

US-15 View To have further description of the project. User can

description get short description, grade result, year, department,
and developers.
US-16 Read on line To read data resources on line through browser by
fetching it from data base temporary.
US-17 Post Posts or display notices, advertisement, and news for
notification users.
US-18 View See what is new and information regarding to project
notification held on.
US-19 Change profile Users change their profile like profile photos,
password, and so on.
US-20 Login To use this system and it is services user should
perform login using user name and password.
US-21 Logout To exit from the system.
US-22 Create account User must login to the system, it has secure account.
US-23 Add deadline Time schedule for the project title, proposal
submission and final document.
US-24 Display The output what system does
Table 7:general use case dicrptions

User case name Schedule

Actor RSC & IL and department
Description Assigning and placing teachers as advisor or examiner for particular
group of students based on title subject type.
Triggered When RSC&IL or department wants to assign teachers as advisor or
examiner.
Pre-condition  User must login.
 Students must have formed into group.
 Instructor information should be accessed from the database.

Flow of events 1. Select Assign after Schedule.

2. System display list of titles, subject type, teachers, forms and
button.
3. User fill the forms, choose for assign advisor or examiner.
4. System check the same person is not advisor and examiner of
the same group.
5. System retrieve and display allowed and well formatted data.
6. User select teacher for each title of each group and press add
button one by one until finish.
7. User hit assign button in order to generate the preview.

38
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

8. System displays preview of assigned and well formatted data

in table.
9. User can print, save, send or delete it.
Alternative flow None
Post condition Assigned advisor or examiner with respective group and title is listed
in the form so as to print, save, or send it.
Table 8: schedule use case descriptions

Use case name Generate report

Actor Rsc&IL and department
Description Producing a reports format for different type of purposes in which user
fill it as daily or weekly or any time report.
Triggered When user want to generate report needed at any time.
Pre-condition User must login to the system.
Basic flow 1. Select Report.
2. System display list of tasks per week. And display if each listed
task is evaluated, reported or not in the form of row and
column. Also holds delete button.
3. If user select or click on the lists name in the row.
1. System display clicked task’s full report view.
2. User can send, print, or close it.
4. If user select button X under evaluated column.
1. System check if task is checked or not.
2. System provide fields and forms for evaluation.
3. User insert characters, select choices and hit evaluate
button.
4. System display “Mr./s. x evaluates successfully” message.
5. System back to step 2 and trigger unevaluated symbol to
checked.
5. If user select New task button
1. System display pages with fields and forms to add new
task of the week.
2. User insert information, i.e. one task per time and press
Add button.
3. User press finish button, after he/she perform the last add
task operation.
4. System display “x week task is added successfully”
message and back to step 2.
6. If user select button X under column reported.

39
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

1. System check if task is reported, evaluated, and new task

is added.
2. System display view of generated report, but there is no
signature of both advisor and students and needs to sign.
3. Advisor share for student group to allow them to sign by
pressing share button.
4. Student view notification, open shared file, sing on it, and
send back to advisor.
5. Advisor sign and press generate button finally.
6. System display letter preview so that user can see what is
generated.
7. User can send, print, save, or cancel it.

Alternative flows  If there is no generated report in the system yet.

2. System display ““report items generated before is not found,
please create new by pressing New task below!”.
 If user select checked evaluated button

4.2. System display “the task you are clicked on is evaluated.”

message. And back step 2.

 If task is not evaluated, and new task is not added, but user selects
unreported button symbol
6.2.System display “before generate report evaluate a task and
add new task of the week”.

Post-condition Report is generated, sent, saved, or printed.

Table 9: generate report use case

User case name View report

Actor Student, teacher, department, Rsc&IL
Description See previously generated and sent report.
Triggered When user wants to see sent report from co-worker or from student.
Pre-condition User must login to the system.

Basic flow 1. Select View report.

2. System display sent report symbol with short description.
3. User press double time on the symbol after reading description.
4. System display whole report on screen.
5. User sign on it and notify report is reached destination.

40
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

6. User can save or forward a report.

Alternative flow
Post-condition Report is viewed, saved, or forwarded.
Table 10: View report use case descriptions

Use case name Post notification

Actor College (Rsc&IL), department and teacher.
Description Display and notify users of the system for different purposes. Including
advertising.
Triggered When user wants to notify or adverting other users.
Pre-condition User must login to the system.
Basic flow a) For the system generated
1 User send data for others user, or some news released.
2 System send and show notification for receiver user.
b) For adverting, news and notify based on time, and deadline notifications.
1. User select Send.
2. System display different forms and button.
3. User selects task type, i.e. notification or message data. Consider as
notification is selected.
4. User select data type, i.e. project doc, proposal, news, advertisement,
data file, or others.
5. User write news, notifies, advertisement, choose time and date, data
file and hit send button.
6. System display “successfully sent” message.
7. System send notification for specified users. And back step 2.

Alternate flow If there is unfilled and not selected fields and user press send button.
b).5. System display “insert necessary data to fields please” message
Post-condition News, advertisement, and notification is displayed.
Table 11: Post notification use case

Use case name Send data

Actor Rsc&IL, department, teachers, and student.
Description Send particular data and file for specified users with limited data capacity.
Triggered When user wants to send a particular data file or message for user of other
side.
Pre-condition User must login to the system.
Basic flow 1. User select Send.
2. System display different forms and button.

41
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

3. User selects task type, i.e. notification or message data. Consider

as message is selected.
4. User select data type, i.e. project doc, proposal, news,
advertisement, data file, or others.
5. User write messages, select receiver address, images and data
file, then hit send button.
6. System display “successfully sent” message.
7. System send messages for specified users. And back step 2.
Alternate flow If there is unfilled and not selected fields and user press send button.
5. System display “insert necessary data to fields please!” message.
Post-condition  User sent data.
 System record a task as a list in View sent.

Table 12: Send data use case descriptions

Use case name Inbox data

Actor Rsc&IL, department, teachers, and student
Description Access a sent data for current user and related information.
triggered When user wants to see new sent data file or message from other source
user.
Pre-condition User must login to the system.
Basic flow 1. Select Inbox.
2. System display list of data and related information.
3. User can view, save, forward, delete, and print it.
Alternate flow None.
Post-condition Data or message viewed, saved, delete, or print it.

Table 13: Inbox use case descriptions

Use case name Generate Letter

Actor College head and Department head
Description Generating a letter which used for announce a specific user in order to do
some specific tasks.
Triggered When a header wants to send a letter to the examiner and advisors.

Pre-Condition User must be login to the system.

1. User select letter.
Basic flow 2. System display generated letters list with corresponding title,
date, receiver name, and delete button. This page also holds new
letter button.
3. If one of saved letter selected, by clicking over it.
1. System display letter view and edit button.
2. User select edit button in order to edit the receiver name.
3. System provide fields and forms…

42
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

4. User insert information and hit upload button.

5. System display edited letter preview after.
6. User can save, print or send the previewed letter.
7. User select close so that the system back to step 2.
4. If new letter button is selected
1. System provide fields that allow user to create new letter.
2. User fill and selects information. Then hit create button.
3. System display preview of created letter, so that user can
see what is generated.
4. User can select send, save, or print for previewed letter.
5. User select back in order to back to step 2. Also user can
select cancel to cancel operation and back to home page.
If the required field does not fill by the header the system displays “This
Alternative flow field is required, please fill it” message.
2. When letter is selected and there is no list of generated letter
before System display “letter items generated before is not
found, please create new by pressing New letter below!”.

Post condition Project related letter is generated.

Table 14: generate letter use case descriptions

Use case name View sent

Actor Rsc&IL, department, teachers, and student.
Description See sent data related information by current user like time, for whom, what
type of data, and title (send type) of send process.
Triggered When user wants to see information and list what user he/she done earlier
during send data.
Pre-condition User must login to the system
Basic flow 1. Select Sent.
2. System display list of sent data and related information.
3. User can clear all or delete it one by one.

Alternative flow None

Post-condition List of sent task is viewed, cleared, or deleted.
Table 15: View sent use case descriptions

Use case name Update file

Actor College IL or department head
Description Updating the file that must be updated if the old one has uploaded
incorrectly or less important than the newly coming and approved files.
Triggered When the header wants or obliged to update file to the system.

43
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Pre- condition  The user must have logged to the system first.
 The data, a user going to update must be in the database.

Basic Flow 1. The head selects Update after Repository.

2. The system displays Update file page in order to allow the user to
search, list and to update data that must be updated.
3. User search and list file from the repository system.
4. The system prompts the user to choose the file from every
directory.
5. Header choose the new file that must be updated
6. User correct or add to old file then press update button.
7. The system displays the message “Selected file is updated
successfully”.

Alternative Flow If the header does not select the new data from other directory and press
update the system displays error message “You must select file, please!”.

Post-condition The system return to home page and allow the user to do another works.

Table 16: Update file use case descriptions

Use case name Add file

Actor College Rsc & Il.
Descriptions Adding newly coming approved project files, proposal template,
document template and old files for the purpose of cataloging and
provide a service.
Triggered When the college head want to or obliged to add files to the repository.
Pre-conditions Head first must be logged to the system.
1. Header selects upload file after Repository.
Basic Flow 2. System provide dropdown button list that contain “add from disk
file” and “add from the system”.
a. If add from disk file is selected
3. The system displays the given field to add files with their year,
department category and short description.
4. Header select from disk and add the files depending on their year
and department then press Add.
5. The system displays a message “System has successfully reposted
your file”.
b. If add from the system is selected.
3 System provide file list with categories, i.e. project, proposal,
result-sheet, and project template categories.
4 User click or press on file to see button for task.

44
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

5 System display buttons by dropping down them from the row of

selected file.
6 User press description button for description.
7 System provide small page with forms and fields.
8 User insert information and click go button.
9 System back to step 5 with description set sign.
10 User click add button to upload file into system repository.
11 User click on x button to close listed file.

Alternative Flow If the header does not select the file source or year and try to add to the
repository
a.5. System displays the message “You should fill the necessary
information about the file”.
If there is no listed file from system database
b.3. System display “no item found under this categories” message.

Post-conditions Approved project file is added and stored.

Table 17: Add file use case descriptions

Use case name Search

Actor All users
Description Searching a single file from where data is reposited, by interring a series
of characters for what user wants.
Triggered When user is obliged to search the data files either project title proposal or
project final documentation.
Pre-condition The user must be logged to the system first.
Basic Flow 1. User select Search.
2. The system displays search boxes.
3. Heads search projects based on their year or titles.
4. The system displays or list down the required projects document
titles.
5. Heads can view projects.

Alternative Flow If the searched project title is not available the system displays “No search
result”.
Post - condition The heads can print and download projects.
Table 18: Search use case descriptions

Use case name Form group

Actor Department heads
Description Form graduating students 1 to 5 group.
Triggered When the students need one to group form for their projects.

45
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Pre-condition  The head must be logged to the system first.

 Student information, i.e. name, mark, and so on must be in the
database.

Basic Flow 1. The heads select Form group.

2. The system displays form that is designed to group students
and allow users to write, edit or delete input characters.
3. User select and insert character and hit place button.
4. System display preview of formed group in well format.
5. User here can save, post, or close preview page.

Alternative Flow None

Post-condition Class students are formed in to group.
Table 19: Form group use case descriptions

Use case name Download file

Actor All users.
Downloading the files that is allowed to and desired by the user in order to
Description have file’s soft copy.
Triggered When the user wants to download the specific files for different purposes.

Pre-condition  The user must be logged to the system.

 Data to be downloaded must be in the database.
Basic Flow 1. User search and list view of file what he/she want to
download.
2. Users open a specific file that can able to be accessed.
3. The system displays download button at the file name line.
4. Users press Download file.
5. The system prompts the user in which directory the file
should be stored.
6. Users select the directory they want to store the file.
7. The system downloads the file and show a message
“Successfully downloaded”.
Alternative Flow None
Post-condition File is downloaded and user can read files on his device local
directory.

Table 20: Download file use case descriptions

46
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Use case name View description

Actor All users.
Description View some descriptions about the searched and selected file. User can
view description like author’s, year, yield mark, statement of
problem, scope, and limitation of selected project file.
Triggered When the user wants to visit and view a specific project status and
description.
Pre-condition User must have logged to the system first.

Description data to be viewed must be in the database.

Basic Flow 1. User search project file by title, year or department.
2. System open a page with project titles list.
3. User select more for description from each title list’s row.
4. The system displays detail description of selected project
title or documentation.
5. User can read, back or close description preview of a specific
project.

Alternative Flow None

Post-condition The user have some knowledge about a specific project that he is
going to select.
Table 21: View descriptions use case descriptions

Use case name View notification

Actor Rsc&IL, department, teachers, and student.
Description User view what new information attached for them.
Triggered When user want to know new information.
Pre-condition For public notification
 User must open the system.
For private notification
 User must login to the system.
Basic flow For public notification
1. User open the system.
2. Select System.
3. System display all public notification and advertisement.
For private notification
1. System place symbol sign of notification on the button
notification.
2. Select notification.
3. System display list of news, notifications, and advertisement.
4. User can mark us read or download it, if it is file.
5. User select close to close notification page.
6. System back to step 1. With no sign of new notification.

47
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

For system generated notification

1. System pop up notification box on window bottom.
2. User click on displayed box of notification.
3. System navigate to a page that cause for notification. Like
Inbox page to display what is new message or file is in
boxed.
4. User take any action that proposed before for each pages to
back to initial work.
Alternate flow None.
Post-condition Notification is viewed.
Table 22: View notification use case descriptions

Use case name Change profile

Actors All users.
Description Change their profiles in order to make secure their user type
functionality specifically their password.

Triggered When it is needed to change their password.

Pre-condition The user must be logged to the system.
Basic Flow 1. The user selects Change profile.
2. The system displays change their password only.
3. The user changes their password in the required field.
4. The system displays a message “Successfully changed”.

Alternative Flow None

Post-condition The user can access the provided services by the new password.

Table 23: Change profile use case descriptions

Use case name Login

Actors All users.
Description Users must have to login to the system in order to use a service
provided by the system.
Triggered When the user wants to use this system.
Pre-condition Users must have an account for the system to be a member.

48
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Basic Flow 1. User select Login.

2. The system displays the login page.
3. Users enter user name and password finally press login button.
4. The system checks the username and password of a user from
user’s database then display the home page of a specified user
type.

Alternative Flow If the user is enter incorrect username and password that do not match
with the user’s database account the system displays error message
“Username or password is incorrect”.
Post-condition User can access the homepage and can do a specific tasks.
Table 24: Login use case descriptions

Use case name View information

Actor College IL, Department head, and Teacher
Description Access the information of the student group, teachers, heads and
about their titles, profiles, user types.
Triggered When the user wants to view the information of the particular system
members.
Pre-condition The user must be logged to the system first.

Basic Flow 1. The user selects View information.

2. The system displays the information in category.
3. The user selects the user category whom he/she wants to
look.
4. The system displays the selected information.
5. The user view or close the selected user information.

Alternative flow None

Post-condition The user information is viewed, or printed

Table 25: View information use case descriptions

Use case name Logout

Actor All users.
Description Users should logout from the system if they are logged to the system
in order not to be accessed by unauthorized users.
Triggered When users finish their work, and want to leave out from their
system room to get break for themselves.
Pre-condition User must be logged to the system first.

49
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Basic Flow 1. User select logout.

2. The system processes it and logout from the system page and
display login page again.

Alternative Flow If the user do not want to press logout button the system can able
him Clear all browsing data for browser menu.
Post-condition User can go everywhere without any doubt about the system
security.
Table 26: Logout use case descriptions

Use case name Create Account

Actor Department head
Description Register and create account for students, and teachers of the
department.
Triggered When user wants to create or account for student and teacher users.
Pre-condition User must have logged and fill criteria to the system.
Basic flow 1. User select Account button.
2. User click createAcc button.
3. System display registration page and forms.
4. User fill the form with information and click save button.
5. System display “successful registered” message.
6. System provide user page with forms.
7. User give a user name and password for registered person
and click create button.
8. System display “successfully created” message. And back to
step 2.
Alternative flow If data, a user inserts in step 3 and 6 is invalid after system check it.
5. System display “invalid data inputted” message.
7. System display “invalid data inputted” message.
Post-condition User is registered, and account is created

Table 27: Create account use case descriptions

Use case name Delete account

Actor Department header
Description To delete created account of an individual user in the system.
Triggered When user leave the college because of any reason, admin delete an
account of that person.
Pre-condition Account must be created first.
Basic flow events 1. User select Account button.
2. User click deleteAcc button.

50
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

3. System display deleteAcc page and its forms.

4. User fill the forms to help the system to identify the user
and press delete button.
5. System display “are you sure to delete” prompt message.
6. User select yes button.
7. System display “account x is successfully deleted” message.
Alternative flow If information entered in the fields is not unknown by system.
5. System display “an account this type is not found” message.
If user select no button
7. System back to step 3, displays deleteAcc page.
Post-condition Selected account is deleted from the database.
Table 28: Delete Account use case descriptions

4.2.3. Object model

Object model is a description of an object-oriented architecture, including the details of the object
structure, interfaces between objects and other object-oriented features and functions.

4.2.4. Class Diagram

Conceptual models are used to depict the detailed understanding of the problem space for the
system. Class models show the classes of the system, their interrelationship (associations and
multiplicity) among classes, the operations and attributes of the classes (Jacobsons, 2015).
It shows the classes of the system and their interaction which are typically used to:

 Explore domain concept

 Analyze requirement in the form of conceptual analyses model.
A class diagram is typically modeled rectangles with three-section:

 The top one indicates the name of the class

 The middle one lists the attributes of the class and
 The third one lists the methods. By including those 3 sections class name, an attribute
and a method box in the class we are arguably making design decisions in our model.

51
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

52
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 13: Class diagram for PFRMS

4.2.5. Sequence Diagram

A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
instances participating in the interaction by their “lifelines” and the stimuli that they arranged in
time sequence (Coad, 2015).

A. Login sequence diagram.

Figure 14: Login sequence diagram

53
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

B. Form group sequence diagram

Figure 15:.Form group sequence diagram

54
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

C. Evaluation sequence diagram

Figure 16: Evaluation sequence diagram

55
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

D. Create account sequence diagram

Figure 17: Create account sequence diagram

56
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

E. Post file sequence diagram

Figure 18: Post file sequence diagram

57
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

F. Generate report sequence diagram

Figure 19: Generate report sequence diagram

4.2.6. Activity Diagram

An activity diagram is a variation of a state machine in which the states represent the performance
of actions or sub activities and the transitions are triggered by the completion of the actions or sub
activities. It represents a state machine of a procedure itself. Activity diagrams represent the

58
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

business and operational workflows of a system. An Activity diagram is a dynamic diagram that
shows the activity and the event that causes the object to be in the particular state.

A. Evaluate task activities diagram

Assume, user logged to system, and start with home page.

Figure 20: evaluate task activity diagram

59
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

B. Add new task activities diagram

Assume, user logged to system, and start with home page.

Figure 21: Add new task activities diagram

60
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

C. Generate weakly report activity diagram

Assume, user logged to system, and start with home page.

Figure 22: Generate weakly report activity diagram

61
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

D. Generate letter activities diagram

Assume, user logged to system, and start with home page.

62
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 23: Generate letter activities diagram

E. Form group activities diagram

Form group activity is performed to form group of student in CCI College. As educational policy in
Ethiopia, project may take between two or more students in order to share knowledge and experience.

Figure 24: Form group activities diagram

63
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

F. Add file activities diagram

Assume, user logged to system, and start with home page.

Figure 25: Add file activities diagram

64
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

G. Update activities diagram

Assume, user logged to system, and start with home page.

Figure 26: Update activities diagram

4.2.7. State Diagrams

State chart diagrams describe the behavior of an individual object as a number of states and
transitions between these states. A state is a condition that an object satisfies. A transition
represents changes of state triggered by events, conditions, or time.). The state chart diagram
focuses on the transitions between States as a result of external events for an individual object.

65
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Both activity and state chart diagrams are useful in modeling the lifetime of an object. However,
activity diagram shows flow of control from activity to activity; whereas state chart diagram shows
flow of control from state to state.

A. Login state diagram

Figure 27: Login system state diagram

66
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

B. Create account state diagram

Figure 28: Create account state diagram

67
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

C. Inbox state diagram

Figure 29: Inbox state diagram

68
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

D. Delete account state diagram

Figure 30: Delete account state diagram

69
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

E. Change profile state diagram

Figure 31: Change profile state diagram

70
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Chapter Five: System Design

5.1. Introduction

This chapter describes a higher-level overview of the technical architecture for the project flows
up and Repositories Management system based on the user requirement specified in the various
chapter. Additionally, it summarizes the technologies that the developer member will use. It
describes desired features and operations in detail, including screen layouts, business rules, process
diagrams, and other documentation.

The high-level description contained in this chapter provides the design goals of the architecture,
the architectural styles and components that have been selected to best archive the use cases
specified in the Requirement Specification Document. This framework then allows for the
development of the design criteria and documents that define the technical and domain standards
in detail.

The purpose of system analysis and design is for a situation to increase their efficiency, because
when we look at a current system we will see flaws that need fixed answer within the new system
that we design we will take these into considerations. Since we make each step and procedure with
design, it will be simple to implement in practice. This means system design is used to indicate
how each function is performed. The purpose of designing is to make all our system user easy and
faster manner access to the system (Fowler, 214).

5.2. System overview

Our system overview functionalities when the title submission schedule posted from the
department, then student submit title and the department approve the title and student communicate
with advisor and advisor assign then student submit proposal and department post the schedule for
proposal submission finally department assign and student communicate with their advisor and
finish the project they submit final documentation to the department and finally department assign
examiner and post schedule for document submission and student submit on the time final
documentation. This system overview show bellows the structure.

71
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 32: system overview

5.3. The Design Consideration

5.3.1. The Design Goals
The design goals are derived from the functional and non-functional requirements of the system,
which were stated in the previous requirement specification phase of this document. We describe
the qualities of this system. This includes:
 User Interface: The user interface of the system should be easy to use by each user of the
system with little training. Our interface contains different buttons such as login, home,
and others which guide the users what to click and fill to enter to their page to do what they
want. So the user interface is easy to access. We also do our system clear which means the
interface shows where to go in the system. The developed software use the system is user
friendly by making easily accessible.
 Security: user’s account is created by the admin user, so, no one can’t create an account
by themselves and use the system. But person who has an account can login to the system
using his/her username and password and use the system.

72
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Fault Tolerance: The system should be able to give response (error message) when the
user enters incorrect input. If users enter incorrect data like username, password and invalid
fields the system displays an error message which informs the user to enter the correct
information. To do this, we apply validation using java script.
 Scalability: Since the system is modular it is assumed that the system will be scalable for
future use.
 Integrity: Data integrity ensured that data is high quality, correct, consistent and
accessible, important to follow rules governing data integrity. Hence the developed system
will be tested for data and database integrity. The system should easily integrate with any
applications.
 Since the system performs data validation mechanism while entering the data that
makes data consistency.
 The system also performs skip logic questions.
 Extensive data validation and review will be performed both before data are
uploaded to the system and as part of upload process this supports the system to
keep data integrity.
 Accessibility: Is the ability of the system to be accessible to users. This can include media
such as certain web browsers, mode of access such as mobile devices. Since the system is
web based any user can access the system anywhere if connection is available.
 Availability: Is the ability to maximize the time when the system is available for use to
its users. By avoiding redundancy of codes, using error handling mechanism (like
exception handling), and replace infinitely running loops into short and precise loops that
increases the availability of the system.
 Throughput: Is the bandwidth relating to the capabilities of the systems performance over
the network or Internet. It is the characteristics of a system providing for adequate ability
to simultaneously support the demands of multiple end users. Since the system is web based
multiple end users can simultaneously work their job and support users.
 Maintainability: The system, since it is web based, will be relatively easy to correct
failures. Besides modifications due to business rule changes and due to new requirements
can easily be made from a server and then client applications can easily use the update.

73
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

 Reliability: The software should be a system user can trust or relay on due to the accuracy
of the information or data it provides. When end users want to perform their task the system
should provide the appropriate data without frustrating users with ambiguous or unreliable
data.
 Reusability: The system, which is divided into sub systems, partitions, layers and
modules, will attain massive reusability. The modules will be repeatedly used in the
different sub systems. And the sub systems and layers are arranged to be used by other
systems outside PFMS. This makes software development to be smooth, speedy and
modifiable.

5.3.2. The Design Trade-Offs

Functionality v. Usability

The system favors usability compared to functionality yet it doesn’t mean that the system loses its
proper functionality. Rather the developing team will endeavor to maintain the basic requirements
of the system along with high usability. The system will avoid waste functionalities, which are not
must for the system’s existence, for the sake of encouraging basic system utilization.

Performance v. portability
The system selects portability compares to performance but not say our system does perform his
task with low performance that annoy every user rather the system performs its operation without
depending specific type of operating system as a result of this users can install the system any
place where ever it needed without bother a kind of plate form they going to use.

Security v. Usability
Possible have lots of reason for selecting security instead of usability but again our system
considers usability besides security. Relating security issues our system will drown line for each
user which functionality of the system need to access by authenticate finally, record each users of
the systems’ information including the task they have done on that specific date, also securing data
during transfer is one of task our system handles additional to others security matter.

Assumptions and Dependencies

The following section deals with describing assumptions or dependencies regarding the software

74
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

and its use. These issues include:

Related software or hardware:

Different software and hardware may be used in relation to this system, which consequently may
create dependencies; end users will probable use text editors, spreadsheet, and PDF. On the other
hand, JavaScript, CSS, Photoshop, will be used for development.

5.4. The Architecture of the Proposed System

It is the architecture that determines the type of interactions that the components are going to have.
The architecture of PFRMS system, that does this work uses Client/Server architecture. In this
type of architecture, the server is responsible to receive a request from the client and respond to
the request, whereas the client is responsible to interact with that of the users of the system. The
server does two types of work. The first type is a web server, which is responsible to receive
browsers’ request through http protocol and responds accordingly. Whereas the second type of
server is a database server, which is responsible to provide the requested database services to the
web server.

The database server is generally responsible for modification and insertion of data to the database.
It can only communicate with the web server. The client side is a web browser which receives
requests from the user of the system and responds to the request by communicating with the web
server. If the user has a request on data, the browser passes the request to the web server then the
web server pass the request to the database server (Shewa&Garl, 2016).

Figure 33: shows three tier of architecture of the system

75
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

The PFRMS is Client–Server architecture and allows a remote access. The following requirements
are mandatory on both Client and Server side.

Client slide

 Internet connection should be available on the client side

 Web browser is demanding to connect with the web server of the system
 Teacher and Admin user should be legitimate and having an account provided by
the system also, students have an account he/her can view post notification and send
message with username and password.
 It should give the URL (Uniform Resource Locator) address of the web site.
Server Side

 The admin user initiates and updates the system using his/her preferred privileges
 It should have Internet connection and database driven-website for remote access.

Figure 34: Three-Tier architecture in deployment

76
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

5.4.1. Sub-system Decompositions

Subsystem decompositions will help to reduce the complexity of the system. The subsystems can
be considered as packages holding related classes or objects (Rumough, 2015).

The PFMS under consideration is decomposed in to subsystems as shown by the following

diagram. These subsystems are further decomposed into other subsystems. Same of subsystem in
our project are listed with their descriptions and operations.

User manager subsystem: - this subsystem is responsible for managing and handling user
information by registering user, create, edit, and delete accounts.

Record: - this subsystem is responsible for Recording every and each activity that system user
performs while using a system services. For this reason, it inherited by all other components of the
system.

Generate report: - this subsystem is responsible for generating weekly reports regarding on
projects, that are done by the system every week.

Scheduling subsystem: - is a subsystem that perform to form groups for students, assign
instructors as advisor or/and examiner and generate letters so as to request and announce them.

Project manager subsystem: - this subsystem is responsible for controlling and managing
projects by upload, edit, delete, search, and download /having softcopy of/ it.

Transaction subsystem: - is a subsystem that handle a collection of different types of transactions.

Those transactions participate on system flow ups and on the circulation of an information and
data between users. Some of them are; send data, inbox data, view sent data, view done-task
history, users information and so on.

77
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 35: subsystem decomposition for PFRMS

78
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

5.4.2. Deployment Diagram

Deployment diagram show how the system will have deployed on computers. In other words,
deployment diagrams show the hardware of the system, the software that is installed on that
hardware, and the middleware used to connect the disparate machines to one another. We want to
create a deployment diagram for applications that are deployed to several machines (Addison-
Wesley, 2006).

Deployment diagram is used to show the following:

 Show which software elements are deployed by which hardware software elements.
 It illustrates the runtime processing for hardware.
 It provides views of the hardware system’s topology.

Some of the deployment diagram elements:

 Artifact: A product developed by the software, symbolized by a rectangle with name and
the word “artifacts” enclosed by double arrows.
 Associations: A line that indicates the message or, other types of communication between
nodes.
 Components: A rectangle with the two tabs that indicates software elements.
 Dependencies: A dashed line ends in an arrow, which indicates that one node or
components is depends on the other.
 Interface: A circle that indicate a contractual relationship, those object that realize the
interface must complete some sort of obligations.
 Node: A hardware or software objects shown by the three-dimensional box.
 Node as container: A node that contains another node inside on it.
 Stereotype: A device contained within the node, presented at the top of the node with name
bracketed by double arrows.

79
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 36:deployment diagram for our project

5.4.3. Persistence data management system

Persistent data are the data that are stored in a database permanently. This section typically includes
the description of data schemes, the selection of a database. Our system will use the MYSQL
database engine for storing data.

We use object-oriented databases for our system instead of relational databases, so instead of
designing E-R diagram we use persistence models to show the mappings and the relations of tables.
The purpose of persistence modeling is which objects in the system design are required to be stored
persistently.

80
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Information related to user, create account, view posted comment, feedback, and update is
persistent data, which should be stored in the Database Management System. This allows the
programs that operate on these data to do consistently. Moreover, storing data in a database enables
the system to perform complex queries on a large data set.

Figure 37: database design

Mapping

In order to store information persistently we map objects into tables and the attributes into fields
to the specific table based on the objects found on the system. Therefore, we identified nine tables
that will be implemented on the PFRMS. For this reason, the mapping of objects to tables is
displayed as follows: -

81
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

This part is to describe and show the necessary relationships among the tables, which are selected
to store the data persistently in the system. There are three types of relationships in this system.
 One-to-One Relationships
 Many-to-Many Relationship
 One-to-Many relationship.

82
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

83
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Figure 38:perisitance data management class mappings

84
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

5.4.4. Class Interface

Class interface is similar to writing a class. But a class describes the attributes and behaviors of
an object. And an interface contains behaviors that a class implements.

Unless the class that implements the interface is abstract, all the methods of the interface need to
be defined in the class. In our proposed systems, all actors have their own accessibility to different
functionalities.

Class interfaces design

Class User

Attributes are username, password, and object attributes.

Methods:

a. +Login ()

Pre-condition: - user must have an account and fill it in fields properly.

Post- condition: - user logged to the system.

b. +viewProfile ()

Pre-condition: - user must logged to a system with his/her private account.

Post-condition: - profile is viewed.

c. +changeProfile ()

Pre-condition: - current password should be filled.

85
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Post-condition: - profile password is changed.

d. +Logout ()

Pre-condition: - system should be logged by user.

Post- condition: - system is closed in secured.

Class Form_Group

Attributes: - name, member, formtype, year, section, …

Methods/operations of the class

a. +GetStudentInfo ()
Pre-condition: - information of students should be in the database of the system.
Post-condition: - student’s name and related information is listed.

b. +formGroup ()
Pre-condition: - student information is listed down and form type is selected.
Post-condition: - groups of specified students is formed.
c. +Preview ()
Pre-condition: - groups should be formed and generated.
Post-condition: - form is displayed.
d. +post ()
Pre-condition: - groups should be formed and previewed.

86
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Post-condition: - form is posted for intended or for all student groups.

Class Generate Report

Attributes: username, remark, week, groupname, signature, …...

Methods

a. +newTask ()
Pre-condition: - required information should be filled.
Post-condition: - new task is added to user account database.
b. +evaluateTask ()
pre-condition: - new task should be added and not evaluated before.
Post-condition: - added task is evaluated and remarked.
c. +generateReport ()
pre-condition: - current week tasks must be added and previous tasks should be
evaluated.
Post-condition: - report is generated.
d. +preview ()
Pre-condition: - report should be generated.
Post-condition: -report is displayed.

Class Project

87
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Attributes: - developers, title, name, year, department, result, abstract/description, …

Methods/ operation in the class

a. +CheckFile ()
Pre-condition: - file or data should be selected.
Post-condition: - file type and size is checked.
b. +Upload ()
Pre-condition: - system is must be logged, selected file and inserted information should be
valid.
Post-condition: - intended file and information is added to system database.
c. +Update ()
Pre-condition: - file to be update should be in the database and believed that, there is an
error is occurred.
Post-condition: - selected file is updated.
d. +Description ()
Pre-condition: - file must selected and valid information must be inserted to fields.
Post-condition: - description of project file is added to database
e. +dataList ()
Pre-condition: - file to be searched should be in the database and characters inserted in the
fields must be in the database.
Post-condition: - file label with the same value of inserted characters listed down as
response for search.

88
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Class Schedule

Attributes: username, sched_Id, schType, title, subtype, ….

Methods/operations

a. +getStudentInfo ()
pre-condition: - student information should be in the system database.
Post-condition: - name, group, section and project title is listed down.
b. +getInstructorInfo ()
pre-condition: - instructor information should be in the system database.
Post-condition: - needed information is listed down, i.e. name and subject type.
c. +Schedule ()
Pre-condition: - type of schedule is selected, student and instructor information is listed.
Post-condition: - instructors are assigned as advisor or/and examiner.
d. +Preview ()
Pre-condition: - instructor should be assigned between groups.
Post-condition: - assigned result is displayed format.
e. +post ()
Pre-condition: - schedule of instructors must finished.
Post-condition: - format of schedule result is posted.

Class Generate_letter

89
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Attributes: title, name, body, …

Methods/operations

a. -GetLetterList ()
Pre-condition: - saved letter should be in the system database.
Post-condition: - letter saved in the database before is listed.
b. +generateLetter ()
Pre-condition: - new letter button form should have selected and inserted information
must valid.
Post-condition: - new letter is created and generated.
c. +Edit ()
Pre-condition: - letter to be modified must be saved in the database.
Post-condition: -selected letter is edited.
d. +Preview ()
Pre-condition: - letter should be generated or/and edited.
Post-condition: - letter format is displayed.
e. Send (receiver)
Pre-condition: - letter to be send and receivers address should have selected.
Post-condition: - selected letter is sent.

Class Project_deadLine

90
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Attributes: title, body, date/time, username, ….

Methods/operations

a. +addDeadLine ()
Pre-condition: - inserted information should have valid.
Post-condition: - new date is added to a system as due date of the project submission.
b. +editDeadLine ()
Pre-condition: - date deadline should be added.
Post-condition: - deadline date is edited.
c. +deleteDeadline ()
Pre-condition: - date deadline should be added.
Post-condition: - deadline date is deleted.
d. +display ()
Pre-condition: - deadline date should be settled.
Post-condition: - date is displayed on the screen until expired.

Class RSC and IL /at college level/

Attributes: name, department, user role, mark, subject Type, year, ….

91
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Methods/operations

a. +register ()
Pre-condition: - inserted information should be valid.
Post-condition: - information of users is registered.
b. +createAccount ()
Pre-condition: - user information should be registered.
Post-condition: - user account is created.
c. +editAccount ()
Pre-condition: - user account should have created.
Post-condition: - user account is edited.
d. +userRole ()
Pre-condition: - information inserted should be valid.
Post-condition: - user role is selected and added to system.
e. +deleteAccount ()
Pre-condition: - user account should have created.
Post-condition: - user account is deleted

Class Transaction/data, file, or message/

Attributes: time, record, username, transactiontype, …

Methods

a. +send ()
Pre-condition: -file/message, notification/ and destination address should be selected.

92
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Post-condition: - selected item is sent.

b. +inbox ()
Pre-condition: - system should have notify.
Post-condition: -sent files listed in categories.
c. +viewHistory ()
Pre-condition: -each and every activity/task/ should be recorded.
Post-condition: - performed and done tasks are listed down as history.
d. +Information ()
Pre-condition: - user’s information should have registered.
Post-condition: - user’s information is viewed with limitation.

5.5. User interface

Home page user interface screen layout.

Figure 39:Home page user interface

93
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Generate new letter user interface screen layout

Figure 40:Generate new letter user interface

Create account user interface screen layout

Figure 41:Create account user interface

94
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Generate report user interface screen layout

Figure 42:Generate report user interface

Upload file from the system user interface screen layout

Figure 43:Upload file from the system user interface

95
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Repository user interface screen layout page

Figure 44:Repository user interface

Generate letter user interface screen layout page

Figure 45:Generate letter user interface

96
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

Conclusion
In this project, we develop Project flow up and repository managing system

The system developed is web application by PHP the system allows the student submit their project
and meet with their advisors. The system allows to the department to manage the students and
instructors regarded with project. The system allows for advisors to communicate with the students
and department heads. The system notifies the student to when the deadline of the project is. The
system allows for college heads to assign examiners for each department student groups during
their project presentation.

Our model contains analysis model which contains the functional and non- functional
requirements, use case, sequence, state diagram, activity diagram, conceptual modeling of classes
and user interfaces. And also contains design model which consists subsystem decomposition,
component diagram, deployment diagram, persistence modeling of classes.

97
PROJECT FLOW UP AND REPOSITORY MANAGING SYSTEM

References
1) Addison-Wesley. ( 2006). Curescu, Object Oriented Analysis and Design andSoftware
Development Process, England: Addison-Wesley., 2006.
2) Booch. (2015). Booch, Object-Oriented Analysis and Design with Applications, 2nd ed.
Benjamin/Cummings, Redwood City, CA, 199.
3) Coad. (2015). Object-Oriented Software Engineering, 6th editon.
4) Fowler. (214). Fowler, Analysis Patterns: Reusable Object Models. Addison-Wesley,
Reading, MA, 1997.
5) Jacobsons. (2015). Object-Oriented Software Engineering,.
6) Rumough. (2015). Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-
Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.
7) Shewa&Garl. (2016). Shaw & D. Garlan, Software Architecture: Perspectives on an
Emerging Discipline. Prentice Hall, Upper Saddle River, NJ, 1996.

98