Haramaya University

College of Computing and Informatics

School of Information Systems
Department of Information Systems
Final Year Project Documentation
Title: Construction Management System
Submitted to Department of Information Systems

January, 2013

Haramaya University

Table of Contents
List of Acronym and Abbreviations.................................................................................................I

Page | I
List of Figures.................................................................................................................................II
Acknowledgment...........................................................................................................................III
Abstract..........................................................................................................................................IV
Chapter One.....................................................................................................................................1
1. Introduction..............................................................................................................................1

1.1. Description of the Existing System...................................................................................1

1.2. Problems in the Existing System......................................................................................1
1.3. Objectives..........................................................................................................................2

1.3.1. General Objectives.....................................................................................................2

1.3.2. Specific Objectives....................................................................................................2

1.4. Scope and Limitation of the Study....................................................................................2

1.5. Methodology.....................................................................................................................3

1.5.1. Method of Data Collection........................................................................................3

1.5.2. System Development Methodology..........................................................................3

1.6. System Implementation Tools..........................................................................................3

1.7. Test and Deployment........................................................................................................4

1.7.1. Module Testing..........................................................................................................4

1.7.2. Integrated Testing......................................................................................................4
1.7.3. Deployment................................................................................................................4

1.8. Feasibility Study...............................................................................................................4

1.8.1. Economic Feasibility.................................................................................................5

1.8.1.1. Tangible Benefits...................................................................................................5
1.8.1.2. Intangible Benefits.................................................................................................5
1.8.2. Operational Feasibility...............................................................................................5
1.8.3. Technical Feasibility..................................................................................................5
1.8.4. Schedule Feasibility (using Gantt chart)....................................................................5
1.8.5. Legal and Contractual Feasibility..............................................................................6
1.8.6. Political Feasibility....................................................................................................6
1.8.7. Risk Feasibility..........................................................................................................7

1.9. Team Configuration and Communication Plan................................................................7

1.10. Significance of the Study and Beneficiaries..................................................................7

Page | II
Chapter Two....................................................................................................................................8
2. Description of the System Development Methodology and its life cycle...............................8

2.1. Problem Analysis..............................................................................................................9

2.1.1. Fact Finding Techniques and Results........................................................................9

2.1.1.1. Fact finding techniques..........................................................................................9
2.1.1.2. Interview..............................................................................................................10
2.1.1.3. Document Analysis..............................................................................................10
2.1.1.4. Observation..........................................................................................................11
2.1.2. Result.......................................................................................................................11

2.2. Overview of the existing system.....................................................................................12

2.3. Problem of the existing system.......................................................................................12
2.4. Overview of the proposed system...................................................................................12
2.5. System Requirements......................................................................................................13
2.5.1. Functional Requirements.........................................................................................13
2.5.2. Non-Functional Requirements.................................................................................14
2.5.2.1. Performance.........................................................................................................14
2.5.2.2. User Interface.......................................................................................................14
2.5.2.3. Security and Access permissions.........................................................................14
2.5.2.4. Backup and Recovery..........................................................................................14

2.6. Requirement Analysis.....................................................................................................15

2.6.1. Essential Use Case Diagram and Documentations..................................................15

2.6.1.1. Essential Use Case Diagram................................................................................15
2.6.2. Essential Use Case Documentation.........................................................................17
2.6.2.1. Use case documentation for login........................................................................17
2.6.2.2. Use case documentation for monitor schedule....................................................17
2.6.2.3. Use case documentation for assure quality..........................................................18
2.6.2.4. Use case documentation for approve contractor’s request...................................18
2.6.2.5. Use case documentation for manage changes to the requirement.......................19
2.6.2.6. Use case documentation for make payment.........................................................19
2.6.2.7. Use case documentation Hire Contractor.............................................................20
2.6.3. Essential User Interface Development.....................................................................20
2.6.4. User Interface Flow Diagram..................................................................................22

Page | III
 2.6.5. Domain Modeling (Class Responsibility Collaboration /CRC/).............................22
2.6.6. Business Rules.........................................................................................................24
2.6.7. Analysis Modeling...................................................................................................24
2.6.8. System Use Case Diagram and Documentations.....................................................25
2.6.8.1. System use case diagram......................................................................................25
2.6.8.2. System Use case Documentation.........................................................................26
2.6.8.3. Use case documentation for login........................................................................26
2.6.8.4. Use case documentation for Manage the site supervisor.....................................27
2.6.8.5. Use case documentation for monitor schedule....................................................27
2.6.8.6. Use case documentation for assure quality..........................................................28
2.6.9. Sequence Diagram...................................................................................................29
2.6.10. Activity Diagram..................................................................................................35
2.6.11. Conceptual Class Diagram...................................................................................41
2.6.12. Class Diagram......................................................................................................42

Chapter Three................................................................................................................................44
Design Phase..................................................................................................................................44
3. Introduction............................................................................................................................44

3.1. Design Goals...................................................................................................................44

3.2. User interface identification............................................................................................45
3.3. User interface design.......................................................................................................45
3.4. Design Class Diagram.....................................................................................................45
3.5. State Chart Diagram........................................................................................................46
3.6. Persistent Modeling / Database Design..........................................................................47

3.6.1. Entity relationship diagram......................................................................................47

3.7. Normalization..................................................................................................................49
3.8. Deployment Diagram......................................................................................................52
3.9. Component Modeling.....................................................................................................53
References......................................................................................................................................54
Appendix........................................................................................................................................55
Interview....................................................................................................................................55

Page | IV
 List of Acronym and Abbreviations

BR ---------------------------------------------------- Business Rule

CMS ---------------------------------------------------Construction Management System

CPM -------------------------------------------------- Construction Project Management  

CRC -------------------------------------------------- Class Responsibility Collaboration

EU ---------------------------------------------------- Engineering Unit

ERD -------------------------------------------------- Entity Relationship Diagram

GB ----------------------------------------------------- Giga Byte

GUI --------------------------------------------------- Graphical User Interface

HU ---------------------------------------------------- Haramaya University

RAM -------------------------------------------------- Random Access Memory

SQL --------------------------------------------------- Structured Query Language

UC ----------------------------------------------------- Use Case

UML ------------------------------------------------- Unified Modeling Language

VB ---------------------------------------------------- Visual Basic

VP ---------------------------------------------------- Vice President

Page | I
 List of Figures

Figure 1. ----------------------------------------------------------- Schedule for the project

Figure 1.1. -------------------------------------------------------- Waterfall Model

Figure 4.1.1. ------------------------------------------------------- Essential Use Case Diagram

Figure 4.2. --------------------------------------------------------- Login Screen

Figure 4.2. --------------------------------------------------------- User Interface Diagrams

Figure 4.3. --------------------------------------------------------- User Interface Flow Diagram

Figure 4.4. --------------------------------------------------------- CRC diagram

Figure 4.10. ------------------------------------------------------- Conceptual Class Diagram

Figure 5.5. --------------------------------------------------------- State Chart Diagram

Figure 5.6. --------------------------------------------------------- Persistent modeling/database design

Figure 5.6.1. ------------------------------------------------------- Entity Relationship Diagram/ERD

Figure 5.7. --------------------------------------------------------- Normalization

Figure 5.8. --------------------------------------------------------- Deployment Diagram

Figure 5.9. --------------------------------------------------------- Component Modeling

Page | II
 Acknowledgment

This project would not have been possible without the support of many people. We would like to
express our gratitude to our advisor, Mrs. Ramma who was abundantly helpful and
offered invaluable assistance, support and guidance. Next, we would like to thank Engineering
Unit Head Mr. Daniel for giving the required information for us. Special thanks also to all our
graduate friends, especially group members; Kedir, Mereke, Neima and Teshome for sharing the
literature and invaluable assistance. Not forgetting to our best friends who always been there. We
would also like to convey thanks to the School of Information Systems for providing the
computer laboratory facilities.  We wish to express our love and gratitude to our beloved
families; for their understanding & endless love, through the duration of our studies.

Page | III
 Abstract

Construction Management or Construction Project Management (CPM) is the overall planning,

coordination, and control of a project from inception to completion aimed at meeting a client’s
requirements in order to produce a functionally and financially visible project. This paper is the
system analysis and design part of construction management system. The system analysis phases
shows that what the existing system does and what the problems are. But the design phase shows
the new proposed system and it shows the solutions to the problems of the existing system.

Page | IV
 Chapter One

1. Introduction

Haramaya University is one of the famous Universities in Ethiopia. It is found in the eastern part
of Ethiopia between Dire Dawa and Harar. This University gives different courses in different
departments. Among these departments Information Systems is the one in which we are going to
develop a software to the office of Construction Management.
Construction Management is a professional field that focuses on each part of the construction
process of any built environment. It typically encompasses commercial building site or multi-
unit residential sites. Construction Management of the site may be maintained by a general
constructor or a separator entity, and the construction management personnel or company
answers to the development and is responsible for overseeing every aspect of the project from
start to finish.
The purpose of this project is to support the organization in many ways. From those ways some
of them are:-
 Save the time that is lost while doing some jobs manually
 Protect the organization file from accident
 Protect the data of the organization from accessing of unauthorized person
 Support simulations document preparation of different office of the organization and
finally to enable the construction performance

1.1. Description of the Existing System

In Haramaya University Construction Management is very crucial and complex activity,

because, it contains different sub components. Such as: project quality assurance management,
project time management, project material management. This system involves three types of
actors. These are employer, consultant (advisor) and contractor.
The manual way of data handling and running up of the activities is time and human power
consuming, resource wasting and boring one. And also due to its time consuming features many
consultants waste their time instead of filling the form.

1
 1.2. Problems in the Existing System

The current system of the engineering unit office is fully manual system. Using manual system
by itself has no problem. But the problems that occur in this manual system are based on the
manager and employees who work in the system. Since, some of the problems those occur in the
system are discussed below.
There is a gap between project plan and the result. This means the planned project and the budget
of the project are mismatched. It is because of lack of good time management. The lack of good
time management may affects the overall project process. That means if the planned schedule
extends by two week, the project may need additional budget for the extended two week, and
may also need additional man power and material resources. Improper use of construction
material is another problem. This means using extra material for a given activity.

1.3. Objectives

1.3.1. General Objectives

The general objective of this project is to develop window application software for Engineering
Unit of Haramaya University and to change the manual system to computerize. This Engineering
Unit manages different construction sites which are found in Haramaya University, Chiro
campus, Harar Health campus and Harar town. To manage all this construction sites we are
going to provide software called Construction Management Software. Finally, the purpose of this
project is to improve the problems of current system.

1.3.2. Specific Objectives

In addition to the general objectives, we provide some specific objectives in the following
manner:-
 To simplify the work load of the Engineering Unit (EU)
 To improve project time management
 To improve project material management
 To reduce paper work
 To reduce loss of data

2
 1.4. Scope and Limitation of the Study

Scope is an area in which something acts or operates or control. And it indicates the boundary or
size of project. The scope of our project, Construction Management System (CMS), includes
construction sites which are found in HU main campus, Harar Health campus, Harar town and
Chiro campus. In addition to these sites our project lets the employee management, construction
material management, time management.
Although, our project has the above scope, it has some limitations. One of the limitations of the
project is inability to do all activities of the office. The office of Engineering Unit supervises
different activities, such as: controlling quality assurance, time monitoring, and construction
material management. Among these activities our project is unable to do controlling quality
assurance.

1.5. Methodology

1.5.1. Method of Data Collection

To propose this project we have used the following data collection method.
 Interview: - An interview is a conversation between two or more people where questions
are asked by the interviewer to draw out facts or statements from the interviewee. And we
have made an interview with head of the Engineering Unit to get an overview of the
current system and the problem of the existing system.
 Observation: - is an act or instance of viewing or noting a fact or occurrence for some
scientific or other special purpose.
 Documentation: - is written document which is stored in the office that shows the
overview of the existing system.

1.5.2. System Development Methodology

A system development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. There are different types of system
development methodologies to develop information system; among these we select waterfall
system development method. Because, Waterfall model is simple to implement and also the
amount of resources required for it are minimal when compared to the others.
In this model, output is generated after each stage, therefore it has high visibility. The client and
project manager gets a feel that there is considerable progress.

3
 1.6. System Implementation Tools

The hardware and software requirements of the system gong to develop are listed below;
 Software:
 Microsoft SQL Server 2012
 Microsoft ASP.NET with Visual Basic (VB)
 Window 7 operating system
 Microsoft Visio
 Hardware
 40 and above GB Hard disk
 2 GB RAM
 Languages
 English
 Amharic Font

1.7. Test and Deployment

1.7.1. Module Testing

Testing of individual software components or modules. Typically done by the programmer and
not by testers, as it requires detailed knowledge of the internal program design and code. May
require developing test drive modules or test harnesses.

1.7.2. Integrated Testing

Integration Testing is a level of the software testing process where individual units are
combined and tested as a group. The purpose of this level of testing is to expose faults in the
interaction between integrated units.

1.7.3. Deployment

Deployment is methodical procedure of introducing an activity, process, program, or system to

all applicable areas of an organization. And the developed software is going to be installed on the
project supervisor’s computers. We will prepare user manual for the developed system to how to
install and use the system.

4
 1.8. Feasibility Study

Much of the feasibility studies are included within the project group members and many ideas
have been raised. As a result most of the ideas raised are taken as an appropriate option and the
ideas mention the solution to the way we can go through our software (project). Among these
most of the ways are studied under the following techniques.

1.8.1. Economic Feasibility

1.8.1.1. Tangible Benefits

Benefits that are easily quantified from the conducted system are:
 Fastest processing time and small amount of processing error.
 Small response time And many services
 Easy and fast file management.
 Reduce cost for manual data management (Reduced expenses)
 Easy update & retrieval on stored records

1.8.1.2. Intangible Benefits

Benefits from the system that areas unquantifiable are;
 Better decision making
 Better service to the office
 Little job burden to employees of office

1.8.2. Operational Feasibility

We perform the activity firstly by having the understanding of main problem manual system
have and we taught changing this manual system to somehow an automating manner is the best
thing and depending on this, the project result is operational since it solves their problem. And to
make the workers familiar with the technology, we will give the training for about the software
to the working place. So that, the organization’s workers can themselves run and operate with the
software then after.

1.8.3. Technical Feasibility

Generally speaking, using the different techniques, we can perform the work up to the desire of
the organization, even though fulfilling human being’s need in all direction may be difficulty and
impossible.

5
 1.8.4. Schedule Feasibility (using Gantt chart)

This involves questions such as how much time is available to build the new system, when it can
be built (i.e. during holidays) interference with normal business operation etc. The schedule for
this project is feasible due to rich information exchange between the organization (client) and the
developing team. In addition to the time set to develop the system is enough to complete the
project on time.

Figure1: - Schedule for the project

1.8.5. Legal and Contractual Feasibility

Assuming ourselves as someone that have a full privileges to perform such activities, and having

6
enough deep knowledge about the problem, law cannot permit us to work with and giving
solutions to such problems. So we could.

1.8.6. Political Feasibility

Political considerations often dictate directions for a proposed project. This is particularly true
for large projects with significant visibility that may have significant government inputs and
political implications. For example, political necessity may be a source of support for a project
regardless of the project's merits. On the other hand, worthy projects may face impossible
opposition simply because of political factors. Political feasibility analysis requires an evaluation
of the compatibility of project goals with the prevailing goals of the political system.
1.8.7. Risk Feasibility

As we can understand from the word “risk” it is exposing to a chance of loss and damage the
resource of the project. If we consider risk feasibility in our project duration we may not face
problems, even if we face a problem we can manage or handle them. Because, we have studied
the risk feasibility.

1.9. Team Configuration and Communication Plan

In this project four students (Kedir, Teshome, Neima and Mereke) are involved. And their roles
are listed below.
 System analyst and assistant manager
 Database designer
 Programmer and front-end designer

1.10. Significance of the Study and Beneficiaries

We categorize the benefits of the system into tangible and intangible.
Tangible benefits:
 Reduce processing errors
 Decreased response time
 Manpower reduction
 Cost elimination
 Reduced credit losses

Intangible benefits:
 Improve customer satisfaction

7
  Improve employee role
 Better decision making

Chapter Two
2. Description of the System Development Methodology and its life
cycle

A system development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. There are different types of system
development methodologies to develop information system; among these we select waterfall
system development method. Because, Waterfall model is simple to implement and also the
amount of resources required for it are minimal when compared to the others.
In this model, output is generated after each stage, therefore it has high visibility. The client and
project manager gets a feel that there is considerable progress.
The waterfall model is the classical model of software engineering. This model is one of the
oldest models and is widely used in government projects and in many major companies. As this
model emphasizes planning in early stages, it ensures design flaws before they develop. In
addition, its intensive document and planning make it work well for projects in which quality
control is a major concern.
The pure waterfall lifecycle consists of several non-overlapping stages, as shown in the
following figure. The model begins with establishing system requirements and software
requirements and continues with architectural design, detailed design, coding, testing, and
maintenance. The waterfall model serves as a baseline for many other lifecycle models.

8
Figure 1.1: Waterfall model

2.1. Problem Analysis

2.1.1. Fact Finding Techniques and Results

2.1.1.1. Fact finding techniques

Fact finding is the formal process of using research, document analysis, interviews,
questionnaires, and other techniques to collect information about systems, requirements, and
preferences. It is also called gathering or data collection. Among those methods we used
interview, observation and document analysis.

9
 2.1.1.2. Interview

This is one of data collection method that enables to gather information from the organization
directly in the form of asking question and getting answers for those questions. So, we have used
this method to gather information by asking the head and employers of the registrar some basic
questions.
Some questions that we asked the registrar are:
o How construction management system is going on?
o During construction time, are there any problems? If there, what are they?
o What requirements are needed for the process?
o Who is responsible for what?

2.1.1.3. Document Analysis

This is another data collection method that enables to gather information from the organization
direct looking the written document. Among those documents we have seen contract agreement
document, check list document and a document which contains terms and their definition and
interpretation. The following picture is a sample of single check list for work permit.

10
 2.1.1.4. Observation

This is also another data collecting method. This method is done by observing and understanding
what the office do during their current work. In fact we have also used this observation method
to gather data. As we have seen in the place of construction the site supervisor supervises the
overall project processes. And he has his own office at that place.

2.1.2. Result

We have gathered information by using the above methods, and the methods help us to get
information about the existing system. As we have asked the head of Engineering Unit office of
Haramaya University Mr. Daniel, he told us the main actors of the system and their

11
responsibilities. From the documents given to us we understand some terms which are new for
us, and we used those terms and their interpretation in the time of identifying actors and use
cases of the system.

2.2. Overview of the existing system

In Haramaya University Construction Management is very crucial and complex activity,

because, it contains different sub components. Such as: project quality assurance management,
project time management, project material management. This system involves three types of
actors. These are employer, consultant (advisor) and contractor.
The manual way of data handling and running up of the activities is time and human power
consuming, resource wasting and boring one. And also due to its time consuming features many
consultants waste their time instead of filling the form.

2.3. Problem of the existing system

The current system of the engineering unit office is fully manual system. Using manual system
by itself has no problem. But the problems that occur in this manual system are based on the
manager and employees who work in the system. Since, some of the problems those occur in the
system are discussed below.
There is a gap between project plan and the result. This means the planned project and the budget
of the project are mismatched. It is because of lack of good time management. The lack of good
time management may affects the overall project process. That means if the planned schedule
extends by two week, the project may need additional budget for the extended two week, and
may also need additional man power and material resources. Improper use of construction
material is another problem. This means using extra material for a given activity.

2.4. Overview of the proposed system

After a thorough investigation of the currently working system, we need able to identify the
critical problems clearly observed (that was explained in the limitation of the existing system in
the proposal). Therefore, in order to solve these problems we have established a new system that
would benefit the organization in doing so.
The major benefit that the new proposed system would provide is: -
 To simplify the work load of the Project Engineer and Site supervisor
 To improve project time management

12
  To improve project cost management
 To improve project material management
 To reduce paper work
 To reduce loss of data
 Minimizes most paper based works
 It facilitate the working system of the organization
The new system works by taking the input from the user and store the input in the database for
the future use. The inputs are likes:
 Project schedule (starting and ending date)
 Customer name
 Current site status
 Site name
 Day-to-day activity
And these inputs are processed by an authorized person and get the information from the
database by some criteria like site number, project number, and location and so on.

2.5. System Requirements

2.5.1. Functional Requirements

Functional requirements are system requirements, in this project which specifies a function and
defines behavior of the system that a system component must be capable of performing tasks on
inputs to produce outputs. Functional requirements listed below have to be considered in this
system development.
 Data validation: - is validating the data which is going to inserted in to the system. This
means for instance restricting entering string in the phone number place.
 Storing all data: - handling all the data in the system database.
 Insert construction information: - all information about the project should be stored in
the system database. For instance the current status of the project and the current man
power information should be put to the system.
 Search construction information: - searching or retrieving the information of the project
during the construction.
 Update the schedule, if it is necessary: - first the consultant prepares the schedule and in
the middle if the consultant wants to modify the schedule the system should permit to
update the schedule.

13
  Generating report: - the system should generate report about the current project status
and the reports about man power and material resources.

2.5.2. Non-Functional Requirements

Non-functional requirements place restrictions on the product being developed, the development
process, and specify external constraints that the product must meet. This requirement considers
only the front end values rather than values that have relation with the database. Now here non
functional requirements according to this system are described:

2.5.2.1. Performance

The response time of the system is fast because it runs with height the speed.

2.5.2.2. User Interface

Describe the logical characteristics of each interface between the system and the users. This may
include any GUI standards or product family style guides, screen layout constraints, standard
buttons and functions that will appear on every screen, error message display standards, and so
on. So this system does these all functions in easy and efficient way.

2.5.2.3. Security and Access permissions

Consideration of the security of the system has a great advantage for this system, because the
database should be secured from the unauthorized users. Only the clerks and those who have
access permission are authorized to access the database. To prevent from the unauthorized user,
the user should have admin password and it is used privatized only for who has access rights.
The admin password should be changed regularly.

2.5.2.4. Backup and Recovery

When team member stand to develop a system they must have to put use a backup mechanism by
using removable flash disks, or CDs because the system will be lost because of viruses or power
fluctuations. The other thing is recovery of recorded files which may lose because of viruses or
other data destroying phenomena’s.

14
 2.6. Requirement Analysis

Requirement Analysis for software development projects is the exploratory, developmental

activity of helping users figure out what they want and recording the same for further use in the
subsequent phases of development.

2.6.1. Essential Use Case Diagram and Documentations

2.6.1.1. Essential Use Case Diagram

In this phase team member bring together the models or diagrams supporting textual information
that constitute the requirement model. It is important to remember that in a project that adopt
interactive life cycle, these activities may take place over a serious of iterations.

15
Figure 4.1.1. Essential Use Case Diagram

16
 2.6.2. Essential Use Case Documentation
2.6.2.1. Use case documentation for login

Use case name Login

Use case number Uc1
Actor Site supervisor
Description When each site supervisor enters id and password, it checks the input from the
database. If it is valid, it allows the user to access and if not it display
unauthorized message.
Typical course of action: Actors action Systems response
Step1: this use case is initiated Step2: the systems display the login
when the the supervisor click on forms.
the login option Step4: the systems verifies whether the
Step3: the supervisor enter the id supervisor is authorized or not. If he/she
and password is authorized systems display the main
page
Alternate course of Step3: if the supervisor does not fill the appropriate id and password then the
action: systems display error message and return to step 2
Pre-condition The supervisor must be authorized for the work
The get into the system
Post-condition

2.6.2.2. Use case documentation for monitor schedule

Use case name Monitor schedule

Use case number Uc2
Actor Site supervisor
Description When each site supervisor wants to do with the schedule, the system should allow
using the schedule form.
Typical course of Actors action Systems response
action: Step1: this use case is initiated when the Step2: the systems display the
supervisor click on the schedule option schedule form.
Alternate course of Step1: if the supervisor does not initiated to work with the schedule, the system
action: displays nothing
Pre-condition The supervisor must be authorized for the work

17
 The get into the system
Post-condition

2.6.2.3. Use case documentation for assure quality

Use case name Assure quality

Use case number Uc3
Actor Site supervisor
Description When each site supervisor wants to do with the quality assurance, the system
should allow using the schedule form.
Typical course of Actors action Systems response
action: Step1: this use case is initiated when the Step2: the systems display the
supervisor click on the quality assurance quality assurance form.
option
Alternate course of Step1: if the supervisor does not initiated to work with quality assurance, the
action: system displays nothing
Pre-condition The supervisor must be authorized for the work
The get into the system
Post-condition

2.6.2.4. Use case documentation for approve contractor’s request

Use case name Approve contractor’s request

Use case number Uc4
Actor Engineer
Description Contractors provide the request to the engineer and then the engineer approve the
contractor’s request
Typical course of Actors action
action: Step1: this use case is initiated when the contractor wants to send request to the
engineer.
Step2: the engineer will confirm the contractor’s request
Step3: the engineer approve the contractor’s request

18
Alternate course of Step2: if the engineer do not confirm the contractor’s request, the contractor
action: cannot get any response
Pre-condition The engineer must be authorized for the work
Approving the contractor’s request
Post-condition

2.6.2.5. Use case documentation for manage changes to the requirement

Use case name Manage changes to the requirement

Use case number Uc5
Actor Engineer
Description Managing the changes to the requirements of the construction contact and to the
design

Typical course of Actors action

action: Step1: this use case is initiated when the contractor wants to send request to the
engineer.
Step2: the engineer will confirm the contractor’s request
Step3: the engineer approve the contractor’s request
Alternate course of Step2: if the engineer do not confirm the contractor’s request, the contractor
action: cannot get any response
Pre-condition The engineer must be authorized for the work
Approving the contractor’s request
Post-condition

2.6.2.6. Use case documentation for make payment

Use case name Make payment

Use case number Uc6
Actor Owner
Description Make payment of the Cost of the Work in accordance with the agreement

Typical course of Actors action

action: Step1: this use case is initiated when the owner wants to begin the construction
project
Step2: the owner will hire contractor and make agreement with the contractor

19
 Step3: the contractor begin the project
Step4: the owner make the payment to the contractor
Alternate course of Step2: if the owner and the contractor cannot agree, the contractor do not begin
action: the project
Pre-condition The owner must be authorized for the work
The owner and the contractor agreed, and the project begin
Post-condition

2.6.2.7. Use case documentation Hire Contractor

Use case name Hire Contractor

Use case number Uc7
Actor Owner
Description The owner hires the contractor to perform the job and the project. Make payment
of the Cost of the Work in accordance with the agreement

Typical course of Actors action

Step1: this use case is initiated when the owner wants to begin the construction
action:
project
Step2: the owner will hire contractor and make agreement with the contractor
Step3: the contractor begin the project
Step4: the owner make the payment to the contractor
Alternate course of Step2: if the owner and the contractor cannot agree, the contractor do not begin
action: the project
Pre-condition The owner must be authorized for the work
The owner and the contractor agreed, and the project begin
Post-condition

20
 2.6.3. Essential User Interface Development

Figure 4.2. Login Screen

21
Figure 4.2. User Interface Diagrams

22
 2.6.4. User Interface Flow Diagram

Figure 4.3. User Interface Flow Diagram

2.6.5. Domain Modeling (Class Responsibility Collaboration /CRC/)

Class responsibility collaboration is a collection of standard index cards that have been divided
into three sections. A class represents a collection of similar objects, a responsibility is
something that a class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities [8].  In construction management systems there are class. These
are owner, Engineer, contractor, consultant, site supervisor and Employee.

23
Figure 4.4. CRC diagram

24
 2.6.6. Business Rules

A business rule is a rule of a business, company, or corporation. It is a rule that defines or

constrains some aspect of business and always resolves to either true or false. Business rules are
intended to assert business structure or to control or influence the behavior of the
business. Business rules describe the operations, definitions and constraints that apply to an
organization. Business rules can apply to people, processes, corporate behavior and computing
systems in an organization, and are put in place to help the organization achieve its goals. [7]

The following are business rules of the construction management

BR01. The Contractor shall be responsible for the safety of all activities on the Site.
BR02. The language of the Contract is English or Amharic and the law governing the Contract is
that of the Federal Democratic Republic of Ethiopia.
BR03. Consultant will decide contractual matters between the Employer and the Contractor in
the role representing the Employer.
BR04. The only who supervise the quality assurance in the construction process is the site
supervisor.
BR05. If the employer wants to begin a new project, he/she should contact the consultant.
BR06. The Contractor shall construct and install the Works in accordance with the Specifications
and Drawings.
BR07. All payments shall be made in Ethiopian Birr.
BR08. The Contractor shall carry out all instructions of the Engineer, which follow (comply)
with the applicable laws where the Site is located.

2.6.7. Analysis Modeling

The analysis model describes the structure of the system or application that you are modeling. It
consists of class diagrams and sequence diagrams that describe the logical implementation of the
functional requirements that you identified in the use case model.
The analysis model identifies the main classes in the system and contains a set of use case
realizations that describe how the system will be built. Class diagrams describe the static
structure of the system by using stereotypes to model the functional parts of the system.
Sequence diagrams realize the use cases by describing the flow of events in the use cases when

25
they are executed. These use case realizations model how the parts of the system interact within
the context of a specific use case.

2.6.8. System Use Case Diagram and Documentations

2.6.8.1. System use case diagram

26
 2.6.8.2. System Use case Documentation
2.6.8.3. Use case documentation for login

Use case name Login

Use case number Uc1
Actor Engineer
Description When engineer enters id and password, it checks the input from the database. If
it is valid, it allows the user to access and if not it display unauthorized
message.
Typical course of action: Actors action Systems response
Step1: this use case is initiated Step2: the systems display the login
when the engineer click on the forms.
login option Step4: the systems verifies whether the
Step3: the engineer enter the id engineer is authorized or not. If he/she is
and password authorized systems display the main page
Alternate course of action: Step3: if the engineer does not fill the appropriate id and password then the
systems display error message and return to step 2
Pre-condition The engineer must be authorized for the work
The get into the system
Post-condition

27
 2.6.8.4. Use case documentation for Manage the site supervisor

Use case name

Manage the site supervisor

Use case number Uc2

Actor Engineer
Description The Engineer manages the site supervisor in order to perform the job correctly.
Typical course of action: Actors action
Step1: this use case is initiated when the engineer wants to manage the
supervisor.
Step2: the engineer will check the site supervisor to do or not.
Step3: if the site supervisors do it responsibility the engineer must pay the salary
of the site supervisor.
Step4.if not the engineer must be remove the site supervisor and change the other.
Alternate course of Step3: if the site supervisor do not perform his obligation. Then the site
action: supervisor didn’t get any kind of income from the engineering.
Pre-condition The engineer must be authorized for the work
The site supervisor gets his wants.
Post-condition

2.6.8.5.Use case documentation for monitor schedule

Use case name Monitor schedule

Use case number Uc3
Actor Site supervisor
Description When each site supervisor wants to do with the schedule, the system should allow
using the schedule form.
Typical course of action: Actors action Systems response
Step1: this use case is initiated when the the Step2: the systems display the
supervisor click on the schedule option schedule form.

28
Alternate course of Step1: if the supervisor does not initiated to work with the schedule, the system
action: displays nothing
Pre-condition The supervisor must be authorized for the work
The get into the system
Post-condition

2.6.8.6. Use case documentation for assure quality

Use case name Assure quality

Use case number Uc4

Actor Site supervisor
Description When each site supervisor wants to do with the quality assurance, the system
should allow using the schedule form.
Typical course of action: Actors action Systems response
Step1: this use case is initiated when the the Step2: the systems display the
supervisor click on the quality assurance quality assurance form.
option
Alternate course of Step1: if the supervisor does not initiated to work with quality assurance, the
action: system displays nothing
Pre-condition The supervisor must be authorized for the work
The get into the system
Post-condition

29
 2.6.9. Sequence Diagram

A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram

that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality of the scenario.
Sequence diagrams typically (but not always), are associated with use case realizations in the
Logical View of the system under development. A sequence diagram shows, as parallel vertical
lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows,
the messages exchanged between them, in the order in which they occur. This allows the
specification of simple runtime scenarios in a graphical manner. [4]

30
31
Sequence diagram for monitor schedule

32
33
34
35
36
37
 2.6.10. Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. Activity diagrams can be used to describe the
business and operational step-by-step workflows of components in a system. An activity diagram
shows the overall flow of control. Activity diagrams are constructed from a limited number of
shapes, connected with arrows.

38
39
40
41
User Interface Prototypes

42
 2.6.11. Conceptual Class Diagram

The conceptual class diagram or Domain Model is the simplest form of class diagram. It shows
the classes, their associations, and attributes. It does not show methods or interface classes. [1]

Figure 4.10. Conceptual Class Diagram

43
 2.6.12. Class Diagram

The class diagram is the main building block of object oriented modeling. It is used both for
general conceptual modeling of the systematic of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data
modeling. The classes in a class diagram represent both the main objects, interactions in the
application and the classes to be programmed. [3]

44
45
 Chapter Three
Design Phase
3. Introduction

During the Design Phase, the system is designed to satisfy the requirements identified in the
previous phases. The requirements identified in the Requirements Analysis Phase are
transformed into a System Design Document that accurately describes the design of the system
and that can be used as an input to system development in the next phase.

3.1. Design Goals

The design goals stated for the system defines the qualities that the system should incorporate.
Most of these design goals are the refinements of the non-functional requirements identified
during requirement elicitation, and some of the design goals may not stated explicitly in the
requirements specification. However, if the system is to be efficient, these design goals need to
be incorporated.
The system should be secured: as the system is an insurance system the security requirement is
a critical issue. So that the system should prevent unauthorized access to the data stored in the
database, and in addition the system should maintain data about what activities are performed by
whom and when.
The system should be easy to use: the user of the system can be any authorized employee in the
section. So, that the system should be usable, whether or not the employee has know-how on
how to perform tasks using computers. For that the system should provide help at every moment
the employee is in need of help.
Ease of access to the required data: any data can be required at any time for some purpose, i.e.
modify or view. So that the system should enable the user acquire the required data easily and
timely with no need of navigating too many files.
Development cost: cost of development the system should be minimized as much as possible in
a manner that it doesn’t affect the functional as well as the non-functional requirements of the
system.

46
 3.2. User interface identification

The user interface of software is the portion the user directly interacts with, including the
screens, reports, documentation, and software support.
The following are user interfaces for Construction Management System
No User Interface ID User interface Name
1 UI-01 Main Menu UI
2 UI-02 System Login UI

3 UI-03 Current project status UI

4 UI-04 Register user UI

5 UI-05 Add new project UI

6 UI-06 Scheduling UI
7 UI-07 Generate report UI
8 UI-08 Construction Materials Status UI

3.3. User interface design

User interface designs are used to model the interactions that users have with software defined in
single use case. User interface are an excellent way of exploring system interface. They help to
model the high level relationships between major user interface elements. User interface mainly
helps to facilitate the interaction between user and the system.

3.4. Design Class Diagram

The class diagram is the main building block of object oriented modeling. It is used both for
general conceptual modeling of the systematic of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data
modeling. The classes in a class diagram represent both the main objects, interactions in the
application and the classes to be programmed.

47
 3.5. State Chart Diagram

In this part the team used to model the behaviors of the objects by drawing the state diagram.
That shows the sequence of states that an object goes through, the events that cause the transition
from one state to the other and the actions that result from a state change. The following figures
show the state of the objects of the corresponding use cases.

Figure 5.5. State chart diagram

48
 3.6. Persistent Modeling / Database Design

Figure 5.6. Persistent modeling/database design

3.6.1. Entity relationship diagram

An entity-relationship model (ER model for short) is an abstract and conceptual representation of
data. Entity-relationship modeling is a database modeling method, used to produce a type of
conceptual schema or semantic data model of a system, often a relational database. Diagrams
created by this process are called entity-relationship diagrams or ER diagram.

49
Figure 5.6.1. Entity Relationship Diagram/ERD

50
 3.7. Normalization

Normalization is the process of removing redundant data from your tables in order to improve
storage efficiency, data integrity and scalability. This improvement is balanced against an
increase in complexity and potential performance losses from the joining of the normalized
tables at query-time. There are two goals of the normalization process: eliminating redundant
data (for example, storing the same data in more than one table) and ensuring data dependencies
make sense (only storing related data in a table). Both of these are worthy goals as they reduce
the amount of space a database consumes and ensure that data is logically stored. [6] [9]
First Normal Form:
Tables are said to be in first normal form when:
 The table has a primary key
 No single attribute (column) has multiple values
 The non-key attributes (columns) depend on the primary key
Second Normal Form:
Tables are said to be in second normal form when:
 The tables meet the criteria for first normal form.
 If the primary key is a composite of attributes (contains multiple columns), the non key
attributes (columns) must depend on the whole key.
Note: Any table with a primary key that is composed of a single attribute (column) is
automatically in second normal form.
Third Normal Form:
Tables are said to be in third normal form when:
 The tables meet the criteria for second normal form.
 Each non-key attribute in a row does not depend on the entry in another key column.

51
52
53
 3.8. Deployment Diagram

A UML deployment diagram depicts static view of the run time configuration of processing
nodes and the components that run on those nodes. In other words, deployment diagram shows
the hardware of your system, the software that is installed in that hardware, and the middleware
used to connect the disparate machines to one another. It also shows how hard ware and software
components work together [2]
Figure 5.8. Deployment Diagram

54
 3.9. Component Modeling

Component diagrams show how the physical components of a system are organized. And also
shows which component or objects will be accessed by whom and what type of security
infrastructures it is using. It is a UML diagram that depicts the software components that
comprise an application, system or enterprise. The components, their interrelationships,
interactions and their public interfaces are depicted. [2]

Figure 5.9. Component Modeling

55
 References

[1]. Systems Analysis II, Domain Modeling, INFO 355 Glenn Booker

[2]. Scott W. Ambler (2001), The Application Developer’s Guide to Object Orientation and the

UML.

[3]. Lab Manual CPIT 250 System analysis and Design 1

[4]. http://en.wikipedia.org/wiki/Sequence_diagram

[5]. http://www.smartdraw.com/resources/tutorials/uml-collaboration-diagrams/

56
[6]. Dinesh Thakur, http://ecomputernotes.com/fundamental/what-is-a-database/what-is-a-

database-normalization

[7]. http://en.wikipedia.org/wiki/Business_rule

[8]. http://ict.mcast.edu.mt/moodle/.../A_Class_Responsibility_Collaborator.doc

[9]. http://edn.embarcadero.com/article/25209

57
 Appendix

Interview

1. How construction management system is going on?

The Current construction management process in Haramaya University has many sites in the
main campus and other branch campuses. The engineering unit office found in Haramaya
University is responsible to control all the construction sites.

2. During construction time, is there any problem? If there, what are they?

The main problem during construction process is the lack of good time monitoring. This affects
the cost and scope of the project.

3. What requirements are needed for the process?

The requirements required for the construction processes are; the availability contractor when the
consultant want, and the availability of enough man power and material resources.

4. Who is responsible for what?

The main actors in the construction process are employer (VP for Administration and Student
Affairs), consultant, engineer, site supervisor, contractor and employee. The employer is primary
actor to initiate (begin) the project. The consultant is the mediator between the employer and the
contractor. The duty of the contractor is facilitating the construction process by providing the
required human and material resources. The responsibility of engineer is designing the project
and provides some calculations that are required during the construction. The responsibility of
the site supervisor is supervising the ongoing project processes.

58