A FRAMEWORK FOR DESIGN INFORMATION MANAGEMENT SYSTEM
FOR ARCHITECTS
ALIYU MUHAMMAD ALHASSAN
UNIVERSITI TEKNOLOGI MALAYSIA
A FRAMEWORK FOR DESIGN INFORMATION MANAGEMENT SYSTEM
FOR ARCHITECTS
ALIYU MUHAMMAD ALHASSAN
A project report submitted in partial fulfilment of the
requirements for the award of the degree of
Master of Science (Information Technology- Management)
Faculty of Computer Science and Information Systems
Universiti Teknologi Malaysia
MARCH 2010
iii
To my beloved family and friends
To my respected supervisor
iv
ACKNOWLEDGEMENTS
First of all, I will like to be thankful to Almighty Allah, the creator, and
protector of mankind for giving us the strenght to accomplish this work.
I acknowledge and deeply appreciate the worthwhile and limitless efforts of
my diligent and able supervisors, Dr. M.I. Jambak and PM. Dr. Naomie Bte Salim to
the successful accomplishment of this project work.
I also acknowledge the limitless effort of the head of department, Dr. Mohd
Zaidi Abd Rozan.
I wish to acknowledge and deeply appreciate the motherly
guidance accorded to me by PM. Wardah Zainal Abidin throughout this period. I
also appreciate the contributions of the coordinator IT management, Dr. Razak Che
Hussain, Professor Dr. Ahmad Zaki, PM. Dr. Azizah Abd. Rahaman, PM. Dr. Ali
Selamat, Professor Dr. Bob Colomb, PM. Dr. Harihodin Selamat and all the dynamic
and dilligent lecturers in my department that have all imparted some knowledge onto
me at one time or the other, worthy of thanks. I wish to also acknowledge the efforts
of Dr. Khairul Anwar and other lecturers of the department of Architecture of FAB
that gave their input in carrying out this research, worthy of thanks.
My appreciation goes to my parents for their contributions and support in all
areas of life.
Finally, my profound gratitude and appreciation goes to all my friends, course
mates and school mates, and who so ever help me in one way or the other to ensure
the success of this work. I thank you all, and it is my wish that God will reward and
bless you.
v
ABSTRACT
Architectural design solutions are outcomes of information manipulations by
designers. An activity in the architectural design process may require inputs from
other phases. The architect must be able to keep track of the amount of information
required to accomplish a design task, which is a difficult task to perform. A design
information management system is required to assist designers with new ways of
managing and handling design projects. Despite the difficulty of managing the
information flows and the availability of tools and techniques that can assist in
manipulating the flow, there is still a lack of research to better understand and
manage these flows. Architectural design is characterised by rework (iteration).
Many of the available process models are not capable of representing these iterative
processes. The models that are capable of identifying iterations do not provide
means for managing them. In this work, we review existing information system
framework, information modelling tools and techniques, and propose an information
system framework termed ADIMS based on web services to manage architectural
design information. The work also addresses the problem of architectural design
information management from the information flow perspective by introducing the
design structure matrix as a modelling tool to aid in a better understanding and
management of the flow of information within the RIBA work stages.
vi
ABSTRAK
Penyelesaian rekaan senibina merupakan hasil manipulasi maklumat oleh
para pereka. Sesebuah aktiviti dalam proses rekaan senibina memerlukan input dari
pelbagai fasa lain. Arkitek mestilah mampu menjejaki pelbagai maklumat yang
diperlukan untuk menyiapkan sesebuah tugasan rekaan, yang mana merupakan tugas
yang sukar untuk dilakukan. Suatu sistem pengurusan maklumat rekaan diperlukan
untuk membantu para pereka dengan cara-cara baru dalam mengendalikan dan
menyelesaikan
projek-projek
rekaan.
Walaupun
terdapat
masalah
dalam
menguruskan susunan maklumat serta kesediaan alatan dan teknik yang boleh
membantu dalam memanipulasikan pengalirannya, masih terdapat kekurangan dalam
penyelidikan untuk memahami dengan lebih baik lagi tentang pengaliran maklumat
ini. Rekaan senibina bercirikan iterasi. Kebanyakan model proses yang sedia ada
tidak berupaya untuk mewakili proses-proses iterasi ini. Model-model yang mampu
mengenalpasti iterasi tidak mampu menyediakan cara untuk menguruskannya.
Dalam projek ini, kita akan meneliti rangka kerja sistem maklumat yang sedia ada,
peralatan pemodelan maklumat dan tekniknya, serta mencadangkan sebuah rangka
kerja sistem maklumat yang berterma ADIMS yang berasaskan servis-servis web
untuk mengurus maklumat rekaan senibina. Projek ini juga menerangkan masalah
pengurusan maklumat rekaan arkitektual dari perspektif pengaliran maklumat dengan
memperkenalkan struktur rekaan matriks sebagai sebuah peralatan pemodelan untuk
membantu dalam pemahaman dan pengurusan pengaliran maklumat dalam
lingkungan kerja RIBA.
vii
TABLE OF CONTENTS
CHAPTER TITLE
PAGE
DECLARATION
ii
DEDICATION
iii
ACKNOWLEDGEMENT
iv
ABSTRACT
v
ABSTRAK
vi
TABLE OF CONTENTS
vii
LIST OF TABLES
xii
LIST OF FIGURES
xiii
LIST OF ABBREVIATIONS
xvi
LIST OF APPENDICES
xvii
1 PROJECT OVERVIEW
1.1
Introduction
1
1.2
Background of Problem
3
1.3
Statement of the Problem
4
1.4
Research Objectives
5
1.5
Scope
5
1.6
Importance of the Research Study
6
1.7
Chapter Summary
6
viii
2 LITERATURE REVIEW
2.1
Introduction
7
2.2
Information Management
9
2.2.1
Information Management System
11
2.2.2
Information Modelling
11
2.2.3
Information System Models
12
2.2.4
Information System Framework
15
2.3
Concept of Design
17
2.3.1
Architectural Design
17
2.3.2
Architect
18
2.3.3
Architect and the Building Design
19
2.3.4
Architectural Design Process
21
2.3.5
Architectural Design Information Sources
24
2.3.6
Architectural Design Information Search and
25
Storage
2.4
2.5
Information Management in Architectural Design
27
2.4.1 Design Process Modeling
28
2.4.2 Design Process Modeling Tools
28
2.4.3 Architectural Design Information Repository
33
Problems and Weaknesses in Managing Architectural Design
34
Information
2.6
Architectural Design Information Requirements Determination
2.6.1
Activity Theory Background
35
37
2.7
Discussion
38
2.8
Chapter Summary
39
3 RESEARCH METHODOLOGY
3.1
Introduction
40
3.2
Research Design
41
3.3
Project Methodology
41
3.3.1
Phase 1: Initial Planning
44
3.3.2
Phase 2: Analysis
44
3.3.2.1 Literature Review Analysis
44
ix
3.3.2.2 Data Collection
45
3.3.2.3 Collected Data Analysis
50
Phase 3: Modeling
52
3.3.3.1 Design Framework
52
3.3.3.2 System Development Methodology
53
3.3.3.3 Methodology Justification
53
Phase 4: Evaluate the Framework
54
3.3.4.1 Apply and Evaluate the Framework
54
3.3.4.2 Report Writing
54
3.3.3
3.3.4
3.4
Project Schedule
55
3.5
Software and Hardware Requirements
55
3.6
Chapter Summary
58
4 DATA COLLECTION AND DATA ANALYSIS
4.1
Introduction
59
4.2
Organizational Analysis
60
4.2.1
Introduction to Faculty of Built Environment (FAB)
60
4.2.1.1
FAB’ objectives
61
4.2.1.2
Mission and Vision
61
4.2.1.3
FAB Organizational Structure
61
4.2.2
4.3
4.4
62
Data Collection
64
43.1
Observation and Discussion
64
4.3.2
Design Structure Matrix
65
Observation, Discussion, and Matrix Design
4.4.1
4.4.2
4.5
Royal Institute of British Architects
Observation and Discussion Summary
Design Matrix Summary
Architectural Design Information System Requirement Capture
66
66
67
72
4.5.1 Applying the Concept of Activity Theory to Architectural 73
Design
4.6
Chapter Summary
80
x
5 FRAMEWORK OF ARCHITECTURAL DESIGN INFORMATION
MANAGEMENT SYSTEM
5.1
Introduction
81
5.2
Matrix Representation of Architectural Design Phases
82
5.3
Design Process Analysis: Partitioning
84
5.4
5.3.1
Identifying Loops by Powers of Adjacency Matrix
85
5.3.2
Ordering of Tasks within the Blocks (Tearing)
88
Proposed framework for Architectural Design Information 92
Management System (ADIMS)
5.5
System Overview
92
5.6
User Registration and Login Validation
95
5.7
Information Model Design
98
5.8
Chapter Summary
100
6 THE ARCHITECTURAL DESIGN INFORMATION MANAGEMENT
SYSTEM
6.1
Introduction
102
6.2
User Specification
103
6.3
Prototype and Interface Requirement Specification
103
6.4
Architectural Design Information Management System
104
6.5
Web Presentation
107
6.5.1
The Architect Module
107
6.5.2
The Client Module
115
6.5.3
The Admin Module
118
6.5.4
Search Module
120
6.6 Data Management Service Logic
121
6.7 Information Repository
122
6.8 Software Quality and Testing
123
6.9
6.8.1
User Interface Testing
124
6.8.2
User – Case Testing
128
6.8.3
Documentation Testing
132
Chapter Summary
133
xi
7 DISCUSSION AND CONCLUSION
7.1
Introduction
134
7.2
Achievements
134
3.3
Constrains, Challenges and Limitations
136
7.4
Aspiration
137
7.5
Chapter Summary
137
REFERENCES
Appendices A - F
138
142- 167
xii
LIST OF TABLES
TABLE NO.
TITLE
PAGE
2.1
Definitions of Data, Information and Knowledge
9
2.2
The Set of Architectural Representations prepared over
21
the process of building a Building
3.1
The RIBA Outline Plan of Work
23
Data, Source, Method of Collection, and
50
Person/Organization Involved
3.2
Software Requirements
56
4.1
Description of Actions
79
5.1
Partitioning Algorithm
85
5.2
Tearing Algorithm
88
5.3
Nodes with their Row and Column Entries
89
6.1
Screen Layout Testing
125
6.2
Report Layout Testing
126
6.3
Form Layout Testing
127
6.4
Menu Testing
128
6.5
Use-case testing for Architect Page
129
xiii
LIST OF FIGURES
FIGURE NO
TITLE
PAGE
2.1
Literature Review Framework
8
2.2
Physical Architecture of an Information System
14
2.3
Distributed Information system architecture
16
2.4
Information Search Process
27
2.5
Directed Graph
29
2.6
PERT Chart
30
2.7
SADT Technique
31
2.8
Design Structure Matrix
32
2.9
Screen shot of the Interface in Browser mode
34
2.10
Basic Structure of an Activity
37
2.11
The three levels of Activity
38
3.1
Project Operational Framework
43
4.1
Input of Architect with 20 Years Experience
68
4.2
Input of Architect with 4 Years Experience
70
4.3
Input of Unregistered Professional with 6 Years
71
Experience
4.4
Activity System for Architectural Design Information
75
Management System
4.5
The Hierarchical Decomposition of Activities into
Actions
78
xiv
5.1
The Flow of Information in Architectural Design Stages
83
5.2
The Design Structure Matrix with non-zero entries
86
replaced with 1’s
5.3
The Square of Adjacency Matrix
87
5.4
The Cube of Adjacency Matrix
87
5.5
Tear Suggested by the Matrix
90
5.6
System Overview
93
5.7
Architect, Client, and Admin Activity Management
95
5.8
Architect Registration and Login Validation
96
5.9
Client Registration and Login Validation
97
5.10
System Admin Login Validation
98
5.11
Information Model
100
6.1
Model of Architectural Design Information Management
106
System (ADIMS)
6.2
The Architect Account
108
6.3
The Architect File Upload Page
109
6.4
List of Files Uploaded the Architect
109
6.5
Design Document Search
110
6.6
Architects Document Search Results
111
6.7
Architects Client Search Results
111
6.8
View Client Specification/Make Offer Page
112
6.9
Change Password Page
113
6.10
URL Subcategories Page
114
6.11
View URLs Page
114
6.12
Add Category, Subcategory, and URL Page
115
6.13
Make Appointment Page
116
6.14
Select Offer and Confirm Appointment Page
117
6.15
View Design Description Page
117
6.16
Admin Account
119
6.17
View System Users Page
119
6.18
Add New Design Description Page
120
6.19
Advanced Search
121
6.20
Database Implementation of ADIMS
123
xv
6.21
System Interface
125
xvi
LIST OF ABBREVIATION
ADIMS
Architectural Design Information Management Systems
AI
Artificial intelligence
BI
Business intelligence
CM
Content Management
DAM
Digital Asset Management
DBMS
Database Management Systems
DM
Document Management
DSS
Decision Support System
ES
Expert Systems
FAB
Faculti Alam Bina
HTML
Hypertext Markup Language
HTTP
Hypertext Transport Protocol
IMS
Information Management Systems
I/O
Input/output
LCM
Learning Content Management
LM
Learning Management
MIS
Management Information Systems
RIBA
Royal Institute of British Architects
RM
Record Management
TPS
Transaction Processing Systems
UML
Unified Modelling Language
UTM
Universiti Technologi Malaysia
xvii
LIST OF APPENDICES
APPENDIX
TITLE
PAGE
A
Gantt Chart
142
B
Design Structure Matrix
149
C
RIBA Outline Plan of Work 2007
153
D
Use-Case for Adims
155
E
FAB Organizational Chart
164
F
MATLAB Printout
166
CHAPTER 1
PROJECT OVERVIEW
1.1
Introduction
Information management can be considered as a cycle of processes which
support the organization learning activities. The activities are; information needs
identification, information acquisition, organizing and storage of information,
developing information products and services, distributing information, and
information usage (Woo, 1995). It is an umbrella term that encompasses (Woo,
1995) all the systems and process within an organization for the creation and use of
corporate information (Woo, 1995).
Architects as designers need information from a very broad source, in order
to come up with a solution to such design problem. Traditionally, this information
could come from books, other documents, colleagues and experts (Jambak et al.,
2005). Usually, when designers obtain this information they will keep it in their
mind, or in their very own repository. Therefore, it is difficult for other designers to
obtain the same information in case they have to solve similar design problems. This
2
situation may lead to a risk of wrong decision and overlooked concepts (Jambak et
al., 2005).
Architectural designs as well as other designs are characterised by its ill
defined problem, therefore the methods of obtaining those solutions are also poorly
defined (Ozakaya and Akin, 2006). To be able to come up with a solution, designer
needs to discover the real problem. Though, the solution still cannot be completely
validated (Ozakaya and Akin, 2006). The designer should therefore decide when a
problem is sufficiently described.
Knowledge and information are critical to
effective design and product development. As such solving and specifying design
problems go hand in hand.
According Ozakaya and Akin (2006), information
consistency and updating leads to significant overheads in design.
Designers need design information management systems in order to find new
ideas and to solve their design problems. As such, the result of a design project
depends largely on the expertise and information a designer have before he starts to
search and retrieve information. Determining the information required by designers
to do their design task and to help them update their knowledge towards problem
solving is one of the most difficult aspects of deriving information management plan
in a creative environment.
The amount of data, information and knowledge to be handled by the
designers is often too broad, and unmanageable. Despite the availability of sources
surrounding designers, getting access to the correct and required information for a
particular design is often very handy, and a very uneasy task to perform. This
problem results from both the ambiguity between sequence, keywords, relationship,
connections and also due to the types and size of data and information from other
sources. As such, many designs are being generated without the benefit of existing
information in the design environment.
This work is aimed at developing an
information system framework that will assist architects with ways of managing
design information.
3
1.2
Background of the Problem
The increasing complexity of buildings (Pektas and Pultar, 2005),
competitive global markets, and rapid advances in technology (Wu et al., 2004), have
been forcing design professionals to improve their process in terms of time and
quality (Pektas and Pultar, 2005). One major obstacle affecting architectural design
is the lack of systematic design planning in many building projects (Formoso et al.,
1998). The planning is at times performed in an intuitive manner based on discipline
specific programs (Pektas and Pultar, 2005). This is due to the fact that, a limited
effort is made in identifying and managing the flow of information in the
architectural design process.
Different researchers assisted designers in a number of ways. Some used the
design structure matrix to restructure complex design projects in order to develop
better products (Eppinger et al., 1994). Others (Pektas and Pultar, 2005), introduces
the use of parameter analysis tool for building design with an aim of revealing the
process structure, optimum sequence of parameter decisions, iterative cycles and
concurrency in the process. Wu et al., 2004, proposes an information framework by
integrating web services and agent technologies to manage collaborative product
development process. Szykman, 2002, developed a design repository software
system in order to address terminological and semantic issues associated with
computer aided product development.
There are different types of information in the architectural design phases.
This information can be in the form of audio (communication between the architect
and the client), in the form of sketch (bubble chart), architects drawings, contract
documents, etc. The information from earlier phases provides inputs to later phases.
As such there is a need to assist the architects with ways of managing this
architectural design information so that they can retrieve and used it as at when
needed.
4
This study proposes an information system framework to assist architects to
manage design information.
The work also proposes a model of the flow of
information within the architectural design process by introducing the design
structure matrix as a modelling tool for understanding and manipulating the
information flow.
1.3
Statement of the Problem
Information is essential to the success of such design work.
However,
designers in any activity have their own way of finding/collecting information during
the design process. It is a need to support designers to collect information while not
restricting their design activity. In order to develop such a system (information
system) that nature to designers or architects, an information framework that can
guide the system developer is needed.
The research questions that this project focuses on are;
1. How to model the ways architects collect information to solve their
design task?
2. What is the suitable framework for a design information management
system for architects?
5
1.4
Research Objectives
The objectives that pave the way for the project are:
1. Collecting requirements and understanding the flow of information in
architectural design process.
2. To develop a framework for design information system for architects
based on the collected requirements.
3. To develop a simple prototype as a proof of concept for the
framework.
1.5
Scope
The scopes which identify the boundaries of the project are;
i)
Only architectural design will be considered.
ii)
Only looking at the way architects follow the architectural design
process/phases.
iii)
Only the information flow within the design process will be
considered.
iv)
Only the deliverables of the early phases of design will be considered
in developing the information system framework.
6
1.6
Importance of the Research Study
The knowledge of the ways that designers collect information to develop the
building design, the source of the information, and the format of the information and
how the query is done will assist in modeling the information seeking processes. The
model will thus assist in developing a framework for the design information
management system for architects. Some benefits of the framework are:
1. Easy way to design and modify an information management system for
Architects.
2. Simplifying the information seeking process for solving design problems.
3. Assist designers with a more effective way to re-use design knowledge and
information.
1.7
Chapter summary
As a summary, this chapter provides a general introduction and overview of
the project including the problem background.
Problem statements, project
objectives and the scope of the project have been clearly stated. The goal of this
project is to develop a framework for design information management system for
architects.
CHAPTER 2
LITERATURE REVIEW
2.1 Introduction
This chapter covers the areas that are of interests to the study. The main
essentials such as information management, information management systems,
concept of design (architectural design, architecture, architects, architects and the
building design), information system models, infomation system framework,
architectural design process, architectural design information sources, architectural
design information search and storage, information management in architectural
design, the problems in managing architectural design information, and the concept
of activity theory are analyzed and discussed.
This is obtained from literature review, from sources like books, journals,
conferences, research reports, thesis, the internet to mention but a few. The literature
review framework is shown in Figure 2.1.
8
Figure 2.1: Literature Review Framework
9
2.2
Information Management
Explaining information management requires an understanding of the term
information.
Again, we cannot explain information without having an in dept
understanding of the meaning of data and knowledge. Briefly, we shall explain the
meaning of data, information and knowledge.
According to Stenmark (2002), Knowledge and information affect one
another. He also argues that all knowledge is tacit, and what can be articulated and
made tangible outside the human mind is merely information. The definitions of
data, information, and knowledge are presented in the table 2.1.
Table 2.1: Definitions of Data, Information and Knowledge (adapted from
Stenmark, 2002)
Author(s)
Data
Information
Knowledge
Nonaka and
Takenchi
-
A flow of meaningful
messages
Commitments and
beliefs created from
these messages
Spek and
Spijkervet
Not yet
interpreted
symbols
Data with meaning
The ability to assign
meaning
Davenport
Simple
observations
Data with relevance
and purpose
Valuable information
from the human mind
Davenport
and Prusak
A set of discrete
facts
A message meant to
change the receiver’s
perception
Experiences, values,
insights, and contextual
information
Choo et al
Facts and
messages
Data vested with
meaning
Justified, true beliefs
10
Having understand the meaning of data, information and knowledge; we shall
now explain the term information management. Information management can be
considered as a cycle of processes which support the organization learning activities.
The activities are; information needs identification, information acquisition,
organizing and storage of information, developing information products and services,
distributing information, and information usage (Woo, 1995).
According to Robertson (2005), in terms of technology, information
management encompasses systems such as; web content management (CM),
document management (DM), records management (RM), digital asset management
(DAM), learning management system (LM), learning content management systems
(LCM), collaboration, enterprise search (Robertson, 2005) and more. This implies
that, information management is more than just technology. Equally importantly, it
is about the business processes and practices that underpin the creation and use of
information (Robertson, 2005).
Information management is also about the information architecture, its
content, metadata and more. To James Robertson (2005), information management
encompasses; people, process, technology, and content.
The basic goal of
information management is to harness the information resources and information
capabilities in order to assist the organization in learning and adapting to changes in
the environment (Choo et al., 1995).
Based on understanding of the technologies involved and the theories behind
(Robertson, 2005) information management, it is right to say that, information
management is no longer a simple job that could be performed (Robertson, 2005) by
almost anyone.
Simply, information management entails organizing, retrieving,
acquiring and maintaining information (Robertson, 2005) which is closely related to
an overlapping with the practice of data management. Managing information at times
may involve the use of information system. The next section explains the term
information management system.
11
2.2.1 Information Management System
The term Information management system (IMS) has no widely accepted
definition. As such, it can be applied to any system of software that facilitates the
storage, organization, and retrieval of information within a computer system, without
the implication that it needed to have all the essential characteristics of a DBMS.
The data are arranged such that their integrity is ensured; the storage and
retrieval processes are optimized. IMS control input and output processing. It
provides formatting, logging, and recovery of messages, maintains communications
security, and oversees the scheduling and execution of programs (Data Center
Definitions, 2007). The information held in an information management system may
include sound fragments, images, and video sequences in addition to the usual
textual and numerical information.
An information model will aid in better
representation of information in an information management system. The next sub
section will explain the meaning of an information model as it relates to an
information management system.
2.2.2 Information Modeling
An information model concerns part of an organization and its environment,
representing the elements about which information is to be recorded and the way in
which the information is to be processed (Flyn et al., 1999). Within the field of
software engineering and data modelling (Flyn et al., 1999), an information model
can be abstract, formal representations of entity types which include properties,
relationships and the operations that can be performed on them (Flyn et al., 1999).
These entities are typically used to model a constrained domain that can be described
12
by a closed set of entity types, properties, relationships and operations (Flyn et al.,
1999).
The model provides formalism to the description of a problem domain
without constraining how that description is mapped (Flyn et al., 1999). to an actual
implementation in software.
There may be many mappings of the information
model. The mappings are called data models, irrespective of whether they are object
models (UML), entity relationship models (Flyn et al., 1999).
Besides UML notations, there are other tools that can be used for modelling
information but are not limited to directed graph which involves the use of a
graphical mapping to represent the entire activity as a system of interconnected
nodes, program evaluation review technique (PERT) chart. Using PERT chart, the
time required to reach a node can be calculated the critical path and to predict
expected completion date (Wiest and Levy, 1997). Other tools which are also used
to model the flow of information are the structured Analysis Technique (SADT),
used for documenting design procedures (Marca and McGowan, 1988), and design
structure matrix (DSM) which uses the structure of information flow to guide the
decomposition of design activity (Gebala and Eppinger, 1981). Researchers from the
field of engineering, mathematics, management, to mention but few used these tools
to model the flow of information and sometimes for decision making.
2.2.3 Information System Models
Toledano identified three actors and three functions to be achieve by an
information system. He defined an actor as an external element to the system that
interacts with it, being this actor a person, either a computer program. The actors are
13
differentiated based on the kind of access to the information system. These actors
are; Information producers, information consumers, and system managers.
The three basic functions to be achieved by an information system identified
by Toledano are:

Integrating the information to the system. Information producers provide the
data to be integrated into the system. The information integration can then
lead to an earlier processing of the data.

To distribute information to the users.

The management the system, to enroll and withdraw, and establishing
permissions regarding their activity (Tolendo).
A) Information integration: Information integration means to process the data
that producers generate, and incorporate this information to the data store
(normally, related data stores).
The following activities characterize the
integration of information are adapted from the work of Tolendo:

Accepting the information package.

Verifying the information package.

Verify the structural validity of data that has been sent and to verify
permissions of the producers with respect to the data.

Integrate and transform the information into data stores.

Generating answers concerning those packages process to producers of
such information.
B) Distributing information: Due to the complex nature of information
distribution, Toledano subdivided the distribution of information into
different sub processes:

Admiting information petitions. The system can equip with modules that
represent directly such information to the consumer.
14

Information petitions validity.

Collection of information.

Formatting of information.

Sending information to consumer.
Toledano presented a model of information system. This is shown in the
figure below:
Figure 2.2: Physical Architecture of an Information System (Toledano)
15
2.2.4 Information System Framework
We shall consider the distributed information system framework due to the
information load on the server. Wu et al., (2004) classified distributed information
system into three classes; web services, remote services, and remote repositories (as
shown in Figure 2.4).
Web service based frameworks take advantage of the Web and support
accessing and sharing of information from different locations (Wu et al., 2004). In
web service based framework, the user interface, data management system and
information repository all function on the server side thereby allowing the client to
interact with a simple application program such as a Web browser. The concept of
web services was used in the development of different applications. (Xu, and Liu,
2003) used web service concept to develop Web-Enabled PDM. Kavido (Tamine
and Dillmann, 2003) applied Web services to record and monitor the product
development process.
Furthermore, WebBlow (Wanga et al., 2003) addresses the integration of
product development control components on the server side with the aid of agent
technology. E2open (E2open Software) applied the concept of Web services based
framework to simplify business process publication, consumption and discovery
among trading partners to facilitate a many-to-many integration among multiple
distributed companies. Web services based framework was proposed by Roy and
Kodkani (1999) to share design data among multidisciplinary team members. Web
services was employed by (Agile PLM Platform) to achieve product and engineering
collaboration, provide design collaboration and visualization support, and to enable
visibility and management of product information across global operations.
Remote services are a traditional approach to designing distributed systems
and are based on remote services technologies, such as Java Remote Method
16
Innovation (RMI) and Common Object Request Broker Architecture (CORBA) to
enable the communication among the clients and servers (Wu, et al., 2004). Unlike
Web services, remote services based information frameworks require development
efforts spent on both the client and the server side, the user interface and partial data
management reside in the client, where the server holds a part of the data
management and the information repository (Wu, et al., 2004). This is also shown in
Figure 2.3.
Remote repository frameworks allow for the storage and versioning of
information. In this type of framework, most of the functional modules reside in the
clients, where the server only deals with the storage of part of the common
information (Wu, et al., 2004).
Figure 2.3: Distributed Information System Architecture (Wu, et al., 2004)
17
Web service based frameworks take advantage of the Web and support
accessing and sharing of information from different locations (Wu, et al., 2004). We
shall adapt Web services based frameworks because it concentrates on server side
programming. In web service based framework, the user interface, data management
system and information repository all function on the server side, allowing the client
to interact with a simple application program such as a Web browser.
2.3 Concept of Design
There are different types of design. This includes but not limited to industrial
design, engineering design, architectural design, software design and many others.
Engineering design deals with servicing a system, component or process so as to
meet desired goals. There are a number of processes in engineering design which
includes; problem definition, information gathering, solution generation etc. On the
other hand, industrial design combines applied art and science which results in the
production and marketing of products. Product design is one aspect of industrial
design in which the usability of the mass produced products often times improve the
marketability of the products.
2.3.1 Architectural Design
Every building begins in the mind of a person (Thompson, 1999). This
person may be someone that needed a home to be built for his family, or someone
wishing to build a block of flats to sell for a profit. It may be a trader seeking a shop
18
to dispose off their goods, or an industrialist needing a factory in which to
manufacture product (Thompson, 1999). It may also be a golfer who is anxious to
construct a golf house. The building itself may be required for different purposes
such as; pleasure, income, utilitarian uses and some other reasons. It should also be
understood that the initial impetus almost invariably comes from one person
recognizing and deciding something to do about it. This is called an architect.
Architecture may be considered as a process and a product of planning, design, and
construction, social or aesthetic considerations. It may require material manipulation
and coordination, technology etc.
The term architecture is interpreted in different ways by different people.
According to Thompson (1999), some see it as a combination of understanding of
different architectural styles, possessing artistic sense, and being able to create
building which delight the eye. More so, others view it as possessing skills in
construction technology and applying them to the design of buildings. In truth, it is
both of these things, but to be really successful and efficient architects, as well as
having artistic and technological skills, also need at least working knowledge of
laws, regulations, customs, costs, business, and much more, such as spaces,
circulation patterns, access, and special needs (Thompson, 1999).
2.3.2
Architect
The architect is employed by the client to act as his agent and see that he is
provided with a building which will satisfy his needs (Thompson, 1999). To achieve
his objectives, the architect with the approval of his client needs to make a series of
choices.
Some of the choices are mentioned by Thompson, (1999).
First, the
architects will be concerned that the building will satisfy the functional requirements
of the occupants. Second, he has to decide how to make the building attractive to
19
look at. Third, he will have to choose a suitable structural form, and appropriate
finishes and services, taking care that the completed building will not incorporate any
defect. Fourth, he will make choices related to costs for the future life of the
building. Fifth, the architect will be concerned with many other practical matters,
such as, how to minimize the danger and inconvenience of fire damage, noise
transmission, and thermal loss.
Today, the architect’s role is seen to encompass the earlier mentioned roles.
He is continued to be widely recognized as the leader of the building team, who
perform a dual role of building designer, and he is able to contribute the results of his
specialist training in innovative design and construction designer, within the setting
of a traditional form of contract. This presupposes that the architect posses both
theoretical and creative skills to produce an acceptable design and working drawings,
and practical skills to manage the administration of a functionally satisfactory
building (Thompson, 1999).
2.3.3
Architect and the Building Design
Architectural design solutions are outcomes of information manipulations by
the designers (Ozkaya and Akin, 2006). In order to come up with the building
design, there are a set of deliverables that the architect produces in the process of
constructing the building design. The first architectural deliverable created by the
architect is a form of conceptual representation which depicts the size, shape, spatial
relationships, and basic intent of the final structure. This conceptual deliverable is
known as bubble charts. The bubble chart results from the initial conversations
between the architect and prospective owner (Zachman, 1999).
20
According to Zachman (1999), the architect prepares this bubble chart for
two reasons. First, the prospective owner must express what he or she has in mind
that will serve as a foundation or basis for the architect’s actual design work.
Second, the architect must convince the owner that the owner’s desires are
understood well enough so that the owner will pay for the creative work to follow,
and in effect, initiate the project.
The next deliverables are the architectural
drawings. These drawings depict the final product from the owner’s perceptual
requirements. The drawings may include horizontal sections (flow plans), vertical
sections (cutaways), and pictorial representations depicting the artistic motif of the
final structure (Zachman, 1999).
These drawings are meant to capture what the owner really has in mind. The
owner can either agree or disagree. If he disagrees, then he has to make some
modifications, and if he agrees, it means the design is what he has in mind and he
further agrees to pay the price in order to continue the project. The architect then
produce the next set of deliverables called the architect plans. These are meant to
translate the owner’s requirements/perception into a product. The plans describes
material relationship in the form of drawing as well as the bills of the materials and
are the final deliverables prepared by the architect which becomes the official record
of the finished product. The set of architectural representations prepared over the
process of building a building is shown in table 2.2 below;
21
Table 2.2: The Set of Architectural Representations prepared over the process of
building a Building (adapted from Zachman, 1999)
Representation Nature/Purpose
Bubble Charts
Concepts of building, sizing, shape, and spatial relationships,
architect and owner understanding (mutual)
Project initiation
Architect’s
drawings
The final building design seen on the owners perspective, floor plans,
cutaways, etc and the architect and owner agreement on building
Establish contract
Architect’s
plans
The final architects drawings for the designer owner’s view translated
into a product, and a detailed 16 categories drawings
Basic negotiation with general contractor
Contractor’s
plan
The final building on the builder’s perspective, architect’s plans
constrained by laws of nature and available technology, “How to
build it” description
Directives for construction activities
Shop plans
Subcontractors design of a part/section, detailed stand-alone model,
specification of what is to be constructed
Pattern
Building
2.3.4
Physical building
Architectural Design Process
The architectural design process can be broken into the following phases:
schematic design, design development, presentation and evaluation, detail
development and construction documents, bidding, and administration of the
construction (Gebala and Eppinger, 1991).
22
The conceptual phase is further broken into pre design phase and site analysis
phase. The activities in the pre design phase may include; programming and space
semantics/flow diagrams, whereas, the activities in the site analysis phase may
include site analysis and selection. In summary, significant issues are identified,
initial design decisions are made, and the overall characteristics of the building are
established in the conceptual design phase.
During the design development phase the specific character and intent of the
entire project are described (Campbell and Wells). The activities in this design phase
may include; architectural design, structural design, mechanical design, electrical
design, civil engineering design, landscape design, interior design and materials
design.
The activities in the contract document phase may include; architectural
design, structural design, mechanical design, electrical design, civil engineering
design, landscape design, interior design and materials design (Campbell and well
Wells).
This phase may also involve identification and prioritizing the key
construction materials/appliances and the systems for the project (materials critical
for the full construction of the project).
In the bidding or negotiation phase the architect may monitor the bids and
material review, systems, and finishes so as to ensure that the design objectives are
not compromised. The activities that characterize the contract administration phase
may include; submittal services, observation services, project representation, testing
and inspection administration, and project closeout to mention but few. The detail
stage of architectural design is shown in Table 2.3 below;
23
Table 2.3: The Royal Institute of British Architects (RIBA) Outline Plan of Work
(RIBA, 2007)
Work Stage
I. Inception
Phase
II.
Feasibility
Phase
Work purpose and
Decision(s) to be
reached
Programming and
space
semantics/flow
diagrams, whereas,
the activities in the
site analysis
Activity to be done
People
involved
Terminology
Used
Set up organization for
client briefing.
Considering
requirements, and
appointing an architect.
All client
interests,
Architect.
Briefings
Concepts of
building, sizing,
shape, and spatial
relationships,
architect and
owner
understanding
(mutual), Initiate
Carry out a study of
user requirements, site
conditions, design etc,
so as to reach a decision
Architects,
Quantity
surveyor, and
contractor,
engineers, etc
Furtther brief
development. Carrying
out studie(s) on user
requirements and
technical problems,
designs/ costs,
necessary to reach a
decision
Clients,
architects,
contractors, etc
Complete design brief
developmentfinal
archtects designs,
engineers preliminary
designs, cost plans,
Document submissions
for approvals.
Clients,
architects,
contractors, etc.
project, ensuring
that it is feasible,
functionally,
technically and
financially.
Determining the
general layout
approach, design
and construction in
so as to obtain
approval for the
client on proposals
and report to
accompany it.
Completing the brief
IV. Scheme
Design Phase and deciding on the
particular proposals
(planning,
appearance,
construction method
etc), and costs
approvals.
Briefs are not modified after this point.
To reach a
V. Detail
Design Phase conclusion on final
design matters ie;
specification,
construction &
costing.
III. Outline
Proposals
Phase
Detailed designs of all
Clients,
part building
architects,
components
contractors,
(collaboration of all
Quantity
stakeholders).
surveyors etc
Complete design
costing
Changes to location or size or even cost can results to an abortive work
The preparation of
Final production
Architects,
VI.
production
information
Quantity
Production
inforation, detailed
preparations i.e.
surveyor, and
Information
final decisions for
working drawings and
contractor
Phase
carrying out of
schedule
Sketching of
plans
Conceptual
Drawings
24
VII. Bills of
Quantities
Phase
VIII. Tender
Action Phase
IX. Project
Planning
Phase
work.
The preparation and
collation of detailed
tender l to enable a
tender or tenders to
be obtained for the
project
To identify and
evaluate the
potential contractors
and/or specialists for
the project, and
To appoint a
contractor
Preparation of bills and
tender documentation
Architects,
Quantity
surveyor, and
contractor
Obtaining and
appraising tenders;
submission of
recommendations to the
client
letting the contract of
building, appointing the
contractor, issuing the
information to the
contractor,
Site handover to
contractor
Architects, QS,
engineers,
contractor,
client.
X.
Mobilization
Phase
To handover site to
a contractor
XI.
Construcion
to Practical
Completion
Phase
XII.
Feedback
Phase
To contruct the
building to practical
completion
Final building as seen
by the owner
To make an analysis
of the management
of construction and
to assist the user.
administration of the
building contract after
practical completion,
making final
inspections, assessing
building user during
initial occupation
period, and review of
project performance in
use
Contractors and
sub-contractors
Architects,
engineers,
contractors,
client and
Quantity
surveyors
Architects,
engineers,
contractor, QS,
client and
engineers
Architects,
engineers,
contractor, QS,
client and
engineers
Rediness for
service
Benefits
evaluation
2.3.5 Architectural Design Information Sources
Architects use information to perform design task and end it in a good and
successful product. This information comes from various sources which include;
books, colleagues, experts to mention but a few. In this traditional way of collecting
information, just as (Jambak et al., 2005) observed, informal communication with a
25
nearby colleague or expert is often preferred over a systematic search in literature,
patent database and the like. In the new information world, the internet has become
widely used for design information retrieval. With the internet, designers can collect
information about materials, processes existing products, market data and other
relevant information that they will find useful to solve their design problems.
In order to be effective, architects need the backup of accurate up-to-date
information on design standards, materials, construction techniques, and legislation
for buildings. According to Thompson (2002), the sources of information to which
architects and technologies need to refer include the following: Manufacturer’s and
constructor’s data in products and materials, British standard specifications (BSS),
British standard codes of practice (CP), European standards and euro codes, building
regulations, other acts and regulations, government leaflets and publication, law
reports, contracts, standard forms, and documentation, checklists, etc.
The increasing pervasiveness of the digital media in design tasks has brought
about an increase in the body of information that accompanies the design process
(Ozkaya, and Akin, 2005). Again, according to Ozkaya, and Akin, (2005), computer
based case libraries, visual precedents, digital standards and specification database,
digital building components templates, building models are no longer imaginary
scenarios. The next section explains the architectural design information search and
storage.
2.3.6 Architectural Design Information Search and Storage
There are different approaches that designers may adopt in order to obtain
solution to a particular design problem. It may be in the form of human to human
26
interaction such as a designer to expert discussion, or a human to non human
interaction such human – computer interaction. In the human to human interaction, a
designer to expert discussion, the designer may direct a question to an expert with a
view of finding a solution to a design problem or to even come up with a design
problem based on his understanding of the design issue at hand. This may be as a
result of a brainstorming session between the designer and expert or the design team.
The internet is one common example of a human to non-human interaction
and it serves as a means for designers to retrieve information which will assist them
in solving their design problems. Moreover, it can be taken as an example of a
divergent approach, where an idea possibly comes to the designer’s mind, although
he or she reads a book that did not have a direct link to his or her design project
(Jambak et al., 2005). For the designer to have a precise or convergent idea about the
design problem, he or she has to consult other information resources such as design
handbook, and material properties handbook to mention but a few.
The method of storing design construction information may take various
forms (Thompson, 2002).
Traditionally, manual storage generally by means of
shelves accommodating books, lever arch files, box files and a host of others. The
majority of technical information prepared for such systems is produced to A4 size,
though not everyone is willing to conform to this standard size (Thompson, 2002).
As an alternative to manual information system using A4 pages, computer
information services are now widely used (Thompson, 2002). One other storage
medium is the internet because it truly converts computers into information
appliances. The information search process is shown in Figure 2.4 below;
27
Figure 2.4: Information Search Process (Jambak et al., 2005)
2.4
Information Management in Architectural Design
This section is aimed at understanding the ways information is being
managed in architectural design. Different tools and techniques are employed so as
to effectively manage architectural design information. The following sub section
review the different approach that researchers adapt so as to assist the architects in
managing design information.
28
2.4.1 Design Process Modeling
An activity in the architectural design process may require inputs from other
phases. Thus, the amount of information associated with architectural design activity
is enormous.
In each of these activities, information is used, generated and
transferred to other activities. When performing a design task, architects’ need to
make decisions which are subject to constraints imposed by other decisions. Every
decision is subject to constraints imposed by previous decisions, and in turn
propagates new constraints to other decisions which are to be made at future stages
of the design process (Gebala and Eppinger, 1991). Again, it is not easy to keep
track of all such decisions and their consequences.
One way of handling the design activity is to decompose the activities into
structured sub units. This will make the information flow easy to understand and
track. The benefits of decomposing the design activities are enormous. Through this
decomposition, the design activity can be treated as a collection of smaller task
(Gebala and Eppinger, 1991). It is also easier to; keep track of the information used
and transferred by smaller task. Some of the methods for representing and studying
design problems adopted from the work of Gebala and Eppinger, (1991) are
presented in the sections that follow.
2.4.2 Design Process Modeling Tools
Gebala and Eppinger, (1991) presented several methods for representing and
studying complex design task that involves the decomposition of complex design
tasks into simpler task. The method presented on the work includes the directed
29
graph (diagraph), Program Evaluation Review Technique (PERT), Structured
Analysis and Design Technique (SADT), and the Design Structure Matrix.
Directed graph involves the use of a graphical mapping to represent the entire
design activity as a system of interconnected nodes. Nodes are used for representing
individual sub-tasks, where as the arcs are that links the nodes can be used to
represent the directed information flow. An example of a diagraph is presented in
Figure 2.6. In the figure, a link is drawn from one node into another represents a
required information transfer between the two nodes. In Figure 2.5, Task A requires
information from Task D, but Task D does not require directed input from Task A.
Figure 2.5: Directed Graph (Gebala and Eppinger, 1991)
In the directed graph, the choice of node location is arbitrary which makes it
difficult to discern any structure in the diagraph. Again, the diagraph layout does not
reflect any of the underlying structure of the design problem that it represents.
Though, a diagraph may be very useful in representing information flow when the
30
number of nodes is small, it becomes cluttered and disorderly network of tangled
arcs when the information flow becomes complex.
If the nodes of a diagraph are arranged along a time line, the result is similar
to a program evaluation review technique (PERT) chart. In the PERT chart, the
length of an arc is proportional to the activities direction of the project course. And
the time required to reach each node can be calculated to determine the critical path
and to predict the expected completion date of the project (Gebala and Eppinger,
1991). A simple PERT chart is shown in Figure 2.8.
Start
F
B, D, G
A, C
E
End
Figure 2.6: PERT Chart (adapted from Gebala and Eppinger, 1991)
Despites the capability of the PERT technique in incorporating more
information than the diagraph, it is still not adequate for representing the vast
majority of design procedures where iteration is involved. One other weakness of
the PERT technique is that, project scheduling scheme cannot represent the circular
flow of information that is encountered in design. Just like the diagraph, loops are
also not allowed in the PERT technique instead, the chart is replaced with a single
composite activity that ignores uncertainties associated with the management of
information flow in such loops.
The structured Analysis Technique (SADT) is used for documenting design
procedures. It is a system of interconnected boxes and arrows which is more formal
than the diagraph in terms of depicting input and output.
SADT attempts to
31
overcome the size limitation by restructuring the amount of information which can
be placed on each page of the document. The limitation of the SADT technique is
that, loops remain indistinguishable from simple feed forward transfer of
information. The SADT representation of the above diagraph is presented in Figure
2.7.
Figure 2.7: SADT Technique (Gebala and Eppinger, 1991)
The above mentioned three techniques (diagraph, PERT, and SADT) suffer
from practical limitations and the ability to display circuit explicitly. Because they
are cumbersome, we have found in practice that these methods are used primarily for
documentation of design practices (Gebala and Eppinger, 1991). Another limitation
is that they lack capacity to suggest improvements for effectively managing the
design process.
The Design Structure Matrix (Steward, 1981) overcomes the
limitations of the above mentioned three techniques.
A design structure matrix is a graphical representation that uses the structure
of information flow so as to guide the decomposition of design activity. The matrix
embodies the structure of the underlying design activity by mapping and the relations
32
between the tasks in a precise order which makes interdependence explicit (Gebala
and Eppinger, 1991). Furthermore, the design structure matrix is a square matrix
which maps out the information links among individual design task. It provides a
systematic mapping that can be read easily and with reasonable level of clarity
regardless of the size.
According to Gebala and Eppinger (1991), a design activity is composed of n
task would be represented as an nxn matrix, with task labels placed downside of the
matrix as row headings and across the top as column headings in the same order. For
nodes i and j, the matrix element aij is non zero if node i provides information to
node j. Figure 2.8 below shows the representation of design process from task A to
G.
Figure 2.8: Design Structure Matrix (Gebala and Eppinger, 1991)
The matrix representation has been used to model many different processes
(Gebala and Eppinger, 1991). Engineers used it to model the interdependence of
system parameters to determine the most efficient ordering of design decisions.
Mathematicians have used it to obtain solution of simultaneous equations. The
33
matrix representation has been used as a management and as well as engineering tool
to guide the organizational structure of design projects engineering task (Eppinger et
al., 1991).
The matrix also allows quick identification of tasks which can be
performed in parallel. The next sub section will introduce information systems as
tools used in managing architectural design information.
2.4.3 Architectural Design Information Repository
The above mention tools handle architectural design information in an
information flow perspectives. Researchers like (Szykman, 2002), introduced the
notion of information systems in managing architectural design information. He
developed a design repository software system in order to address terminological and
semantic issues associated with computer aided product development.
The
repository system has various users interface which serves as links between the users
of the system. The interface is also designed to accept request from the user and
deliver the results with the aid of dynamic web pages.
The repository system also uses a browser which provides an interface that
allows users to navigate the information stored in the database. A design repository
editor allows the user to create product models by authoring new design repository
information. It also provides the user with the capability of modifying existing
information in the repository. Below is a snapshot of the interface of the repository
system.
34
Figure 2.9: Screen Shot of the Interface in Browser Mode (Szykman, 2002)
2.5
Problems
and
Weaknesses
in
Managing
Architectural
Design
Information
There are quite a large number of problems in the management of
information in architectural design. One of the problems is the lack of planning in
many building projects (Pektas and Pultar, 2005).
The lack of planning in
architectural design is as a result of the fragmentation of architecture, engineering
and construction industries. Architectural design teams consist of smaller groups of
design professionals, and it may consist of different members per design task. The
cost of the design planning is not often included in the architect’s fee (Pektas and
Pultar, 2005).
35
Secondly, architectural design (building design to be precise) is characterized
by rework (iteration). Many of the available process models are not capable of
representing these iterative processes.
Again, the models that are capable of
identifying iterations do not provide means for managing them (Pektas and Pultar,
2005).
Thirdly, architectural design problems are ill structured, because the
information that the architect have initially may be insufficient. Despite the efforts
made by many researchers, there is still no satisfactory algorithm to handle this
problem. As such, design problem solving, solutions are almost never predictable
(Goldschmidt, 1997).
Fourthly, the storage and retrieval of architectural design information may be
considered a problem.
It is often a very uneasy task for architects to retrieve
information either from previous design or from the internet when solving a design
task. Because architects employ different ways of storing design information, they
are still faced with the problem of retrieving such information for use as at when
needed. Information stored traditionally in shelves, lever arch files, box files, and so
on may not be easy to retrieve especially if the information becomes very big.
2.6 Architectural Design Information Requirements Determination
The information system requirement technique to be discussed here is the
concept of activity theory.
36
2.6.1 Activity Theory Background
Activity theory concepts evolved through three research generations. The
first generation focuses on the conception of mediation.
One limitation of the first
generation was that the unit of analysis focussed individually.
generation, (Leont’ev’s, 1978), overcomes the limitation.
The second
The third generation
considered a joint activity or practice for the analysis of an activity (Uden et al.,
2008).
The concept of activity theory focuses on human activity interaction and it’s
consciousness with the environmental context (Leont'ev, 1981). These activities are
driven by certain needs, with people wishing to achieve certain purposes. In the
concept of an activity, an individual or subject acts as an agent (Uden et al., 2008).
Furtther more, a subject untake an activity with the aid of tools to achieve
objective(s) there transforming into outcomes the object. Relationships between
elements of activity are mediated not directed (eg subject to object relationship is
mediated by tools). An object transformation to an outcome is mediated by tools (eg
computers, papers, methods, etc).
The object is manipulated based on the limitations set by tools (Kuutti, 1996).
In developing an activity, artefacts are created and also transformed and they carry a
particular culture (historical remnant) with them of that development (Uden et al.,
2008). The subject to community relationship is mediated by rules (both implicit and
explicit), within communities in relation to object transformation to be come an
outcome (Uden et al., 2008). The basic structure of an activity is shown in Figure
2.10.
37
Figure 2.10: Basic Structure of an Activity (Uden et al., 2008)
According to Uden et al., (2008), activity has double nature, both an external
and an internal side.
Thus, object properties penetrate inward to the subject thereby
transforming him or her. This is called internalization (Kuutti 1996). Activities can
be considered as having three hierarchical levels (Kuutti, 1996) which includes;
activity, actions and operation (individual or cooperative). The activities may be
regarded as to motives, goals and conditions. An activity can be achieved via a
variety of actions (Uden et al., 2008). Figure 2.11 below illustrates the three levels
of an activity explained above.
Figure 2.11: The Three Levels of Activity (Uden et al., 2008)
38
Activity theory distinguishes between motives, goals and conditions as such;
it provides us with a means to analyze the dynamics of the application. Operations
become perturbed as a result of change in condition.
The system adapts
automatically due to this change.
2.7 Discussion
From the literature review, the researcher has identified the various tools and
techniques that different researcher adapted in order to manage design information
flow. The strength and weakness of the techniques have also been identified. Tools
like diagraph, PERT chart, SADT technique, and the design structure matrix are used
to manage design information in an information flow perspectives. While others like
information systems/repositories are used for information storage. We are also able
to identify the problems in managing architectural design information. Some of the
problems are the lack of planning in design projects, the ill structured nature of
architectural design, and the storage and retrieval of architectural design information.
We have chosen the design structure matrix for modeling the flow of
information in architectural design process/phases because it maps out the
information links among individual design tasks. It also provide a systematic
mapping that can be read with minimum level of clarity regardless of the size, and
also because it can make information interdependence explicit. In order to develop
the information framework, we shall consider web service based framework due to
the fact that, web service frameworks support accessing and sharing information in
different location.
39
2.8 Chapter Summary
In this chapter, the researcher has disscussed in detail information
management, information management systems, tools and techniques used in
managing architectural design information.
The use of information systems in
managing of architectural design information was also discussed. The problems of
managing architectural design information were also highlighted in this chapter. The
concept of activity theory also introduced.
CHAPTER 3
RESEARCH METHODOLOGY
3.1
Introduction
This chapter describes the methodology used for the research study. It gives
a clear picture on the methodology used in the study by describing all the activities.
The project operational framework, data collection and project schedule are also
discussed. For clarity, the work in this study has been divided into several phases
which provide a step by step approach for this study. Methodology can be defined as
organized, documented set of procedures and guidelines that includes the
frameworks, techniques, methods, patterns and procedures used to accomplish a set
of goals and objectives.
41
3.2
Research Design
Research design may be considered as a guideline to ensure that all project
activities are organized. By following a set of methodologies, programs, documents,
and data can be achieved as a result of activities and tasks that are included in the
methodology.
The purpose of this study is to develop a framework for design information
management system for architects. It begins with problem identification, objectives
and project scope. A study of how architects come up with the building design was
conducted. Various design information source and types, design process and the
search process are also identified.
An observation on data information and
knowledge handling in the design process was also carried out. In order to get
information about design information management, some observations, and literature
reviews was carried out.
3.3 Project Methodology
The required methodology for this project development began from initial
planning phase, analysis phase, modelling phase, and applying and evaluating phase,
with the specific activities and task in each phase.
Case study research method have been adapted for this work because of a
number of advantages one of which is, the detailed qualitative accounts often
produced in case studies not only help to explore or describe the data in real-life
42
environment, but also help to explain the complexities of real life situations which
may not be captured through experimental or survey research.
There is a need for a project methodology in order to ensure that all project
activities are well-organized. An operational framework needs to be built to ensure
that all project tasks are accomplished correctly.
operational framework.
Figure 3.1 shows the project
43
Phase 1: Planning phase



Project objective
Project scope
Project methodology
Phase 2: Analysis
Literature review
Data collection
Initial findings
analysis
Study the concept
of architectural
design, and the
flow of
information in
architectural
design process
Collect data
through direct
observation,
discussion, and
primary methods
of data collection
(design Structure
Matrix)
Analyze collected
data using
quantitative and
qualitative
analysis
approaches
Understand
information
management in
architectural
design
Identify the
problems in
managing
architectural
design
information
Develop the
activity system of
architectural
design information
management
system
Phase 3: Modelling
Design information flow in the design
process
Design framework and develop prototype
Phase 4: Evaluate the Frame work
Apply and evaluate the framework
Report writing
Figure 3.1: Project Operational Framework
44
3.3.1
Phase 1: Initial Planning
The project begins with the initial planning phase. The project title was first
discussed with the supervisor and the research objective was then analyzed and
defined according to the problem statement. The project boundary was then drawn
based on the identified scopes and limitations of the project. A research on the
background of the project in the form of literature review was done in order to decide
on the appropriate methodology of the project.
3.3.2
Phase 2: Analysis
This is the next step after the planning phase. The aim of the analysis phase
is to gain an in-depth understanding of the design process, design information
storage, design phases, the concept of architectural design, the flow of information in
design stages, and how the architects come up with the building design.
information was obtained by conducting literature review.
The
The analysis phase
consists of literature review, data collection, and initial finding analysis. These three
activities will be explained in later sections.
3.3.2.1 Literature Review Analysis
In the literature review, essential things such as definition of terms, the
concept of design, design process, design phases, data, information and knowledge in
45
the design process, design process modelling, architectural design information
system requirement determination, design information sources and types, design
information search, and design storage were analyzed and discussed. The processes
and stages that the architects follow to come up with the building design and the set
of architectural representations prepared over the process of building a building was
obtained through literature search.
The advantages and disadvantages of using case study as a research method
were also discussed. This comprehensive literature search helps the researcher to
obtain an in-depth understanding of the problem domain (Zainal, 2007).
This study is an objective to propose a new framework for design information
management systems that can support architects in coming up with the building
design.
Due to the increasing size and complexity of the implementation of
information systems, some researchers use some logical construct or architecture for
defining and controlling the interfaces and integration of the entire system
components. One of these researchers (Zachman J. A., 1999) studied the field of
architectural design, observed and examined the classical architects deliverables
produced in the process of constructing a building. He then compared it with the
process of building complex engineering product such as Airplanes. After that, he
combined these two ideas to develop a framework for information systems
architecture.
3.3.2.2 Collection Data
In this stage, different data collection methods will be employed in order to
obtain data from the research community/case study. The data collected will then be
46
analyzed using some analysis techniques in order to gain an understanding of the
situation and dimension of the problem. There are two methods of data collection
namely; quantitative and qualitative methods of data collection.
Quantitative and Qualitative Data Collection Methods:

Quantitative method is a research technique which is used for gathering
quantitative data (measurable information). Statistical tables and graphs are
used for presenting the results of these methods. This method rely on random
sampling, structured data collection instruments which fits the diverse
experience into a predetermined response category. The results produced are
easier to; summarize, compare and generalized. Qualitative research is used
for gaining a general sense of phenomena and for the formation of theories
that can be tested using further quantitative research. For instance, in the
social science fields, qualitative research methods are used for gaining a
better understanding of things like intentionality and meaning.

Qualitative methods are also loosely present in other methodological
approaches, such as action research. The forms of the data collected can
include; interviews and group discussions, observation and reflection field
notes, various texts, pictures, and other materials. The method plays a very
important role in the impact evaluation (providing useful information which
will assist in understanding the processes behind observed results, and
assesses changes in people’s perception of their well-being).

Quantitative and qualitative methods of data collection differ from each other,
but they are often times used together.
The advocates of quantitative
techniques argue that only by using the methods that the social sciences
become truly scientific field.
Where as, the advocates of qualitative
techiniques argue that quantitative techniques tends to obscure the reality of
social phenomenon because they under estimate and or neglect the nonmeasurable factors that can be the most important.
In reality, majority
tendency for the history of social science is to aim at using eclectic
approaches.
47

Qualitative techniques may be used in understanding the meaning of the
numbers.
Other methods of data collection are classified into these two methods
(quantitative and qualitative).
The following methods can be adopted; direct
observation and interviews, primary and secondary methods, and the advantages and
disadvantages of each of the above mentioned methods of data collection will be
explained in brief.
Direct Observation:

This is the best method of collecting data as it reduces the chance of in
correct data being recorded.
Unfortunately it cannot always be used,
generally on account of the cost. It will be uneconomical, for instance, to
follow a housewife around for a month in order to find out how many times
she vacuumed the lounge, quit apart from the practical difficulties. At other
times this method cannot be used because the information cannot be directly
observed, e.g. where people will spend their holidays if they had unlimited
money (McClave and Sincich, 2000).

Probably, the most fruitful context for direct observation is the collection of
internal data in an organization. Sales invoice, purchase invoice, times sheet
e.t.c (McClave and Sincich, 2000).
Discussion and Interviews:

An interview is a conversation between two or more people (the interviewer
and the interviewee) where questions are asked by the interviewer to obtain
information from the interviewee. It is a technique used to gaining an in
depth understanding of the reasons and what motivate people, preferences or
48
behaviour. Interviews can be conducted in different ways (one to one, and
group).

Conducting an interview face-to-face enable the researcher to establish
rapport with participants and therefore gain cooperation.
One other
advantage of conducting face-to-face interview is that, it yields the highest
response rates in survey research.
It allows the researcher to clarify
ambiguous answers and when appropriate, seek follow-up of information.

Some advantages of conducting personal interviews are (good response rates,
completed and immediate etc).

Despites the advantages of conducting interview, there are equally some
disadvantages. One disadvantage of interviewing is that inaccurate or false
data may be given to the interviewer. The reason may be; forgetfulness,
misunderstanding the question, or a deliberate intent to mislead.
For
example, a housewife who is asked how much milk she bought the previous
week may; have forgotten, include- or fail to include any milk bought by her
husband, overstate the amount because she has a number of children and feels
she ought to have bought more than she did (McClave and Sincich, 2000).

Another disadvantage of interviewing is that if a number of interviewers are
employed, they may not record the answers in the same way as the
investigator himself would have done. For example, to the question ‘Did you
watch the xyz TV program last night-yes or no?’ the interviewer may get the
answer, ‘well part of it, then someone called and we switch off’.
The
interviewer may well record this as a ‘no’ answer, while the investigator may
be working on the assumption that such answers are being recorded as ‘yes’
(McClave and Sincich, 2000).

Different standard like this can easily result in the wrong conclusions being
drawn from the survey. One way of overcoming this disadvantage is to train
the interviewers very carefully so that they record data in exactly the same
form as the investigator himself will record it (McClave and Sincich, 2000).
49
Design Structure Matrix:

In order to identify the flow of information in the different stages of
architectural design, the researcher will use the design structure matrix in
order to obtain inputs from architects on how information flow within the
architects plan of work. The matrix will be used as a primary method of data
collection. A design structure matrix is a graphical representation that uses
the structure of information flow to guide the decomposition of design
activity.

More so, the design structure matrix is a square matrix which maps out the
information links among individual design task. It provides a systematic
mapping that can be read easily and with reasonable level of clarity
regardless of the size. One major reason of using the matrix approach is that,
it embodies the structure of the underlying design activity by mapping and
the relations between the tasks in a precise order which makes
interdependence explicit. It also allows quick identification of tasks which
can be performed in parallel.
The reason for data collection is to help the researcher to have an in depth
understanding of the problem he intends to solve by using a small architectural
design team. The data that will be obtained from the team will tell the researcher
how these designers follow the architectural design process. It will also assist the
researcher to depict and also manipulate the flow of information in the design
process. The information that the researcher need from the data collection, the
source of the information, the method of collecting the data, and the person and
organization involved is shown in Table 3.1 below;
50
Table 3.1: Data, Source, Method of Collection, and Person/Organization Involved
Information
Needed
Source
Methods of
Collection
Person/Organizati
on Involved
Phases and
activities in the
architectural
design process
RIBA outline
plan of work,
2007
Literature review
Publication of
Royal Institute of
British Architects
Observation and
discussion
Lecturers from the
department of
Architecture,
Faculty of Built
Environment, UTM
Using design
structure matrix to
obtain the data
3- lecturers form the
department of
Architecture,
Faculty of Built
Environment, UTM
a) RIBA
outline
plan of
work,
2007 and
b) Design
Manuals
The way
Department of
architects follow
Architecture,
the design phases/ Faculty of Built
work stages
Environment
The types of
information that
flows in the
architectural
design process
3.3.2.3 Collected Data Analysis
The researcher examines raw data using many interpretations in order to find
linkages between the research object and the outcomes with reference to the original
research questions.
The use of multiple data collection methods and analysis
techniques provides the researchers with opportunities to manipulate data in order to
arrive at a conclusion.
Data analysis is a process of gathering, modeling, and
transforming data with the goal of highlighting useful information suggesting
conclusions, and supporting decision making. Data analysis has multiple facets and
approaches, encompassing diverse techniques under a variety of names, in different
business, science, and social science domains.
Analysis involves decomposing
51
complex conceptions with complicated information and breaking it into smaller and
more understandable components. This activity helps to understand the needs and
requirements of this research.
Analyzing data such as organizing data into arrays, creating statistical
displays, and tabulating frequency of events involves the use of some research
techniques. One of these techniques involves the use of multiple investigators to
gain the advantage provided by using a variety of perspectives to examine data and
pattern. Quantitative data collected is used by researchers to corroborate and support
qualitative data that is useful in understanding rationale underlying relationships
between the data collected.
The points this phases will discuss are:

Organization
o Analyze and study the area of organization under taking.

Requirements Gathering
o Respondents’ analysis
o Observation/discussion fulfilment

Literature Review

Critical analysis of related literature and search for existing gap to be
filled by the research

Critical review of empirical and conceptual issues in literature
52
3.3.3
Phase 3: Modelling
The modelling phase is aimed at explaining the detail phases of framework
design, the system development approach, and the methodology justification. The
sections below will explain the researcher’s approach.
3.3.3.1 Design Framework
Designing a framework involves two main phases. Framework development
phase which is aimed at producing a useful design in a particular domain and it is
often an effort consuming phase. The two framework development phases are;
framework usage or instantiation phase where framework is developed, and
framework evolution and maintenance phase. A number of activities characterize the
first framework development phase.
These activities are; domain analysis,
architectural design, framework design, framework implementation, and framework
testing. According to Adair, (1995), the following four guidelines must be observed
while developing a framework:

Derive the framework from existing problem(s) and solution(s)

Develop a small, focused framework.

Build the framework.

Treat the frameworks as products by providing documentation and support,
and by planning for distribution and maintenance.
53
3.3.3.2 System Development Methodology
In this project the researcher used evolutionary prototyping model as guide
lines for the development of the project due to the fact that every project needs to
follow one of the proven system development methodologies. Below are the phases
of the evolutionary prototype model;

Basic requirement definition

Creating the working prototype

Verification of the working prototype

Changing or elaborating the requirements
One advantage of evolutionary prototyping model is that it allows you to
create working software prototypes fast and may be applicable to projects where
system requirements are not known in the early stage of system design, the
developers lack confidence in the software architecture, and creating fundamentally
new software.
3.3.3.3 Methodology Justification
Evolutionary prototype model is chosen as the appropriate methodology to
capture the framework and prototype requirements needed by users. This is due to
the fact that, the methodology targets the speed of product delivery and concentrates
on identifying requirements so that the first version of the product can be delivered
quickly, though with incomplete functionality of the first version of the product.
54
3.3.4
Phase 4: Evaluate the Framework
The following section is aimed at explaining how the framework will be
tested, validated, and report writing. The section below will talk on framework
evaluation.
3.3.4.1 Apply and Evaluate the Framework
The designed framework will be tested in real environment by the users of the
framework which are mainly architects. The framework will as well be validated by
developing a simple application.
3.3.4.2 Report Writing
Report writing involves transforming a complex (Zainal, 2007) issue into one
that can be easily understood allowing a reader to question and examine the study
(Zainal, 2007), and to also reach an understanding independent from the researcher.
This is also the main goal of report writing. Researchers do focus on displaying
sufficient evidence of all areas explored by clearly communicating scope and
boundaries of the research study while paying attention to prepositions that conflict
with the research.
55
Preparation of a comprehensive written research report is an essential part of
a valid research experience, and the researcher should be aware of the requirements
at beginning of the project. The researcher first submits an initial draft document for
comment and based on the comments, corrections are made.
3.4
Project Schedule
The purpose of project schedule is to list all the activities that will be done in
order to accomplish the objectives of the project. The project schedule covers all
phases including planning phase, literature review and analysis that have already
been accomplished. The details of the project schedule are shown in Gantt hart
attached in Appendix A.
3.5 Software and Hardware Requirements
In this section, the researcher will highlight the hardware and software
requirements of the architectural design information system prototype. The software
requirement of the prototype is shown in Table 3.2 below;
56
Table 3.2: Software Requirements
Software
Purpose
Adobe Dreamweaver CS3
Tools for Web Page Design. The
researcher will use this tool to design
the prototype interface for this project.
Basic features of Adobe Dreamweaver
CS3

HTML, CSS, vbscript, and java
script

XML, Rss, and web services
support

ASP Java script, ColdFusion
components and PHP

What you see is what you get
visual design surface

Fully customizable

Easy to configure and deploy
and

XAMPP SQL Server 2000
Simplified debugging.
XAMPP SQL Server is a full-featured
relational database management system
(RDMS)
with
a
variety
of
administrative tools that ease the burden
of
database
administration,
development, and maintenance. In this
project, the researcher is going to use
My SQL server 2000 as a back end of
the
prototype
to
store
data
and
information for easy retrieval.
The researcher choose to use XAMPP
57
Server because it is easy to use, it is
user friendly, and can store variety of
data types. It also makes connection
with visual web developer easy.
Rational Rose Enterprise Edition 2003
Rational Rose is a tool that enables
teachers, students, researchers, and
business professionals to create, and
publish diagrams (such as use case,
activity diagram, state chart etc) and to
model business process.
Microsoft Office Project 2007
Microsoft Office Project Server 2007
provides a set of tools that enables one
to effectively coordinate, manage, and
track project work, individual work, and
team work. In this research, this tool
will be used to create project schedule.
Microsoft Windows XP 2006
Microsoft Windows XP professional
edition 2006 will be used as a window
operating system to be used in the
project development
Microsoft Word 2007
Microsoft word 2007 will be used for
project report writing and any other
documents needed during the project
development
The hardware requirements for this project are listed below;

Processor 2.0 GHz Pentium IV

Memory 1G of RAM.

Hard Disk 40 GB.

Drive CD-ROM or DVD-ROM drive.

Display Super VGA (1024 x 768) or higher.
58

Mouse, MS Mouse or compatible pointing device
3.6 Chapter Summary
This chapter has identified the project development methodology and
methods or approaches to be used in developing the framework for design
information management system for architects.
The prototype methodology is
chosen with evolutionary approach as it is the appropriate methodology for the
development of the framework. Hope that the identified methodology will serve as a
guide to develop the design information management system framework.
CHAPTER 4
DATA COLLECTION AND DATA ANALYSIS
4.1 Introduction
The purpose of this study is to look at the detail architectural design stages
and to understand how information flows within the stages. In order to gather the
information required, the researcher used the various tools and techniques of data
collection highlighted in the project operational framework in Chapter 3. An anlysis
of the data collected will also be carried out. The design structure matrix will be
used to dipict the flow of information in architectural design stages. The concept of
activity theory is applied to architectural design in order to capture the system
requirements. A comprehensive summary of the chapter will be given at the end of
this chapter.
60
4.2 Organizational Analysis
In order to understand the flow of information within the architectural design
stages we carried out an observation and discussion in the Department of
Architecture of the Faculty of Built Environment of the Universiti of Teknologi
Malaysia.
4.2.1 Introduction to Faculty of Built Environment (FAB)
Faculty of Built Environment was incepted in 1972 (as the Faculty of
architecture). It was later changed in 1974 when the Department of Urban and
Regional Planning and the Department of Quantity Surveying were incorporated
under its administrative umbrella.
The courses that were offered then are
architecture, urban and regional planning (URP), and quantity surveying (QS),
offered both as a three year semi-professional diploma programme and a professional
degree structure.
FAB was among the first faculties that relocated to the Skudai main campus
in Johor, across the causeway from Singapore, in 1985.
Other academic activities
include courses offered through the auspices of School of Professional and
Continuing Education (SPACE), which was initiated in 1997 and post-graduate
studies in various disciplines.
61
4.2.1.1 Faculty of Built Environment’ Objectives

To be a visionary organization with dynamic amicable and intellectual work
culture and concern with sustainable development.

To be the faculty of choice in the field of built environment in Asia fully led
by doctorate holders, equipped with state of art facilities, strong financial
structure, a network of reputable partners, and an emphasis on research and
post graduate studies in new area.
4.2.1.2 Mission and Vision
Vision: “to lead the faculty as an international center for the study of built
environment”.
Mission: “to lead professional education in built environment”.
4.2.1.3 FAB Organizational Structure
FAB organizational structure is shown in Appendix E
62
4.2.2
Royal Institute of British Architects (RIBA) Outline Plan of Work
The Royal Institute of British Architects is the UK body for architecture and
the architectural profession.
They support a memership population of 40,500
members worldwide in the form of training, technicalservices, publications and
events, and set standards for the education of architects, both in the UK and oversea.
The Outline Plan of Work, 2007 organises the process of managing,
designing building projects, and administering building contracts into a number of
key stages. But the sequence or content of the Work Stages may vary or they may
overlap to suit the procurement method. The RIBA Outline Plan of work 2007 is
shown in Appendix C of this work. The design structure matrix will be used to show
the flow of information within the different stages of architectural design. There are
five (5) phases namely; preparation, design, pre- construction, construction, and use
phases in the RIBA work stages. Each of the phases has sub phases, and each sub
phase of the outline plan of work contains a description of key activities and
deliverables.
In the preparation phase, we have appraisal phase and the design brief phase.
The key tasks in the appraisal phase are; identification of client need’s business case
and possible development, preparation of feasibility studies and assessment of
options to enable the client to decide whether to proceed or not. In the design brief
sub phase, the key tasks are; development of initial statement of requirements into
design brief by or on behalf of the client confirming key requirements, identification
of procurement method, procedures, organizational structure and range of consultant
to be engaged in the project. The outcome of these two sub phases is business
justification and procurement strategy.
The design phase has three sub phases namely; concept phase, design
development phase, and technical design. The key activities in the concept phase are;
63
implementation of design brief and preparation of additional data, preparation of
concept design including outline proposals for both structural and building service
systems, outline specifications and preliminary cost plan, and review of procurement
route.
Unlike the concept phase, the design development phase consists of
development of concept design (including structural and building service systems,
updated outline specifications and cost plan), completion of project brief and
application for detailed planning permission. The outcome of these two sub phases
is design brief and concept approval. The technical design phase has to do with the
preparation of technical design (s) and specifications. The outcome of this sub phase
is the detailed design approval.
The pre- construction phase comprises of; production information phase,
tender documentation phase, and tender action phase. The key activities in the
production information phase are; preparation of production information for tenders
to be obtained, application for statutory approvals, and preparation for further
information for construction required under building contract. The activities in the
tender
documentation
phase
are;
preparation
and/or
collation
of
tender
documentation in sufficient detail to enable a tender or tenders to be obtained for the
project. Unlike the tender documentation phase, the tender action phase has to do
with the identification and evaluation of potential contractors and/or specialists for
the project, and obtaining and appraising tenders; submission of recommendations to
the client. The outcome of the pre- construction phase is investment decision.
The construction phase comprises of the mobilisation phase, and construction
to practical completion phase. The key activities in the mobilisation phase are;
letting the building contract, appointing the contractor, issuing the information to the
contractor, and arranging site hand over to the contractor. The outcome of the
construction phase is readiness for service.
The use phase consists of the post practical completion sub phase. The key
activities in this sub phase are; administration of the building contract after practical
64
completion, making final inspections, assisting building user during initial
occupation period, and review of project performance in use. The outcome of the
use phase is benefits evaluation.
4.3 Data Collection
This section will focus on explaining how data was collected according to the
project operational framework.
conducting this research.
Three methods of data collection are used in
These data collection methods are direct observation,
discussion, and primary methods of data collection. The researcher carries out an
observation and discussion at FAB, UTM. The researcher also used the design
matrix to collect data from architects in the department of architecture of FAB who
are registered professionals and lecturers at the same time. The matrix used for data
collection is attached in Appendix B.
4.3.1 Observation and Discussion
The main aim of the observation/discussion is to identify the different stages
in architectural design and to find out how information flow within the design stages,
and to also identify if there is any architects best practice they follow.
The
discussion was held in the Faculty of Built Environment with the coordinator of the
department of architecture.
65
4.3.2
Design Structure Matrix
The aim of using the design structure matrix as a primary method of data
collection is that, it also allows quick identification of tasks which can be performed
in parallel and it maps out the information links among individual design task. It
also provides a systematic mapping that can be read easily and with reasonable level
of clarity regardless of the size.
Again, the design structure matrix embodies the structure of the underlying
design activity by mapping and the relations between the tasks in a precise order
which makes interdependence explicit. It also provides a systematic mapping that
can be read easily and with reasonable level of clarity regardless of the size.
4.4
Observation, Discussion, and Matrix Design
In this section, the researcher talks about the structure of the
discussion/observation, the secondary statistics. The outcomes of both discussion
and observation and that of the published architect outline plan of work were
summarized.
66
4.4.1 Observation and Discussion Summary
In order to identify the various stages and the flow of information in the
different stages of architectural design, an observation and discussion was carried out
in the Department of Architecture in Faculti of Built Environment, Universiti of
Teknologi Malaysia.
This is due to fact that, the role of an architect is far beyound just designing a
building. It is also considered a role of an architect to develop the building design,
employed by the client to act as his agent and see that he is provided with a building
which will satisfy his needs, etc. One of the lecturers selected for discussion is a
registered member of the British Architect who was at one time or the other involved
with clients. The architect work is based on contract.
The discussion with the coordinator of architecture in person of Dr. Khairul
of FAB was fruitful.
The meeting was fruitful as many issues concerning
architectural design were raised.
Issues like the design mode (loud and silent
modes). An architectural design practice Log sheet was also observed. The form was
provided by the Malaysian government to be used by architects to record practical
training in an architect’s office. The form contains architectural design stages which
includes; Brief (stage A and B), Design process (stages C, D and E), Production
Information (stages F and G), Contract (stages H, J, K, and L), and Project
management. The activities in the form are obtained from the RIBA outline plan of
work. The researcher observed that, the architects go back and forward and vice
versa. Meaning they don’t follow the design stages in sequence.
67
4.4.2
Design Matrix Summary
A small team of three (3) designers from the department of architecture of
Faculty Alam Bina of the Universiti of Teknologi Malaysia provided the input for the
research. The team comprises of two registered professionals (architects). The third
member of the team is not yet a registered professional. One of these professional is
registered with the Board of Malaysian Architects and has a twenty (20) years of
experience in architectural design. Where as the other architect is registered with the
Architect Registration Board of United Kingdom and has four (4) years of
experience as a practising architect. The other member of the team though not a
professional has six (6) years experience in architectural design.
In order to obtain their input, a design structure matrix with fourteen design
activities or tasks (based on the RIBA outline plan of work 2007) was distributed to
each member. The design activities are; appraisal (A), design brief (B), concept (C),
design development (D), technical design (E), preparation of production information
(F1), preparation of further information for construction (F2), tender documentation
(G), tender action (H), mobilization (J), construction to practical completion (K),
administration of contract after completion (L1), assisting building user during initial
occupancy (L2), and review of project performance in use (L3). The tasks (A to L3)
are placed downside of the matrix as row headings and accross the matrix as column
headings (as shown in Appendix B). For nodes i and j, the matrix element is non zero
if node i provides information to node j.
The summary of the understanding of the team members (3- member team) as
regards to the flow of information in the architectural design phases (see Figures 4.1,
4.2, and 4.3).
68
Figure 4.1: Input of Architect with 20 Years Experience (Registered with the
Malaysian Board of Architects)
From Figure 4.1 above, appraisal requires input from design brief (bubble
charts; gross sizing, shape, spatial relationships etc), design development (architect
drawings i.e. images, and cost plan), review of project performance in use. Design
brief requires input from appraisal phase (client needs and objectives; audio or text),
concept (proposals; initial architect drawings, specifications and cost plan), and
design development (architect drawings i.e. images, and cost plan). Concept requires
inputs from design brief (bubble charts; gross sizing, shape, spatial relationships etc),
design development (architect drawings i.e. images, and cost plan), technical design
(shop plans; detailed stand-alone model), and production information (detailed
information for building contract).
Design development requires input from
technical design (shop plans; detailed stand-alone model), production information
69
(detail information for obtaining tender), and tender documentation (tender
documents). Technical design requires input from design development (architect
drawings i.e. images, and cost plan), production information (detail information for
obtaining tender and detailed information for building contract), tender
documentation (tender documents), and tender action (documents; recommendation
of potential contractors).
Production information (F1) requires input from design development,
technical design, production information (F2), tender documentation, tender action,
and mobilisation (site hand over documents). Production information (F2) requires
input from design development, technical design, production information (F1), and
mobilisation.
Tender documentation requires input from design development
(architect drawings), technical design (shop plans; detailed stand-alone model), and
mobilisation (site handover documents). Tender action requires input from design
development (architect drawings), and mobilisation (site handover documents).
Mobilisation requires input from design development and construction to practical
completion (physical building). Construction to practical completion requires input
from design development (architect drawings), and mobilisation (shop plans; detailed
stand-alone model). Post practical completion requires input from design
development, and construction to practical completion. Figure 4.2 below shows the
understanding of an architect with four years experience.
70
Figure 4.2: Input of Architect with 4 Years Experience (Registered with the
Architects Registration Board of United Kingdom)
From the diagram above (Figure 4.2), we can depict that appraisal requires
input from design brief and design brief requires input from appraisal and concept.
On the other hand, concept requires input from design brief and design development
whereas; design development requires input from design brief, concept and technical
design.
Technical design requires input from concept, design development,
production information (F1 and F2), and tender documentation.
Production
information requires input from technical design. From the figure, we can also
observe that, tender documentation requires input from tender action, mobilisation,
and construction to practical completion. Tender action requires input from design
brief, concept, design development, and technical design.
Mobilisation requires
71
input from production information (F2), and tender documentation. Construction to
practical completion requires input from technical design, and production
information
(F2).
Post
practical
completion
requires
input
from
tender
documentation. The understanding of the flow of information for the unregistered
architect is shown in the figure below.
Figure 4.3: Input of Unregistered Professional with 6 Years Experience
72
From the diagram above (Figure 4.3), we can depict that appraisal requires
input from concept and design brief requires input from concept and design
development. On the other hand, concept requires input from design brief, design
development, tender action, and construction to practical completion.
Design
development requires input from concept, technical design, production information
(F1 and F2), tender action, and construction to practical completion. We can also
observe that, technical design requires input from concept, design development,
production information (F1), and construction to practical completion. Production
information requires input from concept, design development, technical design, and
construction to practical completion. Tender documentation requires input from
concept, design development, technical design, production information (F1 and F2),
tender documentation, tender action, and construction to practical completion.
Tender action requires input from production information (F2), and construction to
practical completion. Mobilisation requires input from production information (F1
and F2), and construction to practical completion.
Construction to practical
completion requires input from design development, technical design, production
information (F1 and F2), tender documentation, tender action, mobilisation, and post
practical completion (L3). Post practical completion requires input from appraisal,
design brief, concept, design development, technical design, production information
(F2), tender documentation, tender action, and construction to practical completion.
The next section explains the activity system of architectural design information
management system.
4.5
Architectural Design Information System Requirement Capture
In order to capture the requirements of information system, the concept of
activity theory will be used to model the architectural design processes and the role
played by the respective subjects in those processes.
73
4.5.1 Applying the Concept of Activity Theory to Architectural Design
This section explains the use of activity theory in analyzing the processes,
and the applications or tools used in architectural design. The basic unit of analysis
in our own case study is the set of activities that the users (architect designers) need
to carry out with the application (design information management system). In order
to accomplish this objective the following three steps adapted from the work of Uden
et al., 2008 are to be followed;
Step 1: Clarifying the purpose of activity system
Clarifying the goals/motives of an activity system is of outmost importance.
The main purpose of this activity is to have an understanding of the context in which
the activities occur and also to reach an understanding of what motivates the activity
being (Uden et al., 2008) modeled the interpretations of perceived contradictions
(Uden et al., 2008).
The aims of our case study is to provide a support to architects to come up
with the building design, by developing a framework for design information
management system for architects.
The framework should provide a way of
effectively managing architectural design information. The set of activities in the
activity system that composes of objects, actions, and operations, mainly constitutes
the context (Uden et al., 2008). The context is constituted by the enactment of an
activity which involves a person (subject) and an artefact (Uden et al., 2008). Thus,
the activity system is the context. The activity system is connected to other activity
systems. An activity is both internal and external. It should be noted that both
external and internal are fused and unified in the activity theory. More so, context is
not persistent and fixed information, and a continuous construction is going on
between the components of an activity system (Uden et al., 2008). Humans use and
also produce and renew tools either consciously or unconsciously (Uden et al., 2008).
74
They use and also transform rules. Understanding how things get done in context is
important in design (Uden et al., 2008). This is due to the facts that, different
contexts impose different practices. Knowing the need beliefs, assumptions, models
and methods that group members group members held is important in analyzing
context.
In addition, the following external or community-driven contexts are
adopted from the work of Uden et al., (2008);

What is the type of limitations that are placed on each activity by outside
organizations?

How are tasks organized while working towards an object?

What social interaction surrounds the structure of the activity?

What are the critical activities?

Who are users involved in an activity?

What are the aims purposes of each activity, and action to the users?

What motive the user intends to achieve?

What are the users expected outcomes?
Step 2: Analyze and produce the activity system
In this step, we are going to define, in depth the components of the activity
system (subject, object, division of labour, community, tools and rules).
To
accomplish this we start by interpreting the components of the triangle (Figure 4.4)
in terms of the situation. The subjects in the design information management system
consist of the architects, clients, system administrator, system developers etc. the
object in our own case is the design information (image, design stage documents,
design parameters, previous design, client specification documents, rules, existing
theories etc). The outcome is building design information, and feedback from both
client and architect.
75
Figure 4.4: Activity System for Architectural Design Information Management
System
Step 3: Analyze the structure of the activity
This step involves decomposing each activity into its operations. It involves
analyzing the activity structure (Uden et al., 2008) (i.e. all the activities that engage
the subject) which defines the purpose of the activity system (architectural design).
This activity structure is described by the hierarchy of activity, actions and
operations. It involved defining the activity using questions. Some of the question
adopted from the works of Uden et al., (2008) are listed below:

How is the work being performed in practice?

How was the actions and operations transformed with time?

What are the historical phases for an activity?

The goal of an activity their relations to the current goals?
76

What actions are performed for each activity and by whom?

Observe and analyze the operations that the subjects perform for every action.
In order to understand the use of technology, we first start with identifying
the goals of actions that are made explicit (Uden et al., 2008). We then extend the
scope of the analysis both higher levels of actions and activities, and to lower levels
of actions and operations. In order to achieve this, we consider the following
questions (adapted from the work of Uden et al., 2008):

Who will use the application?

What goals are there for the target action(s)?

Who are the people involved in the process?

What is the limitation of the current technology?

What conflicts are there for the user’s goals?

What are the criteria for the success or failures?
To capture the requirements for the design information management system
for architects, we must analyze the levels that activities have (activity, action and
operation). In order to analyze activities together with the actions that compose it,
we shall consider hierarchical task analysis technique (used traditionally to represent
the actions that users perform during the activity) and task model based on activity
theory.
To analyze how people externalize their work, the task model should
describe Uden et al., 2008):

What are the aims of the actors?

How do the actors employ the tools and resources in mediating the interaction
and while externalising cognition;

What methods do the actors employ?

What are the actors' conceptions as regards to work (including the sources of
difficulties, breakdown, and attitudes towards the target application).
77
In order to break an action into smaller actions we use structural refinement
technique (as shown in Figure 5.9). We also used temporal refinement techniques
(depicted by dashed lines in Figure 5.9) to decomposes actions into smaller actions
that must be performed in a cooperatively. Cooperation in this work is represented
by temporal constraints among actions. The constraint we used in this work is
adapted from the work of Lorna Uden et al. (2008) and it include;

Enabling with information passing (A1 []>> A2,): action A2 have to be
performed only after the action A1 is performed first (A1 provides a value for
A2).

Suspend-Resume (A1 |> A2): action A1 can be interrupted in order to
perform the action A2 (after A2 performed, and A1 can be resumed).

Iteration (A1*): action can be performed many times.
Based on the literature review and the findings from observation, and
discussion, we define the activities that the architects will perform in a design
information management system. This is shown in Figure 4.5 below;
78
Access Design
Information
Activity
Actions
[]>
>
Register
Login
*
Access
Design Info
Add/Edit
Record
Sort
Record
|>
*
Search
Retrieve
Record
Figure 4.5: The Hierarchical Decomposition of Activities into Actions
Briefly, we shall describe the taxonomy in the figure above.

The activity we are analyzing is the access design information (register and
login (must be performed).
cooperative.
These actions (register and login) are
The constraint that is defined between both enabling with
information passing (Uden et al., 2008). Firstly, the users have to register
before login can be made. The information to be exchanged is the user’s
registration details.

After the user login, there are two simpler operations that the user may
perform which are; Access design info repository and search internet. The
temporal constraints between the two actions suspend-resume, shows hat
Access Design info Repository can be interrupted by Internet Search. It will
then be reactivated once Internet search is performed. Both actions (Access
design info repository and internet search can be performed several times).

The action Access Design Info Repository is decomposed into three
individual actions: Add/Edit record, Sort record and Retrieve record.
79
And finally, each action is associated with a template that will assist us in
characterizing it in the context of the entire activity. The following field shows what
the templates are made with (see Table 4.1):

Objectives: goals that must be reached after performing the action.

The list of kinds of users (Users) who will achieve the action.

Information: additional that will enable us obtain an understanding of context
better. This is shown in Table 4.1 below;
Table 4.1a: Description of the action Add/Edit Design Info Repository
Action
Add/Edit Design Info Repository
Goal
The action subject add/edit the records in the design
repository
Subjects
Users (architects, clients, and system admin)
Table 4.1b: Description of the action Sort Records
Action
Sort Records
Goal
The action subject sort records from the design
repository
Subjects
Users (architects, clients, and system admin)
80
Table 4.1c: Description of the action Retrieve Records
Action
Retrieve Records
Goal
The action subject retrieve records from the design
repository
Subjects
4.6
Users (architects, clients, and system admin)
Chapter Summary
As a summary, the researcher discussed in detail how data was collected,
observation and discussion, data obtain from the primary source (using the matrix)
secondary source, observation/discussion design, data analysis methods and
techniques used, and the methods that were used to show the flow of information
within the various stages of architectural design (Design Structure Matrix). The
detail understanding of the professionals as regards to the flow of information with
the RIBA work stages was also discussed in detail. An activity system of
architectural design information management system was also developed. The next
chapter will discuss the design process analysis, and the framework for architectural
design information management system.
CHAPTER 5
FRAMEWORK OF ARCHITECTURAL DESIGN INFORMATION
MANAGEMENT SYSTEM
5.1
Introduction
This chapter presents the result from the study of the various activities in
architectural design and the flow of information wthin these design phases and
activities.
The main activities to be covered in this chapter are: firstly, the
architectural design process analysis (using partitioning algorithm), secondly, the
architectural design process analysis (using tearing algorithm), and finally, to come
up with a model of architectural design information management system (ADIMS),
based on the models mentioned in the literature, for architects to manage design
information.
The system overview, the user activity management, the user
registration and login validation, and information model design for the system will be
presented in this chapter.
82
5.2
Matrix Representation of Architectural Design Phases
The different phases and the flow of information that took place within the
phases of architectural design can best be presented in a design structure matrix. For
the detail stages and the flow of information within the stages see section 4.4.2 of
chapter 4.
A design activity composed of n task would be represented as an nxn matrix,
with task labels placed downside of the matrix as row headings and across the top as
column headings in the same order (Gebala and Eppinger, 1991). For nodes i and j,
the matrix element aij is non zero if node i provides information to node j. In our
own case, we have fourteen (14) activities. The activities are labeled A to L3 (as
shown in Figure 5.1 below). The plot in the matrix shows the flow of information
within the design activities. An empty row corresponding to an activity means that
activity requires no information from any other activity, where as, an empty column
means the design activity provides no input to any other activity (as shown in Figure
5.1).
From the outcome of data analysis in section 4.4.2, we combine the
understanding of the two registered profesionals (architects) into one matrix (as
shown in Figure 5.1) so as to assist the researcher in conducting architectural design
process analysis (matrix partitioning).
This is due to the fact that most of the
understandings of the design process of the two architects captured most of the
understanding of the unregistered professional.
83
Figure 5.1: The flow of information in Architectural design stages
From Figure 5.1 above, task A (appraisal) requires input tasks B (design
brief), D (design development), and L3 (review of project performance in use). Task
B (design brief) requires input from appraisal (A), concept (C), and design
development (D).
Concept (C) requires inputs from design brief (B), design
development (D), technical design (E), and preparation of further information for
construction (F2). Task D (design development) requires inputs from design brief
(B), concept (C), technical design (E), preparation of production information (F1),
and tender documentation (G). Technical design (E) requires inputs from concept
(C), design development (D), preparation of production information (F1), and
praparation of further information for construction (F2), tender documentation (G),
and tender action (H). Preparation of production information (F1) requires inputs
from design development (D), technical design (E), preparation of further
information for construction (F2), tender documentation (G), tender action (H), and
mobilization (J). Preparation of further information for construction (F2) requires
inputs from design development (D), technical design (E), preparation of production
information (F1), and mobilization (J). Task G (tender documentation) requires
84
inputs from design development (D), technical design (E), and tender action (H),
mobilization (J), and construction to practical completion. Tender action (H) requires
input from design brief (B), concept (C), design development (D), technical design
(E), and mobilization (J).
5.3
Design Process Analysis: Partitioning
Once the design process has been mapped out in a design structure matrix the
analysis proceeds in two different stages (Gebala and Eppinger, 1991). These two
stages are partitioning and tearing. Partitioning is aimed at resequencing the design
task so as to maximize the availability of information required at each stage of the
design process. Where as, tearing is aimed at resequencing within the blocks of
coupled tasks so as to find an initial ordering to start iteration.
In order to partition the design structure matrix we will use the partitioning
algorithm adapted from the work of Gebala and Eppinger (1991). The steps of the
partitioning algorithm are shown in table 5.1 below.
85
Table 5.1: Partitioning Algorithm (adapted from Gebala and Eppinger, 1991)
Steps
Tasks
1.
Schedule the tasks which are not components of any loops. Tasks
with empty rows have all required information and can be performed
first. Tasks with empty columns provide no information required by
future tasks and can be performed last. Once task is scheduled,
remove it from further consideration. Repeat until no empty columns
or rows are found.
2.
Identify loops either by path searching or by the powers of the
adjacency matrix. Represent all tasks in a loop as a single task.
3.
Repeat steps 1 and 2 until all tasks have been scheduled.
The three steps highlighted in Figure 5.2 above are refered to as partioning
algorithm. For the matrix (Figure 5.1) with 14 tasks, the partitioning proceeds as
follows: (Figure 5.1) is the unpartitioned matrix in its original form. In order to
partition the matrix we first check for tasks that are not components of any loop (task
with empty rows or empty columns). Since none exist, it indicates the existence of
loops of information dependence that must be identified. In order to identify the
loops of information flow within the RIBA work stages we shall use a technique that
uses powers of adjacency matrix to identify higher order loops.
5.3.1
Identifying Loops by Powers of Adjacency Matrix
This technique is adapted from the work of (Gebala and Eppinger, 1991).
The adjacency matrix is a square matrix that is identical to a design structure matrix
but the diagonal elements are removed and the non blank elements are replaced with
86
1’s. For a non-zero element aij in the adjacency matrix, a task i say is directly linked
to a task j if it provides direct input to the task. Squaring the matrix will reveal the
tasks that are reachable in two steps. Before raising the matrix to the nth power, we
first change the non-zero entries with 1’s (as shown in Figure 5.2).
Figure 5.2: The Design Structure Matrix with non-zero entries replaced with 1’s
In order to obtain a higher-order matrix containing elements aij, we raise the
binary adjacenecy matrix (Figure 5.3 above) to the nth-power using Boolean
arithmetic rules [a1*a2*a3*... = min(a1,a2,a3,...), a1+a2+a3+... = max(a1,a2,a3,...)].
The operation was performed using MATLAB (output shown in Appendix F). The
square of the adjacency matrix (Figure 5.4) reveals that all the tasks are in a loop.
This is true because all the diagonal entries are 1’s and not empty. The cube of the
adjacency matrix (Figure 5.4) also reveals that the tasks from A to L3 are all in a
loop.
87
Figure 5.3: The Square of Adjacency Matrix
Figure 5.4: The Cube of Adjacency Matrix
88
Having identified the loops in the matrix, the next step is aimed at ordering of
the task within the blocks (tearing). This is explained in Section 5.3.2 below.
5.3.2
Ordering of Task within the Blocks (Tearing)
After successful identification of loops in the design structure matrix using
partitioning algorithm, the next stage in the design process is to conduct tearing
analysis so as to order the tasks within the blocks (loops). One of the tearing
techniques used is tearing by heuristics (as shown in table 5.2).
Table 5.2: Tearing Algorithm (adapted from Gebala and Eppinger, 1991)
Steps
Tasks
1.
Schedule the tasks which have a minimum number of input streams
(initially there will be none). These are identified in the matrix as tasks
with the minimum number of row elements. If there is more than one
such task, select the one with the maximum number of output streams.
These are identified in the matrix as tasks with maximum number of
column marks. If this fails to identify a unique task, starting with each
one of the tasks under consideration, compare the number of steps
required to reach all other tasks under consideration. The task which
requires the maximum number of steps is selected. If the lists are of
equal length, the choice is irrelevant.
2.
Remove the scheduled task from consideration and repeat step 1 until
all tasks have been scheduled.
89
For clarity, we identified the nodes, row entitries, and column entitries
associated to each node and organized them into a table (as shown in Table 5.3)
Table 5.3: Nodes with their Row and Column entries
No
Row Entries
Column Entries
A
3
1
B
3
4
C
4
4
D
5
13
E
6
7
F1
6
3
F2
4
5
G
5
6
H
5
3
J
4
5
K
4
3
L1
5
2
L2
4
2
L3
3
3
des
90
The tear suggested by the matrix is shown in Figure 5.5 below.
Figure 5.5a: Tear Suggested by the Matrix
91
Figure 5.5b: Tear Suggested by the Matrix
The tear from the matrix (Figure 5.5) above suggest the following; design
brief (B) is to be schedule first before any other task. The next task to be schedule is
review of project performance in use (L3). Appraisal (A) should be scheduled next
followed by preparation of further information for construction (F2). Mobilization
(J) should be schedule after task (F2). Concept (C) should be schedule after
mobilization and it should be followed by construction to practical completion (K).
The tear also suggested that assisting building user during initial occupancy (L2)
should be next to task K. Design development should be scheduled after L2 and it
should be followed by tender documentation (G). Tender action should be scheduled
next to task G and it should be followed by task L1. The next task to be scheduled is
92
technical design (E) and preparation of production information should be scheduled
last.
5.4 Proposed Framework for Architectural Design Information Management
System (ADIMS)
In this section, we present the proposed framework that provides for
architectural design information management system. The framework is developed
to handle the deliverables of the different stages of architectural design identified in
the literature review.
It is designed to also handle the interaction between the
architect and the client. In order to come up with a framework of an information
system to support architects, we divided the task into steps namely; system overview,
users’ activity management, users’ registration and login validation and information
model design for easy understanding. We will start with the system overview
(Section 5.5).
5.5
System Overview
The system is designed to interface between architect, client, and the system
administrator (admin) so that there will be an effective management of architectural
design information.
First, the user of the system (architect, client, and system
administrator) provides their email address and password to login to the system.
While in his account, each of the earlier mentioned users have different role to play
93
in the system. They also have different access rights. The system overview is shown
in Figure 5.6.
The input that the architect feed into the system includes email address and
password, architect profile, design parameters, previous design, design experience
records, and design stage deliverable records. The architect recieves design
information and client specification from the system. The client on the other hand
feed the system with email address and password, client profile, design specification,
and make appointment. The system feeds the client with architect offers. The
system admin feeds the system with email address, password, and admin profile, and
the system feed the admin with the profile of the system users (architect, client, and
the admin), as shown in Figure 5.6 below.
Figure 5.6: System Overview
94
In order to manage the activities and the results of the activity of the users
(architect, client, and admin) of the system, each user has his/her account. For
example, the architect first registers in order to use the system by providing his
profile. After successful registration, he/she provides email address and password to
log in to the system. The client also registers in order to use the system by providing
their profile. After successful registration, he/she provides email address and
password to log in to the system.
Again, the system admin must supply his email address and password before
he/she can access the admin account. As shown in Figure 5.7, each user must supply
his email address and password before viewing his/her account. Each user has a
unique ID associated to his email address that can be used to identify the users of the
system.
The architect can upload files to the system. They can also download client
specification files. Apart from uploading files, the architects can also search the
system to locate information for easy retrieval. By entering a client id, the architect
can view the client name and email address. He/she can also search for a design
stage document, design parameters, and files uploaded by the client simply by typing
the name of the file and pressing the search button. The architect can also change
his/her password. The client can upload design specification files, pictures etc.
He/she can make appointment, and view the status of the appointment and offers
made by the architect. The client can also change his/her password, and view a list
of building design, the design description, and the price of the description. The
system administrator can view, edit, update, and delete a user. He/she can also
change the access rights of a user from a system user to a system administrator. The
admin can add a list of building designs including the price and description of the
design for clients to see.
95
Figure 5.7: Architect, Client, and Admin Activity Management
5.6 User Registration and Login Validation
The architect needs to register by providing his profile before gaining access
into the system. The data supplied by the architect is sent to the database and stored
under user account. If the architect provides incomplete data, he/she is prompt by
the system to fill the required field. After successful registration, the architect is
96
directed to the architect login page where he/she will supply the login parameters
(email address and password). If he/she supplied the correct login parameters, the
architect login verification module retrieve the architect name from the database and
grant him/her an access to the architect account (as shown in Figure 5.8).
Architect
Register New
Architect
Architect Profile
Email Address
and Password
Login
Verified Email
Address and
Password
Users
Logged
Architect
Saved Architect
Architect Account
Figure 5.8: Architect Registration and Login Validation
The client needs to register by providing his profile before gaining access into
the system. The data supplied by the client is sent to the database and stored under
clients account. If the client provides incomplete data, he/she is prompt by the system
to fill the required field. After successful registration, the client is directed to the
client login page where he/she will supply the login parameters (email address and
password).
If he/she supplied the correct login parameters, the client login
verification module retrieve the client name from the database and grant him/her an
access to the client account (as shown in Figure 5.9).
97
Client
Register New
Client
Client Profile
Email Address
and Password
Login
Verified Email
Address and
Password
Logged Client
Clients
Saved Client
Client Account
Figure 5.9: Client Registration and Login Validation
In order to log in to the admin account, the system administrator must first of
all supply his login id (email address and password). If he/she supplied the correct
login parameters, the admin login verification module retrieve the admin name from
the database and grant him/her an access to the admin account (as shown in Figure
5.10).
98
Admin
Email Address
and Password
Login
Verified Email Address
and Password
Logged Admin
Users
Admin Account
Figure 5.10: System Admin Login Validation
5.7
Information Model Design
Based on the data flow description discussed earlier, a model of the database
implementation of the system (architectural design information management system)
was derived (as shown in Figure 5.11). The entities created are architects, admins,
clients, appointments, offers, client_specifications, designs, documents, categories,
subcategories, and urls. In order to ensure that each user has access to his individual
account and the activities associated to that particular user, users have their unique id
associated with their accounts.
For every appointment made by the client, the
architect can view the appointment with the appointment id, the client id, and the id
of the document containing the specification uploaded by the client.
99
On the other hand, the client can view offers made by the architects, with
each offer having its id and the id of the architect that made the offer. The admin can
view each user, edit or even delete the user. If the admin edit a user, the records in
the database associated with the user id will be updated. From the information model
below, each architect have a unique user_id, user_email, and user_password. This is
so with the client because, each appointment made by a client contains the client_id,
appointment id (appt_id), and appoitnment description (appt_description) associated
to the client. Again, each document has an id, a name, type, size and the date in
which the document is uploaded to the system. Every design specification a client
upload to the system has a file_id, file_name, file_type, file_size, file_content,
date_created. The architect can organize web addresses (urls) into categories and
subcategories so as to make internet access easier and simpler.
The urls are
accessible to only the architect. The information model for the system is shown in
Figure 5.11 below.
100
Figure 5.11: Information Model
5.8 Chapter Summary
As a summary, the researcher has discussed in detail the different stages in
the architectural design process with the aid of a matrix. This chapter also covers the
design process analysis using matrix partition and tearing algorithms. The data
101
model of the system was also presented in this chapter. The system overview, the
user activity management, user registration and log in validation for the different
users of the system was also discussed. The information design for the system was
also shown in the data model.
CHAPTER 6
THE ARCHITECTURAL DESIGN INFORMATION MANAGEMENT
SYSTEM
6.1
Introduction
This chapter is aimed at explaining and reporting the implementation of the
system based on the framework developed in chapter 5. The purpose of this chapter
is to explain how the prototype can manage the information associated with
architectural design. The information includes but not limited to those provided by
the client (client specification), architects design stage deliverables (business
justification documents, contract documents, procurement strategy, design brief and
concept approval, etc), design parameters, to mention but few. Before explaining the
detail prototype implementation, we will start with user specification in the next
section.
103
6.2
User Specification
The users of the system are the architect, client, and system administrator.
The architect role is to design and to also monitor the implementation of the building
design into a product (building). The client provides the architect with specification
of the building he/she has in mind. To be able to answer the problem, the architect
has a set of deliverables identified in the literature review. In order to satisfy the
client, the architect needs information from different sources. The prototype is
aimed at managing this information.
6.3
Prototype and Interface Requirement Specification
The system is implemented using client server architecture because it is easy
to deploy. It is designed to interface with three (3) different users (architect, client,
and system administrator), with each having a different access right.
The system will enable the architect to upload design documents (previous
design, design parameters, architect deliverables, contract documents, etc). Also, the
client can upload design specification, and he/she can book an appointment. The
system will also enable the architect to access the client specification. He/she can
also make an offer to the client based on the client design specification.
An
important feature in the prototype is the search module that allows the architect to
easily search and retrieve a particular record stored in the system.
The interface should provide the admin with a suitable way of managing the
system users (editing a user, adding a new user, and deleting an existing user). The
104
system should also provide the architect with a suitable interface for uploading files
to the system. It should also provide him/her with an interface to search and display
searched files. It should also enable the architect to view client specification. The
system should provide the client with a suitable interface to upload his/her design
specification, to make an appointment, and to select an offer made by the architect.
The interface should also allow the architect to store useful urls so as to make
internet search easier.
6.4
Architectural Design Information Management System
The proposed system model is based on the information system models
discussed in section 2.3 of this work.
We consider web service distributed
information system framework adapted from the work of Wu et al., (2008). A Web
services based approach is applied as the foundation in developing the architectural
design information system. This is due to the fact that, the web service based
approach makes it easy to share information and different users can access the
system in different location at a time.
The operation layer includes the data
management system, web presentation, and Information Repository.
With Web
browser and architectural design tools and temporary file storage located on the
client side, and web presentation, data management and information repository on
the server side.
Due to the large amount of information that the designers handle, the
information system model provides a search capability to the architect, where he/she
can search for specific record in the database. It also provides him/her with an
internet search capability should he/she requires more information. Web browser
component will help users to access the application using HTTP internet protocol.
The architectural design tools on the client side are software like AUTO CAD say
105
used in architectural design. The temporary storage on the client side is used for
storing designs and other files temporarily. The HTML/HTTP serves as a means of
communication between the browser on the client side and the operation layers on
the server side.
106
Figure 6.1: Model of Architectural Design Information Management System
(ADIMS)
107
6.5
Web Presentation
The Web presentation layer builds a suitable user interface.
We have
identified three different users of the system; architects, system admin, and clients.
Each of this user’s has different access rights and priviledges. In the user interface,
we have the Architect module, Admin module, Client module, and the Search
module.
6.5.1
The Architect Module
The architect module comprises of architect registration, architect registration
process, architect login, architect login process, and architect account. First, the
architect needs to register by filling the registration form before gaining access into
the system. The architect register process module comfirmed the data supplied by
the architect and send it to the database. If the architect provides wrong data, the
module prompts the architect to fill the required field. After successful registration,
the architect is directed to the architect login page where he/she will supply the login
parameters. If he/she supplied the correct login parameters, the login process module
retrieve the architect name from the database and display the name with a welcome
statement and provide him/her with a link to the architect account. If wrong email
address or password is entered, a warning message is displayed and the architect is
re-directed to the login page.
In the architect account (Figure 6.2), the user can upload previous design
files, design parameters, pictures, design stage documents, design parameters, and
other relevant files related to the system. These files will be stored in the database.
108
This is shown in Figure 6.3. After uploading the files, the architect can view the files
he/she uploaded to the system (as shown in Figure 6.4).
Figure 6.2: The Architect Account
109
Figure 6.3: The Architect File Upload Page
Figure 6.4: List of Files Uploaded the Architect
110
While in his account, the architect can search for a picture, design stage
documents, client specification, and other records in the system (as shown in Figure
6.5). The file corresponding to the architect search is displayed (as shown in Figure
6.6). The architect can also search for a client by entering the client id and pressing
on the search button, to retrieve the client names and email address (as shown in
Figure 6.7).
Figure 6.5: Design Document Search
111
Figure 6.6: Architects Document Search Results
Figure 6.7: Architects Client Search Results
112
The architect can view client specification and make offer to the client. The
clients will then select the architect offer corresponding to his appointment for
negotiation (as shown in Figure 6.8). The architect can also change his/her password
from time to time (as shown in shown in Figure 6.9).
Figure 6.8: View Client Specification/Make Offer Page
113
Figure 6.9: Change Password Page
In the architect account, there is a link to a URL directory to assist the
architect to add and organize (into categories and sub categories) important addresses
of websites that will assist him/her with information regarding architectural designs.
This is shown in Figures 6.10, 6.11, 6.12 below.
114
Figure 6.10: URL Subcategories Page
Figure 6.11: View URLs Page
115
Figure 6.12: Add Category, Subcategory, and URL Page
6.5.2
The Client Module
The client module comprises of client registration, client registration process,
client login, client login process, and the client account. Just like the architect, the
client needs to register first by filling the registration form before gaining access into
the system. The client register process module comfirmed the data supplied by the
client and send it to the database. If the client provides wrong data, the module
prompts him/her to fill the required field. After successful registration, the client is
directed to the client login page where he/she will supply the login parameters. If
116
he/she supplied the correct login parameters, the login process module retrieve the
client name from the database and display the name with a welcome statement and
provide him/her with a link to the client account.
If wrong email address or
password is entered, a warning message is displayed and the user is re-directed to the
login page.
In his/her account, the client can upload design specification for the architects
to view and download. The file upload page for the client is similar to that of the
architect (Figure 6.3 above). After uploading the design specification, the clients
will then make an appointment (as shown in Figure 6.13). Based on the client design
specificications, the architect responds to the specification with an offer. The client
selects the offer and confirms his appointment.
The client can also cancel
appointment (as shown in Figure 6.14). Just like the architect, the client can also
change his password. He/she can also view a list of design with their description and
price (as shown in Figure 6.15).
Figure 6.13: Make Appointment Page
117
Figure 6.14: Select Offer and Confirm Appointment Page
Figure 6.15: View Design Description Page
118
6.5.3
The Admin Module
The system administrator is responsible for managing the system. The admin
can view all the users (architects and clients) of the system. He can edit, update and
delete users. The admin can also change user’s access rights from a user to an
administrator. The admin module comprises of admin login, and admin account.
The admin first provide his/her login parameters (email address and password). If
he/she supplied the correct login parameters, the login process module retrieve the
admin name from the database and display the name with a welcome statement and
provide him/her with a link to the admin account (as shown in Figure 6.16). If
wrong email address or password is entered, a warning message is displayed and the
user is re-directed to the login page.
In the admin account, the admin can view the users of the system (architect,
admin, and the client). He/she can change the user access rights, delete a user, and
add a new user. Only the system administrator can change the access rights of a user
from say an ordinary user to system admin. He/she can add a list of building designs
including the price and description of the design for clients to see. He can also delete
existing description. The activities that the admin performs are shown in the figures
below.
119
Figure 6.16: Admin Account
Figure 6.17: View System Users Page
120
Figure 6.18: Add New Design Description Page
6.5.4
Search Module
The search module assist the architect to search for records stored in the
system. There are two types of search namely, simple search and advanced search.
Using the simple search, the architect can search for a file in the client design
specification storage by simply entering the name of the file and clicking the search
button, the search results will be displayed. He/she can also search for records stored
in the design document storage in a similar way. With the aid of the searh module,
the architect can find and locate a client by entering the client id and submiting the
search. The results of the different instances of simple search were shown in Figures
6.5, 6.6, 6.7, and 6.8.
121
Using the advanced search option, the architect can control his/her search by
refining the search to include only the file name, or date created or both. The
snapshort of the advance search options is shown in Figure 6.19.
Figure 6.19: Advanced Search
6.6
Data Management Service Logic
The Data management (service logic) is the system operation module that
decides how to respond to different system scenarios based on retrieved
data/information. In the data management, the user can add/update records, he/she
can search specific records in the database, and he/can can retrieve existing records
in the repository. The data management module consists of Design Information
editor. The usage of this module is to add new record (insert new record), edit
122
existing records, search/retrieve specific records, delete record, and provides
connections between access rights and the database components
6.7
Information Repository
Information repository is the information storage component of the
architectural design information system, consisting of previous design, design history
storage, design experience records and files memory storage, design parameter: text
data storage (eg. urls), design experience record management, and architectural
design stages deliverables storage (documents like: Business justification,
procurement strategy, design brief and concept approval, detailed design approval,
investment decision, readiness for service documents, and benefits evaluation
documents).
The database for the system was implemented using MYSQL. The table
schema diagram associated to the implementation of the system database is shown in
Figure 6.20 below. In the database, the profiles of the architects are stored in a table
named users, and system administrators are stored in a table called admins. The
client profile is stored on a table called clients. There is also a table that stored the
files uploaded by the architects (design_documents). Another table is used to store
the files uploaded by the client (client_specifications). The admin can store design
names, price, and descriptions of the design in a table named designs which can be
viewed by the clients (as shown in Figure 6.20). Three other tables (categories,
subcategories, and urls) will assist the architect to store and manage useful websites
addresses so as to make internet search easier. The architect can view urls based on
categories and subcategories (as shown in Figure 6.20 below).
123
Figure 6.20: Database Implementation of ADIMS
6.8
Software Quality and Testing
The purpose of software quality is to provide a highly qualitative software.
The quality of a software is measured via a set of the following attributes:

Portability: the ability of the software to be transferred easily from one
computer or pc to another.
124

Efficiency: the ability of the software to perform with a very minimum
use of computer resources.

Usability: the ability of the software to be easily understood and used by
human users with little or no difficulties.

Testability: the ability of the software to be easily verified by executing
it.

Understandability: the ability of the software to be read during software
maintainance.

Modifiability: the ability of the software to be revised during software
maintainance.
In the system testing we shall consider three types of tests namely user
interface testing, use-case testing, and documentation testing.
6.8.1
User Interface Testing
During the User Interface Testing, the researcher assessed the interface by
focusing on four elements namely; screen layout, report, form and also menu (user
activities) in the system.
a) Screen Layout
Based on interface testing for screen layout, researcher tests and check each
screen layout to ensure that a uniform standard is followed. Figure 6.21
below shows an example of the system user interface.
125
Figure 6.21: System Interface
Test Report
As a result, each page in system follows the standard where researcher finds
out that:
Table 6.1: Screen Layout Testing
Layout
Standard
Screen

Display a banner at top of every P
single page

P
The menu display on the top pane of
every single page

Result P/F
Copyright display at the bottom of
every single page.
P
126
b) Report Layout
Based on user interface testing for Report layout, researcher test and check
each report layout is following the standard as mentioned in the previous
section.
Test Report
As a result, the researcher find out that all the layout in the system follows the
standard as shown in Table 6.2 below.
Table 6.2: Report Layout Testing
Layout
Standard
Result
P/F
Report

At the top of the report page, a header P
displays the ADIMS System logo.

The information is displayed in form of a P
table at the center of page
c) Form Layout
Based on the interface testing for Form layout, researcher test and check each
form layout to ensure that the standard as mentioned in the previous section is
followed. The figure below shows a part of the interface of the system.
127
Test Report
From the test report, all the forms follow the standards as shown in Table 6.3
below.
Table 6.3: Form Layout Testing
Layout
Standard
Result
P/F
Forms

Create a form that allows a user to fill by:
a. The use of text field: allow the user to P
enter the information

Create Search form that allows user to
search by using:
a. Drop down menu to select search P
option
b. Use text field to enter search term
P
d) Menu
Based on the architect page (as shown if Figure 6.2), researcher assess an
integration testing by testing the functionality of architect activities in order
to ensure each menu function properly and brings the user to correct page or
link. Basically, the testing conducted shows that each menu provides link to
the correct page. The result of testing is shown in Table 6.4 below;
128
Table 6.4: Menu Testing
Menu
Link/Page
Result
P/F
6.8.2
Upload files
Shows the file upload page
P
Download files
Shows the documents uploaded to system
P
Document search
Shows the simple search page
P
Edit profile
Shows the change password page
P
Download client
Shows the client specification documents
P
specifications
page
Make an offer
Shows the architects offer page
P
Advance search
Shows the advance search page
P
Internet search
Provides a link to the internet search page
P
Logout
Shows the logout page
P
Use-Case Testing
The Use-Case of ADIMS and the detail description of the use case are shown
in Appendix D.
129
Table 6.5: Use-case testing for Architect Page
a)
Test Plan
Tester: Aliyu
Page 1 of 3
Version Number : 1
Use Case ID
:1
(Architect)
Date Designed :
Date Conducted :
10/01/2010
11/01/2010
Class Objective:

Log into the system in order to allow architect to upload files, download
files, edit profile, search documents, search clients, view client
specifications, and make offer.
Associated Contract IDs:
Associated Use Case IDs:
Associated Superclass(s):
Testing Objectives:

To ensure that architect log into the system without any error
Walkthrough Test Requirements:
Invariant-Based Test Requirements:
State-Based Test Requirements:
Contract-Based Test Requirements’:
Test Report
The result of the test which aims at ensuring that architect log into the system
shows that the architect is able to log into the system without any error.
130
b)
Test Plan
Page 2 of 3
Version Number : 1
Use Case ID
:3
(Architect)
Tester : Aliyu
Date Designed :
Date Conducted :
10/01/2010
11/01/2010
Class Objective:

Upload design stage documents in the file upload page
Associated Contract IDs:
Associated Use Case IDs:
Associated Superclass(s):
Testing Objectives:

To ensure architect can upload information to the system

To guarantee that any file uploaded by the architect is saved in the
database
Walkthrough Test Requirements:
Invariant-Based Test Requirements:
State-Based Test Requirements:
Contract-Based Test Requirements’:
Test Report
During this testing, all the testing objectives were achieved where architect
was able to upload his/her files to the system successfully and saved in the
system.
131
c)
Test Plan
Page 3 of 3
Version Number : 1
Use Case ID
:3
(Architect)
Tester : Aliyu
Date Designed :
Date Conducted :
10/01/2010
11/01/2010
Class Objective:

Allow user to logout from the system
Associated Contract IDs:
Associated Use Case IDs:
Associated Super class(s):
Testing Objectives:

To ensure that the logout task can be done properly for security purpose.
Walkthrough Test Requirements:
Invariant-Based Test Requirements:
State-Based Test Requirements:
Contract-Based Test Requirements’:
Test Report
The result of the logout testing shows that each user can successfully log out
from the system by pressing the logout button. This ensures that any update
or changes made by the user can be saved properly. It also ensures that
unauthorized users from making changes.
132
6.8.3
Documentation Testing
An online user manual documentation was provided so that system users can
download it at any time should they encounter any difficulty. The online user
manual is to provide each of the users to connect with the system. The user manual
is to guide the users on how to use the system. Hence, this documentation testing is
needed to test the accuracy of the documentation that has been made.
Test Plan
Below is the test plan for the documentation testing to be conducted.
Documentation testing that will be done by the researcher:

The researcher will check items item on every page in all documentation to
ensure that the documentation items and examples work properly.

Documentation testing that will be done by users:
o Choose one or two users that do not have knowledge about this
ADIMS system.
o Brief them about the system.
o Ask them to register in ADIMS system by reading the instruction of
the system in the user manual.
o Find out if they understand the instructions in the user manual or not.
o Leave them to complete the registration themselves.
o After completing the registration, ask them the difficulties about using
the system based on the user manual.
Test Report
From the documentation testing carried out we derive the following
conclusion. The testing carried out by the researcher indicates that the user
manual satisfies the need of the researcher and it works with full success.
133
But, this cannot be counted as a satisfying and good testing because the
researcher is not an end user of the system. As such, the second testing had
been done by an architect who knew only the basic of the system but does not
know how it operates.
From the result, the architect can access all the
information that he needs to know and successfully used the system with no
much difficulties.
6.9
Chapter Summary
The researcher adopted the concept of web service based framework in the
development of the Architectural Design Information Management System
(ADIMS). The system is designed to interface between architect, client, and the
system administrator (admin) so that there will be an effective management of
architectural design information. The user specification, prototype and interface
requirement specification of the ADIMS are discussed in this chapter. The model
and prototype implementation of the ADIMS was also discussed. Three types of
tests namely user interface testing, use-case testing, and documentation testing were
also discussed.
CHAPTER 7
DISCUSSION AND CONCLUSION
7.1
Introduction
This chapter is the last chapter of the study; it includes discussions based on
the findings and conclusions. Based on the findings of the study discussion of the
achievements, the challenges, and aspirations are hereby presented.
7.2
Achievements
After a comprehensive review on; how architects come up with the building
design, the flow of information in the architectural design process, the design
information sources and types, and the tools used by architects to store design
135
Information, a detailed flow of information in archtectural design process has been
identified. The different archtects deliverables have also been explored.
Based on the findings from the observation/discussion, design process
analysis (partitioning and tearing), and literature review, we observed that,
developing a framework for design information management system requires a
detailed understanding of architectural design process and the set of deliverables for
each stage.
From the outcome of the data analysis, the combination of the
understanding of the two registered professionals provided a design structure matrix
that depicts the flow of information within the RIBA work stages. A partition
algorithm was used to provide an optimum sequence of activities in the architectural
design process. It also assisted in identifying couplings in the design process. The
matrix partitioning process was based on the defined interrelationships between
activities in the design process (as shown in Figure 5.1 of section 5.2).
The combined design structure matrix (DSM) of the RIBA work stages
contains 61 entries (interaction points or information flows). The partitioned DSM
indicates that, decisions at RIBA work stages involve couplings. This implies that
the process of coming up with a building design may take longer than planned due to
the iterations of the different design activities. More so, decisions on some activities
may affect a large number of activities in building design. The changes in those
‘critical’ activities are more likely to cause larger iteration cycles thereby delaying
the project. One critical activity identified is design development because it provides
13 out of 14 tasks with input. This design activity was identified by observation of
the matrices. The tearing also suggests an alternative way of rescheduling the design
activities so as to minimize couplings.
Some activities create constraints for other activities. This means that, they
limit on choices for other activities. It is also observed that the architectural design
process is prone to iterations. Decisions made at certain stages (early stages) may
136
affect later stages which results in iterations in the entire process. The DSM will
assist in making optimum decision because it makes information flow explicits.
All the objectives highlighted in the introductory chapter of this work have
been achieved. The framework of architectural design information system and the
design information system model was also developed. Finally, a prototype was also
developed as a proof of concept.
7.3
Challenges, Constraints and Limitations
One major challenge of the proposed DSM approach is the large number of
activities that need to be carried out in the design process. Again, choosing the
appropriate tool for developing a framework for architectural design information
system framework was a great challenge. More so, developing the activity system
for design information management system is quite challenging.
One major
constraint in conducting this research is time.
Despites the capabilities of the prototype implementation, there are some
limitations. The architect may have one to three projects at a time and each project
may have documents associated to it. One of the limitations of the prototype is that it
has not classified the design documents based on projects. Future research should
focus on assisting the architect to classify documents based on projects for easy
retrieval. Again, only the information in the early phases (appraisal, design brief,
concept, design development, and technical design) of architectural design process is
to be stored in the system.
137
7.4
Aspirations
Despites the constraints and challenges faced in conducting this research, a
DSM of the detail flow of information in architectural design process was developed.
The framework of design information management system for architects was also
developed. A prototype was also developed as a proof of concept. In summary, all
the objectives highlighted in the project overview have been achieved.
The
achievements and challenges faced while conducting the research have been
explained in the sections above.
7.5
Chapter Summary
This research has proposed a DSM as a process modelling tool for
architectural design process. It also shows that the matrix maps out the activities in
the design process. Furthermore, the DSM identifies the iterative cycles, critical
activities, and made assumptions on how to reschedule the design activities. Though
the DSM makes iterations explicit, it is very difficult to develop initially.
The framework for architectural design information system developed and the
prototype implementation will assist architects with an alternative way of better
handling architectural design information without keeping it in their mind. The
concepts of Web services based framework was applied in the development of the
Architectural Design Information Management System (ADIMS) prototype. The
system is designed to interface between architect, client, and the system
administrator (admin) so that there will be an effective management of architectural
design information.
REFERENCES
Adair, D. (1995). Building Object-Oriented Framework. AIXpert. February.
Agile PLM Platform. Source: http://www.agile.com
Akin O. (2002). Case based Instruction Strategies in Architecture Design. Design
Studies, Vol 23 pp 407-432.
Akin, O., Ipek, O. (2006). Requirement-driven Design: Assistance for Information
traceability in Design Computing. Design Studies 27, 2006, 381-398.
Andrew Treloar. The Monash University Information Management Strategy: From
Development to Implementation Journal of Knowledge Management Prentice,
2006.
Arthur Thompson (1999). Architectural design procedures. 2nd edition, London,
Architectural Press.
Barbara Mc. Nurlin, Ralph H. Sprague, and JR. Tung Bui (2009). Information
Systems Management in Practice, eight edition, Pearson International edition.
Chun, W. W. (1995). Information Management for the Intelligent Organization:
Roles and Implications for the Information Professionals. Digital Libraries
Conference, Singapore.
Dace A. Campbell, and Maxwell Wells. A Critique of Virtual Reality in the
Architectural Design Process. Source:
http://www.hitl.washington.edu/publications/r-94-3/.
Data Center Definitions (2007). Information Management System (IMS).
SearchDataCenter.com Definitions.
Davenport, T.H., and Prusak, L. (1998). Working Knowledge: How Organizations
Manage What They Know. Boston, MA: Harvard Business School Press.
139
David A. G., and Steven D. E. (1991). Methods for Analyzing Design Procedures.
Design Theory and Methodology, Vol 31, American Society of Mechanical
Engineers, New York, N.Y. 10017.
Dick Stenmark (2002). Information vs. Knowledge: The role of intranets in
Knowledge Management. Hawaii International Conference on System Science.
Donal J. Flynn, Olivia Fragoso Diaz (1999). Information Modelling: An International
Perspective. Prentice Hall, Europe.
Eppinger SD, Witney DE, Smith RP, Gebala DA (1994). A model-based method for
organizing tasks in product development. Research in Engineering Design 6:1-13
E2open Software. Source: http://www.e2open.com.
Engeström, Y. (1999). Expansive visibilization of work: an activity-theoretical
perspective. Computer Supported Cooperative Work (CSCW), 8(1-2), 63-93.
Hicks B.J., S.J. Culley, R.D., and Allen, G. Mullineaux (2002). A Framework for the
Requirements of Capturing Information and Knowledge in Engineering Design,
PERGAMON International Journal of Information Management.
Ipek Ozkaya, and Omar Akin (2006). Requirement-driven Design: Assistance for
Information traceability in Design Computing. Design Studies 27, 381-398,
Elsevier Ltd.
Jambak M.I., Verlinden J.C., Vergeest J.S.M., and Smith (2005). Context
Visualization in Web-based design information retrieval system. Delft University
of Technology, Netherlands.
James Robertson (2005). 10 Principles of Effective Information Management. Step
Two Designs Pty Ltd.
James T. McClave, and Terry Sincich (2000). Statistics. Eight edition, Prentice Hall,
Upper Saddle River New Jersey.
Kaufer, D. S., Carley, K. M. (2003). Communication at a Distance: the influence of
print on sociocultural organization and change. Lawrence Erlbaum Associates,
Hillsdale, New Jersey.
Kuutti, K. (1996). Activity theory as a potential framework for human-computer
interaction research. In B. Nardi (Ed.), Context and consciousness: activity
theory and human-computer interaction. (pp. 17-44). Cambridge, MA: MIT
press.
140
Leont'ev A.N. (1978). Activity, consciousness and personality. Englewood Cliffs,
NJ: Prentice-Hall.
Leont'ev A.N. (1981). Problems of the development of mind. Moscow: Progress.
Lorna U., Pedro V., and Oscar P. (2008). An Activity-Theory-Based Model to
Analyze Web Application Requirements. IR Information Research, vol. 13 No2.
Moises Daniel Diaz Toledano. The Architecture of Enterprice Information Systems:
A View Based on Patterns. Source: www.moisesdaniel.com
Oliver Tamine, and Rudiger Dillmann (2003). KaViDo – A Web-Based System for
Collaborative Research and Development Process.
Elsevier, Computers in
Industry 52(2003)29–45.
Roy U., and Kodkani S.S. (1999). Product Modeling Within the Framework of the
World Wide Web. IIE Transactions, 31(7), pp. 667–677.
Simon Szykman (2002). Architecture and Implementation of a Design Repository
System. Design Engineering Technical Conferences and Computers and
Information in Engineering Conference, Montreal, Canada.
Sule Tash Pektas and Mustafa Pultar (2005). Modelling Detailed Information Flows
in Building Design with the Parameter – Based Design Structure Matrix. Design
Studies, 27, pp.91–122.
Tamine, O., and Dillmann R. (2003). KaViDo: a Web-based system for collaborative
research and development processes. Computers in Industry, 52, pp.29–45.
Tanenbaum A. S., and Steen, M. (2002). Distributed Systems - Principles and
Paradigms. Upper Saddle River, NJ, Prentice Hall, pp.50-52.
Teresa W., Nan X., and Jennifer B. (2004). Design and Implementation of
Distributed Information System for Collaborative Product Development.
The Riba Outline Plan of Work (2007). Publication of National Joint Consultative
Council of Architects, Quantity Surveyors and Builders.
Tuomi, I. (1999). Data is More Than Knowledge: Implications of the Reversed
Knowledge Hierarchy for Knowledge Management and Organizational Memory,
Journal of Management Information Systems, Vol. 16, No.3, pp. 107-121.
Wanga Y. D., Shena W., and Ghenniwab H. (2003). WebBlow: a Web/agent-based
multidisciplinary design optimization environment. Computers in Industry, 52,
pp. 17–28.
141
Xu X. W., and Liu T. (2003). A Web-Enabled PDM System in a Collaborative
Design Environment. Robotics and Computer Integrated Manufacturing, 19,
pp.315–328
Formoso, C T , Tzotzopoulos, P, Jobim, M S S and Liedtke, R (1998). Developing a
Protocol for Managing the Design Process in the Building Industry. International
Group for Lean Construction, Sixth Annual Conference, Source:
http://www.ce.berkeley.edu/wtommelein.
Young-kyunglin, and Keiichi S. (2001). Development of Design Information
Framework for Interractive Systems Design. Proceedings of the 5th Asian
International Symposium on Design Science, Seoul, Korea
Zachman J. A.
(1999). A Framework for Information System Architecture.
International Journal IBM Systems Journal, Vol38, NOS 2&3.
Zainal, Z. (2007). Case Study as a Research Method. Universiti Teknologi Malaysia.
J. D. Wiest and F. K. Levy (1997). A Management Guide to PERT/CPM. PrenticeHall, Englewood Cliffs, New Jersey, 2nd Edition.
D. A. Marca and C. L. McGowan (1988). SADT: Structured Analysis and Design
Technique. McGraw Hill, New York.
142
Appendix A:
Project Schedule
143
144
145
146
147
148
149
Appendix B:
Design Structure Matrix
150
Design Structure Matrix
Dear respondent,
I am doing my master’s thesis in IT Management under FSKSM, Universiti
Teknologi Malaysia (UTM).
The purpose of this matrix is to understand the flow of information within the
different stages of architectural design.
How to fill the Matrix:
A sample of the matrix is given in page 2 to assist you in filling the matrix.
All information you provide will be confidential; secret and can be used only for this
research purpose.
Thanks for your participation and collaboration to the study.
Supervisors:
Dr. Muhammad Ikhwan Jambak
Department of Modelling and Industrial
Computing
Faculty of Computer Science and Information
Systems
81310 UTM Skudai, Johor, Malaysia
E-mail: mohdikhwan@utm.my
PM Dr Naomie Bte Salim
Department of Information Systems
Faculty of Computer Science and Information Systems
81310 UTM Skudai, Johor, Malaysia
Email:naomie@utm.my
Aliyu Muhammad Alhassan
Master Student
Faculty of Computer Science
and Information Systems,
81310 UTM Skudai, Johor,
Malaysia
Tel: +6012 –7652349
Email: alyalhas@gmail.com
151
A design activity composed of n task would be represented as an nxn matrix, with
task labels placed downside of the matrix as row headings and across the top as
column headings in the same order.
Sample: The flow of information in Architectural design stages
From the sample above, task A (Appraisal) does not require information from
any task. This is dipicted by an empty row correspondinding to the task. Design Brief
(task B) requires input from Appraisal; Concept (task C) requires input from Design
Brief (task B). On the other hand, Design Development (task D) requires information
from task C, while Technical Design (task E) requires information from Design
Development. Tasks F1 (Preparation of Production Information) did not require input
from any task, and F2 (Preparation of Production Information for Further
Construction) requires input from Mobilization (task J).
152
153
Appendix C:
RIBA Outline Plan of Work 2007
154
155
Appendix D:
Use Case for ADIMS
156
<<extends>>
<<extends>>
Download files
Download client specifications
<<extends>>
View files
<<extends>>
Search Client
<<extends>>
Search
Download Documents
<<extends>>
Search Client specifications
Architect
Documents
User Registeration
View Appointment
<<extends>>
Make Offer
<<extends>>
Add/Delete User
Login/logout
View/edit Profile
Admin
Make Appointment
Client
View Design Description
<<extends
View Offer
Confirm Appointment
Add Design Description
157
Use Case Description for Login
Use case name: Login
ID: 1
Importance level: High
Primary actor: users
Use case type: Detail, essential
Stakeholders and interests: Admin – want to view users, add or delete a user.
Architect – wants to upload documents, update profile
or view client specifications.
Client – wants to view make appointment, confirm
appointment, and upload design specification.
Brief description: This use case allows users to log in to the ADIMS system.
Trigger: users need to log into the system
Type: External
Relationships:
Association: none
Include: none
Extend: none
Generalization: none
Normal flow of events:
1. User enters his/her email address
2. User enters his/her password.
Sub flows: 1.1 if email address is invalid, re enter email address
2.1 if password invalid, retype the password
Alternate/exceptional flows: none
158
Use Case for Adding New User
Use case name: Add/Edit user
ID: 2
Importance level: High
Primary actor: Admin
Use case type: Detail, essential
Stakeholders and interests: Admin – want to add a new user or edit existing user.
Brief description: This use case allows Admin to add a new architect and client to
the ADIMS system and to edit existing user’s info.
Trigger: Admin need to add new user to the system and edit an existing user.
Type: External
Relationships:
Association: none
Include: none
Extend: none
Generalization: none
Normal flow of events:
1. Admin login to the system
2. Maintain user data.
3. Save the user data
Sub flows:1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case for Upload Files
Use case name: Upload Files
ID: 3
Importance level: High
Primary actor: Architect andClient
Use case type: Detail, essential
Stakeholders and interests: Architect – wants to upload his/her design documents
Client – wants to upload his/her design specification
Brief description: This use case allows architects and clients to upload their files
into the ADIMS system.
Trigger: Architects and Clients need to upload their file into the system
159
Type: External
Relationships:
Association: none
Include: none
Extend: none
Generalization: none
Normal flow of events:
1. Architect/Client login to the system
2. Architect/Client goes to the file upload page.
3. Architect/Client Upload file
4. Save the document uploaded.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case for Edit Profile
Use case name: Edit Profile
ID: 4
Importance level: High
Primary actor: Architect and Client
Use case type: Detail, essential
Stakeholders and interests: Architect – want to update his/her profile
Client – wants to update his/her profile
Brief description: This use case allows architects and clients to update their
profile
Trigger: Architects and Clients need to update their profile in the system
Type: External
Relationships:
Association: none
Include: User profile
Extend: none
Generalization: none
Normal flow of events:
160
1. Architect/Client login to the system.
2. Architect/Client goes to profile page.
3. Architect/Client edits profile.
4. Save the user profile.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case Description for Search Files
Use case name: Search files
ID: 5
Importance level: High
Primary actor: Architect
Use case type: Detail, essential
Stakeholders and interests: Architect – want to search for a file
Brief description: This use case allows architects to search for a design stage
documents or client specification files.
Trigger: Architects need to search for a file in the system
Type: External
Relationships:
Association: none
Include: none
Extend: none
Generalization: none
Normal flow of events:
1. Architect login to the system.
2. Architect goes to the search page.
3. Architect search for a file.
4. Architect locates a file.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
161
Use Case Description for Make Appointment
Use case name: Make Appointment
ID: 6
Importance level:
High
Primary actor: Client
Use case type: Detail, essential
Stakeholders and interests: Client – want to make an appointment
Brief description: This use case allows clients to make appointment.
Trigger: Client need to make an appointment
Type: External
Relationships:
Association: none
Include: none
Extend: none
Generalization: none
Normal flow of events:
1. Client login to the system.
2. Client goes to the make appointment page.
3. Client makes appointment.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case Description for View Appointment
Use case name: View Appointment
ID: 7
Importance level: High
Primary actor: Architect
Use case type: Detail, essential
Stakeholders and interests: Architect – want to make an offer to client
Brief description: This use case allows architects to view client appointment
and make an offer.
Trigger: Architects need to view client appointment in the system or make an
162
offer to client.
Type: External
Relationships:
Association: none
Include: none
Extend: Make Offer
Generalization: none
Normal flow of events:
1. Architect login to the system.
2. Architect goes to the view appointment page.
3. Architect view appointment and make offer.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case Description for View Offer
Use case name: View Offer
ID: 8
Importance level: High
Primary actor: Client
Use case type: Detail, essential
Stakeholders and interests: Client – want to make and confirm or cancel
appointment.
Brief description: This use case allows clients to view; select architects offer
and confirm appointment.
Trigger: Client need to view offers in the system, and confirm or cancel
appointment
Type: External
Relationships:
Association: none
Include: none
Extend: Make Offer
Generalization: none
163
Normal flow of events:
1. Client login to the system.
2. Client goes to the view offer page.
3. Client selects offer and confirm appointment.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
Use Case Description for Download files
Use case name: Download files
ID: 9
Importance level: High
Primary actor: Architect
Use case type: Detail, essential
Stakeholders and interests: Architect – want to download a file
Brief description: This use case allows architects to download a design stage
documents or client specification files.
Trigger: Architects need to download a file in the system
Type: External
Relationships:
Association: none
Include: none
Extend: Download Documents, Download Client Specifications
Generalization: none
Normal flow of events:
1. Architect login to the system.
2. Architect goes to the download page.
3. Architect selects a file.
4. Architect downloads a file.
Sub flows: 1.1 If invalid email address and password is entered, re login
Alternate/exceptional flows: none
164
Appendix E:
FAB Organizational Chart
165
166
Appendix F:
MATLAB Printout
167
168