Professional Documents
Culture Documents
Communicational aspects of
Project Management using
web-based technologies:
Implementing an email-based
communication environment
carried out at the
Information & Software Engineering Group
Technical University of Vienna
under the guidance of
Ao.Univ.Prof. Dipl.Ing. Dr.techn. Andreas Rauber
and
Dipl.Ing. Dr.techn. Alexander Schatten
as the contributing advisor responsible
by
Robert Neureiter, Bakk. techn.
Molkereistrasse 3/7, 1020 Vienna
Matr.Nr. 9925047
Vienna, 10.08.2005
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die
den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.
Wien, 10.08.2005
Acknowledgements
I would like to thank my parents Marianne and Bernhard, my brother Martin and
all my relatives for their support at every point in my life. My study would not
have been possible without their encouragement.
Last but not least I would like to point out the valuable guidance of Dr. Alexander
Schatten during the completion of this master thesis.
i
Abstract
Zusammenfassung
ii
Contents
Eidesstattliche Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . i
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
2 Communicational aspects 8
2.1 Project related communication . . . . . . . . . . . . . . . . . . . 8
2.2 Computer supported communication . . . . . . . . . . . . . . . . 9
iii
3.4.1 Meetings, telephone- and video-conferences . . . . . . . . 14
3.4.2 Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3 Workshops . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4 Discussion forums . . . . . . . . . . . . . . . . . . . . . 16
3.4.5 Chats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Emails 16
4.1 General information about emails . . . . . . . . . . . . . . . . . 16
4.2 Advantages of emails . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Individual perception of email . . . . . . . . . . . . . . . . . . . 19
4.3.1 Impact to social interactions by email communication . . . 19
4.3.2 Influence on individual level . . . . . . . . . . . . . . . . 21
4.3.3 Influence on organisational level . . . . . . . . . . . . . . 22
iv
6.5.2 Load balancer . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.3 Web server . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5.4 Application server . . . . . . . . . . . . . . . . . . . . . 39
6.5.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6 An example of a web project: Webmail . . . . . . . . . . . . . . 40
6.7 Web usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.2 Categorisation of usability problems . . . . . . . . . . . . 42
6.7.3 Usability evaluation . . . . . . . . . . . . . . . . . . . . 43
v
References 84
List of Figures 90
List of Tables 91
Index 92
vi
1 Introduction - Project Management
1.1 Introduction
This master thesis describes important project management tasks, especially the
role of communication within a project. An efficient and functional communi-
cation infrastructure is indispensable for project team members which includes
project reporting, project documentation and more direct communication chan-
nels. Several communication channels and their utilization are mentioned. In
particular, emails and their utilisation in project management for project commu-
nication and as a key element for building a knowledge base are analysed.
Moreover, advantages and disadvantages of distributed projects and important as-
pects of collaboration between project team members are illustrated. To improve
project management, groupware systems have to be used, important classification
aspects and usefulness of such applications are mentioned.
Another part of this thesis goes into web-based software development. Such ap-
plications have partially other requirements than ’conventional’ software applica-
tions and need adapted approaches in development. Characteristics, success and
expense factors and the architecture of web projects are described. An additional
chapter deals with web usability, since websites often miss efficient navigation,
user feedback or other usability factors. Especially at complex process operations
it is difficult to provide an easy usable workflow in websites.
The last chapter illustrates the implementation of the email based communica-
tion extension of the open source OSWP-portal [OSW05]. The extension in-
cludes a webmail-client and its integration into the project management portfolio
of OSWP. Project related communication and its archival storage was realised.
All needed components, technologies and protocol are described like Simple Mail
Transfer Protocol (SMTP), Post Office Protocol (POP), the JavaMail-API and oth-
ers.
1
These individual tasks generally cannot be accomplished routinely in conventional
hierarchical line organisations. The organisation structures are changing from be-
ing function-oriented and fixed to be flexible and project team oriented. Nowa-
days, realisation of projects demands presents more and more a holistic approach
to optimize problem solving. Competitive conditions are getting more challenging
than ever and most tasks are characterised with growing complexity and extended
interdisciplinary aspects. For example, new products have to be developed in
project durations which are getting shorter and shorter, whereas market require-
ments and development costs are increasing.
Project management includes organisational, methodical and interpersonal meth-
ods to improve, ease and control achievement of the defined project goals. These
methods also allow to keep the costs and effort low which have to be invested,
although many persons may be integrated in the project. Project management
provides a nominal/actual value comparison and therefore allows to intervene in
good time if problems arise. Existing risks should be detected early so that it is
possible to counteract with according measures in time. To get the success factors
like money, time, resources and quality under control and to harmonise them is
the main focus of project management [Hee93].
2
1.3.1 Time saving
By structured planning of the tasks, time can be utilised more efficiently. For
example, if all tasks are assigned in detail to the project team members at the
beginning, there is not much coordination effort needed afterwards and no tasks
are carried out twice. In addition, good project management makes team members
a part of the project. Each member feels responsible for project success which
leads to efficient time utilisation.
1.3.4 Standardisation
Workflows, terms, forms, documentation, protocols, etc. can be handled more
efficiently due to standardisation by project management methods. With each
project, these tasks are getting more and more routinely [Did04, Klö99].
3
Usually, the emerging costs of introducing systematic project management meth-
ods are overcompensated by ulterior cost reduction and accelerated project reali-
sation [Ibi04].
1.4.1 Planning
In general, planning is directed into the future preparing decisions and actions.
Thinking ahead and gathering information about the future is an important part of
4
planning. If defaulted, in the middle of the project has to be extemporized leading
to uncertainty whether the project ends with success or failure.
• Project strategy
• Project definition
• Risk analysis
• Task structuring
• Quality planning
• Time scheduling
• Resource planning
• Cost planning
• Budgetary accounting
1.4.2 Controlling
Unlike planning, controlling always takes place in the present and relies on cog-
nitions of the past. Controlling ensures that all tasks are accomplished as planned
and adequate countermeasures are established if any disruption occurs.
5
1.4.3 Team leadership
Working in teams brings some advantages such as increased creativity, productive
competition and accelerated information spreading. Although teams have to be
created, guided and decisions have to be made.
6
1.5.1 Common problems
Frequently experienced problems regarding project information are:
• The involved project team members talk at cross-purposes, e.g. they inter-
pret same terms differently.
• The project manager or other team members are making decisions without
coordinating or informing the regarding persons.
• As a result of insufficient information about project status, project strategy,
etc. the team members are unsettled or even define their own goals.
• All team members get every project report and are overwhelmed by the vast
amount of information. Thus, relevant details for the individual are difficult
to examine.
7
2 Communicational aspects
2.1 Project related communication
To identify the meaning of communication we have to understand what communi-
cation is and what it is not. Communication as a general rule is interpreted only as
transmission of information, but that is definitely wrong. Communication is rather
a combination of sending information by the sender and receiving and understand-
ing this information by the recipient. As long as the recipient does not understand
the transferred data, communication has not been established. The project team
members, especially the project manager need the ability to communicate. To be
efficient, you have to put yourself in the position of the communication partner.
For example, it is not possible to explain complex technical concepts to someone
who does not possess the according technical knowledge. The message has to be
translated in a language that this person understands, otherwise you are not com-
municating but only giving a bad lecture.
8
within the project team.
The communication network in a project team should satisfy the following tasks
[Klö99]:
Mutual assistance and help Many developments of project teams can be reused
in others. Something that is difficult to accomplish in one team, may be no prob-
lem for another one. If the needs of the project are communicated properly with
the available knowledge resources, the project will benefit.
9
interpersonal relationships and the manner how people communicate with each
other. For example, the dependence on personal relationships is getting more and
more unimportant. Instead of these personal relationships, loyal dependencies are
getting more relevant. These dependencies are based on common aims such as
implementing a new software product, for instance. For this reason, it is very
important that communication partners who are possibly anonymous can trust
each other. The more complex the goals to achieve are, the merrier this aspect
gets involved because complex tasks need ongoing coordination between the par-
ticipating persons. Therefore, computer supported communication will increase
human-computer and decrease human-human dialogues [Fre99].
Language is slowly volatilising and is replaced by and by with short text state-
ments, graphics and pictures which are understood not only by people who speak
the same language.
Communication via electronic channels lack the ability to transmit common im-
pressions of a conversation like personal perceptions or feelings e.g. sounds,
smells or gestures. For example, in emails communication is reduced to words,
video-conferences only have the ability to include some gestures of the commu-
nication partner confining the quality of the dialogue.
Introducing computer supported communication leads slowly to a transfer of per-
sonal responsibility to computer applications. By inadequate use of e.g. company-
wide deployed software applications, the users more and more blame the software
for their own faults.
Direct forms of communication such as telephone or personal discussions are
more and more replaced by asynchronous statements, briefings or requirements
notified by email or other forms of electronic messages. In addition, these new
communication forms interestingly produce added conversations. Often, the sim-
plest questions, which can be answered oneself by thinking about it, are asked e.g.
in a forum. The answers may induct new questions, new propositions are made
and therefore communication can sprawl unregulated.
10
3 Types of project related communication
Communication is a widespread term, therefore establishing an efficient project
related information system means to comprehend the following three parts of
communication, of which the third one contains direct forms of communication
such as meetings, phone, email, etc. These forms are described in detail.
• Project reporting
• Project documentation
• Direct communication
• Reports about project progress: These reports usually are prepared by the
project manager either during regular periods or when a milestone is reached.
11
• Final project report: This report is also written by the project manager and
is quasi the last project progress report. Normally, it is presented during the
project meeting also to encourage learning effects for future projects.
• Project manual
Part of a project related repository should be for example a project website. Such
a website is a significant instrument for providing the project members with all
the needed information about the project [Sto04].
12
is that arising questions can be cleared instantly. The messages are not explicitly
stored in the channel.
• Face-to-face meetings
• Chats
• Instant-messengers
• Discussion forums
• Newsgroups
Messaging systems They allow the exchange of messages whereat the partici-
pants cannot communicate synchronously. The management of the messages can
be supported by several features such as additional information attached to the
message. The most classic messaging system is email.
13
Conferencing systems can be subdivided into three classes:
Information systems These systems provide structured data for the users and
can be retrieved by according access mechanisms. Information has to be adminis-
trated by adding, changing and deleting content.
14
Individual meetings are usually attended by four people or less, mostly only
two. These meetings are used to get specific and detailed information from each
other. It is easier to solve problems especially if additional questions are coming
up.
Cross-functional meetings are ment to get an overview of the project and there-
fore persons from different areas may participate. Such meetings need a begin
time, an agenda and a specified finish time.
3.4.2 Telephone
The telephone is one of the fastest and most direct forms of communication if
the dialogue partner is available. Nearly everybody uses telephone as a fast and
reliable communication channel to get information or inform another person about
something of importance. Compared to personal meetings, telephone calls are
usually briefer and are used rather as call backs for deadlines or meeting times.
They are less time consuming and leave less space for misunderstandings than
emails. Disadvantages are of course the lack of traceability of the call or the fact
that the called person is not available in the moment of the call and, on the other
hand, torn out of his work.
3.4.3 Workshops
In workshops the project team members develop detailed plannings, e.g. defining
work packages and assigning them to team members at the beginning of a project.
Workshops usually last at least a day, or sometimes several days [Sto04, GP04].
15
3.4.4 Discussion forums
Discussion forums are an asynchronous way of exchanging information. When
entering a forum, a list of all postings is shown. Each thread contains a starting
message and its answers. A participant can either create a new thread or respond
to an existing one. Forums can be opened or restricted, are either facilitated or
not. A special form of such forums are newsgroups. These are public discussion-
and information forums in which news are exchanged. Each newsgroup covers a
specific topic. News are organised hierarchical and you have to be registered to
the corresponding news server to access to it.
3.4.5 Chats
Chats are by reason of their instantaneous and direct form of communication pre-
ferred for short arrangements. In a chat any number of participants can attend, but
they should follow established rules for chats. These rules are called chatiquette.
Chats are organised in chat rooms or channels and the communication is usually
logged by the chat server. A specialised form of chats are instant-messengers
like ICQ. These programs provide personalised chat functions for communicating
favoured with friends or colleagues.
4 Emails
4.1 General information about emails
As emails are an important part of my diploma thesis, this type of project related
communication channel is described in an own chapter.
The significance of emails is getting more and more important due to the spreading
of computer networks all over the world. Nicholas Negroponte even states "that
email is the most important application in computer networks" and makes the case
that emails will create a totally new worldwide social arrangement [Neg95].
Electronic mail, to everybody known as email, name a letter like message carried
forward via computer networks like the Internet and is the most popular Internet-
application beside the World Wide Web. The first email was sent in 1971 via the
Internet predecessor Arpanet by Ray Tomlinson. It did not take long for this new
application to overhaul other applications such as Telnet or FTP with its trans-
ferred data volume contradicting to Lawrence Roberts who said that the exchange
16
of messages among computer network users are not an important motivation for
a network of scientific computers. Due to the fact that emails are usually sent in
plain text, they are more similar to post cards than to letters. Basic email technol-
ogy does not include features like encrypting, signing or registered letters. Nowa-
days, more precisely since 2002, more than a half of the worldwide emails sent
are spam, making these missing features necessary to avoid anymore useless email
traffic [Wika].
One of the greatest benefits of email is the fact that the recipient can decide when
to answer. When sending information, emails are eventually faster than the tele-
phone because emails are brought forward even if the recipient is not available at
the time. In addition, replying to an email is much easier than to a document in
written form. Responding is possible via one mouse-click, the message transfer
occurs in seconds, no paper or envelopes are needed and the recipient is able to
read the message whenever he has time to do so. This advantage of timing the
answer as recipient decreases the stress factor which is at hand by telephone, es-
pecially cellular phones. Email messages are appreciated by many people for
well-defined straightforward questions which can be answered clearly without
misunderstandings. Furthermore, emails are so popular because they are asyn-
chronous and readable on the computer. They create enormous mobility, as the
location both of the sender and recipient is not important. Besides, emails are di-
rect and avoid conversations. If there are any interpersonal conflicts between the
dialogue partners both can stay impersonal and businesslike easier.
Of course, asynchronous communication is also possible with the answering ma-
chine of the telephone. It is also a question of preference which type of commu-
nication is chosen: verbal or written form. Nevertheless, regarding the content of
communication, emails are the more beneficial way. Further processing particu-
17
larly archiving the message content is much more comfortable and space-saving
than other communication channels. Supplementary, the concentration of the di-
alogue partners is not affected the way they are during telephone calls. Answers
can be phrased without stress and written at any time.
Additionally, a record of the whole communication is also possible. Email mes-
sages are instantly stored and documented in a database allowing easy project
traceability, for instance. This digital availability of email allows further process-
ing with little time and effort.
Email is not limited to plain text, the sender may add various files to the mes-
sage which are called attachments. Although there are no limits regarding email
size, the mail provider usually sets a limit not to exceed appropriate mail traffic.
In addition, by using HTML-mails the sender is able to format fonts, colours or
insert pictures into the message. Nevertheless, these HTML-mails are ill-reputed
because they pose security risks if for example JavaScript is included in the email.
Emails can be used for several purposes. An example for email utilization would
be newsletters which are very useful for regular status reports sent to a broad target
group, for instance.
Another alternative of emails are discussion forums. The only difference between
conventional email messages and such forums is the fact that in a forum the dis-
cussion thread is easily accessed and all answers to each post is shown. Each user
can answer questions or ask some. Forums are helpful in supporting team work,
especially if the team is separated by open ground. These email flows can be
analysed to combine people with similar interests or skills to according mailing
clusters, for example.
Many email-clients support indexing and searching features which help the user
to manage the information overload created by the intensive use of emails nowa-
days. Usually, filters can be defined to classify emails and file the message in an
according folder in order to handle this challenge [Fre99].
• Email is asynchronous
• Email is fast
• Email is text-based
18
• Email has a built-in external memory
19
are uncommon for formal correspondences and the recipient may be grieved.
Email discussions are a good example to show the differences between conven-
tional and computer supported communication. Advantages of email discussions
are that the participants are answering more evenly and more proposals are made.
In normal group discussions usually only few participants speak. But there are
considerable disadvantages regarding social relations as well. The open and not
restrained dialogue via emails complicates democratically decision making. An
important circumstance of email communication is the fact, that nobody can cut
somebody off. Experiments show, that groups of three persons need quadruple
time for making a decision with emails in comparison to direct contact. In addi-
tion, if email linked dialogue partners are pressed for time, the decisions are more
extreme and polarized, or even sometimes no solution is found and no decision is
made [Fre99].
20
arguments and the students did not copy statements from others but phrased their
own thoughts. On the other hand and as already stated, email discussions are not
capable of transmitting visual or other sensitive impressions making interpretation
of statements more difficult than in conventional discussions. Synchronisation of
the discussion is not trivial, because every participant can answer at any time to
any statement. Therefore, any participant has to keep track of the discussion, oth-
erwise disorientation is possible. The larger the group of discussion members, the
harder this might be. An in-class discussion is more structured. Another disad-
vantage is the difficulty not to get off the subject if the moderator does not react
quickly to prevent this. Additionally, some inactive students had to be motivated
by the moderator to contribute to the discussion.
21
• Monitoring of the email traffic mainly decreases email usage for personal
matters
• Reduced efficiency due reading fun mails and using email in unprofessional
way for private messages
22
5 Distributed and collaborative project management
Fundamentals of project management are changing by reason of business global-
isation. In past project management approaches, few individuals, located higher
in the organisational hierarchy than the common project members, had the total
overview from the project. Individual project members only knew their tasks and
had no authorisation to make decisions. This procedure only works in repeatable
process environments of course.
Nowadays project hierarchies are often more flat and every project member brings
in his own opinion and creative thoughts. In addition, an increasing number of dis-
tributed projects are conducted which involve project collaborators from different
sites.
The three greatest challenges for distributed project management are [FC03]:
23
• Collaboration: provide qualitative levels of communication, interaction and
coordination.
• Knowledge management: obtain and share explicit knowledge
• Task scheduling: especially the analysis of task interdependence
First of all, distributed teams are nowadays often unavoidable, especially when it
comes to software development. It is not possible to have all the specialists for
every task at one location. Companies often have several locations all over the
world or work together with other companies. Universities also do not always
have all experts who are needed for specific tasks. Some experts are not needed
full-time and are possibly working at many projects at many locations simulta-
neously. Collaboration over great distances has become reality. This is the most
serious aspect when it comes to distributed teams, but there can be additional
circumstances.
When developing software applications, the clients often request the presence of
at least one project member at their site to have a direct contact person. This
approach often improves the information exchange with the client. However, the
project team has to deal with its local separation.
In some cases, project members are reluctant or unable to relocate to other loca-
tions.
Sometimes it is simply to expensive to get all project members to one location, for
example because there is not enough office space for the whole team. On the other
hand, it might be possible that technical resources are needed which are available
only at different locations.
Most software projects, except small ones, involve many people which leads to
increased communication efforts. Project success depends on the quality and uti-
lization of the communication channels which are used in the project team. In
larger projects, it is beneficial to have a highly organised proactive coordinator for
making suggestions for improvements, managing opinions, summarising conclu-
sions and presenting them for discussion.
For the first project type (single-project, single-location) only common project
management resources such as basic communication (e.g. meetings, phone,...),
coordination tools (e.g. for supervising project progress, scheduling, resource
planning) and information sharing (e.g. document management systems) are needed.
24
Distributed locations additionally afford the technical infrastructure to provide in-
ternet or intranet connections and possibly interoperability between different com-
puter systems to communicate efficiently. The second (single-project, distributed-
location), and even more the third project type (distributed both project and lo-
cation), include all the problems of distributed project management as mentioned
above. Utilised project management tools need to support advanced features such
as cross-project calendaring or prioritization schemes to coordinate the compli-
cated activities arising with this project type. Groupware systems for distributed
project management are described in the next chapter [NCRJ02].
25
effort increases, as it is not naturally to get feedback from other team members
at short notice because this person possibly works in another time zone. It is not
possible to arrange meetings easily, they have to be virtual. In those meetings, the
interaction of the participants is limited and the decision making process is more
complicated.
Another problem are maybe different languages spoken by the team members. A
common language but also common terms and expressions have to be defined be-
tween the project members to avoid misunderstandings or misinterpretations. The
absence of personal contacts hinder developing relations, especially if different
culture groups are involved.
Furthermore, different locations often use different tools and infrastructure such as
different word-processors, email systems, operating systems and hardware. These
varieties also complicate efficient collaboration [col05, PL00].
To assist project team members in their collaboration efforts and needs, project
management tools, which support features described in the next chapter, are re-
quired.
A collaborative PM-software should ideally support all needed features for dis-
tributed project management and can be classified into four levels. Each ongoing
level is based on the lower level including all its abilities.
26
there are no further interaction possibilities, this level only provides the most basic
tasks such as informal communication, information sharing or short dialogues.
Advanced project management software should at least support the first three lev-
els, because the lower levels only provide information sharing which is insuffi-
27
cient for efficient collaboration between distributed project teams. Members at
different locations depend on other people doing their job and therefore the inter-
action between them is essential, making concerted level applications necessary
[NCRJ02].
Most of the project management tools and groupware systems which are used
today were developed to fulfil all requirements of non distributed project man-
agement. With today’s demands of collaborative applications accessible over the
Internet, groupware systems have to be integrated into project management sys-
tems which are used. A groupware system supports a group of collaborators who
conduct a common goal. To reach this goal, this groupware system must have the
following features: coordination, collaboration and communication. Communi-
cation is the base for achieving coordination and collaboration, as already pointed
out before. Therefore, the design of the communication features is the most im-
portant part of the system. Other important features are awareness, sessions and
user administration and notifications.
In computer-mediated communication (CMC) systems the following elements are
involved: a sender, a recipient, a message and a channel. Every groupware system
normally has multiple ways of message addressing, for example point-to-point
and multicast, synchronous and asynchronous.
The groupware system should support every communication scenario which could
be used in the project team. Ideally, every project member gets a feeling about
what is going on in the project by using the groupware system [JMH02, FC03].
28
5.5 Knowledge development via documentation of communi-
cation
Collaboration backed by communication is one point, to benefit from it after-
wards is another. To retrace the acquired information through communication of
the project members, the collected knowledge has to be stored in a central well
structured knowledge base.
• Engagement: Is the style and medium of the information adequate for its
audience?
29
5.5.2 Knowledge development via email
Technical communication can play an important role in this area. It is undergo-
ing a transformation nowadays with the rise of the World Wide Web. Knowl-
edge is spread more and more through (technical) communication. Collabora-
tive distributed work increases the importance of knowledge sharing and creation
between the separated project team members. This aspect is called knowledge
management and required to improve the organisational learning effectiveness
and global competitiveness. Knowledge can be obtained by using communica-
tion technologies more effectively. Information is mostly transferred and stored
electronically, nowadays. From a business and educational point of view, the In-
ternet has become a digital schoolhouse alternative knowledge base for its users
[Leo98, Ank99, Lic04].
For example, if a project member asks for help via email, the recipients are com-
mitted to read the message and, when suitably, respond to it. Replying to emails
in quoted form has become a common way. This electronic record-keeping is in-
creasingly relevant not only for accountability, but also for legal aspects. During
many of these email discussions knowledge is created not only for the project team
in the whole, but also for each project member in particular. Although knowledge
development is not supported best by email, nonetheless email conversations build
spontaneously and naturally new knowledge.
A typical knowledge development cycle from email discussions contains the fol-
lowing processes leading to new knowledge:
30
Initiation The initial email message can contain questions, suggestions, instruc-
tions, etc. and becomes part of a knowledge trail which consists of related, suc-
cessive messages in one or more so called threads. The initial message usually
contains primarily information, no new knowledge yet.
Crystallisation and sharing During replying to the initial message and its suc-
cessors a knowledge trail, which is also called knowledge-under-construction,
may be formed and it grows in size and information with every message. The
participants share insights, ideas, suggestions, contextual information and other
already existing knowledge along this knowledge trail, crystallising relevant in-
formation. During this process, the significance of the trail increases and the
emerging knowledge usually obtains multiple perspectives, relevance, context,
validation, innovativeness, problem resolution, consensus, clarity, etc. The trail
can widen to more than the initial subject or can be finalised if all participants are
satisfied. Persons who accessed the whole trail possess all the knowledge shared
and created during the discussion. Due to documenting the whole trail and allo-
cating it, knowledge has been created and is shared.
31
The outcome of such email conversations can result in different forms such as
decisions, policies or organised plans. The created knowledge from email discus-
sions can be described as purpose-driven and just-in-time knowledge to provide
project members with it for their everyday work needs, activities and responsibil-
ities [Lic04].
MEME Nowadays, most of the messaging systems which are in use have very
little information about the people in the communication network. These mes-
saging systems can practically do nothing more than simply deliver messages to
recipients prior known by the sender. Of course, this lack of directing messages to
32
according recipients can be decreased by mailing-lists. For example, if someone
needs a Java expert, an email to a java-mailing list could be sufficient. In bigger
companies or universities, those people should be available. But the problem is
that not every member of such a mailing list is an adequate conversation partner
automatically, meaning not every java mailing list member is a Java expert for
our case. Again, the messaging system lacks knowledge about the users. This is
where MEME comes in.
MEME is an adaptive information sharing system which is not only capable of
sending information per email, but it also evaluates the information of the mes-
sages based on defined user profiles or overall preferences. The interesting feature
of MEME is that the system can assign relevant value to information extracted out
of messages and, in addition, send this information to persons who are perhaps
interested in it. MEME creates and administrates user profiles and groups of users
who have similar profiles. By comparing the information of the email messages
with the knowledge profile of the users or groups, the system can additionally
decide who gets these messages. These profiles are adaptive, meaning that they
are extended and tuned by MEME based on the email feedback the users give to
the messages in the system. Of course, the feedback should correspond with their
interests, information needs and own knowledge. The profile and group admin-
istration can also be done manually by a user to improve the classification of the
messages.
To come back to our example with the search for a Java expert: Perhaps there
are persons who have exactly the knowledge you need, but they are on no Java
mailing list or have not entered their Java skills into their profiles. Let us make the
assumption that these required persons however have participated in several Java
projects and communicated in their corresponding project teams via email about
these projects. MEME can take advantage of the information semantics of these
messages by adapting the profiles of these users, making them a contact person for
Java matters without explicit profile administration effort. Regretfully, MEME did
not exceed its educational surrounding but the benefits of such a system is obvious
[MD01].
33
6 Web-based software development
6.1 Definition of a web project
The Internet and its applications, especially the World Wide Web, have become an
integral part of our world and the large number of web users increases every day.
This world wide network supports the collaboration of distributed project teams
and web-based project management tools are a valuable complement to project
management. But web-based applications have to be implemented as well. In this
chapter it is described what web projects are and how they differ from conven-
tional projects [Laz01].
Web projects are IT (information technology) projects and design projects as well:
A web project can be mainly focused on the technical side, for instance internal
changes of data access methods to the used data source without changing anything
in the user interface. But generally design-driven web projects are also possible
34
like, for example, changing only pictures on a website. Web projects are usually
a mix of both sides, making web projects an interdisciplinary challenge [Sto04].
35
ternet experience and different technical equipment. All these aspects should be
considered when implementing a web project [Sto04].
Web projects can suffer from all conventional project problems arising during im-
plementation such as insufficient communication, important decisions are delayed
or not made at all, bad project planning, budget reduction, etc.
36
• Defective content
• Hacker attacks
• The website does not fulfil user-satisfaction resulting in less usage of the
website.
While IT-problems are already recognised during the project, the website is either
functioning or not. Design problems often appear after the launch of the website,
for example if the user acceptance is low.
When implementing a web-project some procedures are helpful like involving the
user of the website, keeping project durations short or implementing the most
important features at the beginning of the implementation process [Sto04].
37
• Usage of a content management system, especially if the IT-specialists are
not familiar with it yet.
• When implementing websites, there is often a lack of usability.
• Internationalisation
6.5.1 Firewall
Usually, an own firewall-computer secures the internal network that it prevents
any unauthorized entry. The firewall should be separated from other servers to
keep security risks at minimum. The more services are running on a system the
merrier security links emerge.
38
complicated regarding static websites, the sites are simply copied on every web
server. Those load balancing systems are sometimes actually integrated in net-
work switches or in small software programs. Handling dynamic portals with
user sessions is not trivial. In this case, the user sessions are either closed when
switching to another server or have to be mirrored to other servers as well.
39
examples are the commercial IBM Web Sphere server and the JBoss server which
is available for free [Wikf, Sto04].
6.5.5 Database
On every website data has to be stored, and in most cases a database is used.
Again, there are many options for choosing a database, commercial and free ones.
Market leader is Oracle with its commercial product, but there are free avail-
able alternatives such as MySQL or PostgreSQL fulfilling the required features
[Sto04].
40
• Learnability: How easy is it for users to accomplish basic tasks the first time
they encounter the design?
• Efficiency: Once users have learned the design, how quickly can they per-
form tasks?
• Memorability: When users return to the design after a period of not using
it, how easily can they re-establish proficiency?
• Errors: How many errors do users make, how severe are these errors, and
how easily can they recover from errors?
Graphic user interfaces (GUI) have shortened potentials in web projects be-
cause of the restrictions which are given by the World Wide Web and the HTML-
standard. From the technical point of view it is therefore naturally more difficult
to achieve the same usability standards for web projects as for conventional Win-
dows programs, for instance. To keep navigation through a website clearly laid
out and intuitive but nevertheless efficient is one of the most challenging tasks
when implementing web projects. In addition, certain browser incompatibilities
do not make this task easier.
41
should be displayed. The user must not be confused by amounts of information.
The principle of simplicity known as KISS - Keep it simple and stupid - comes
into play. Also, first sight impressions are very important.
Interaction with the user Getting feedback is no trivial issue in web projects,
because web pages can only react on a users request. For example, a form which
contains many fields should have immediate feedback after entering information,
not until the whole form is filled in and submitted by the user. Unfortunately,
those features require additional features such as JavaScript. If such features are
not possible, detailed and clear feedback has to be given to the user at least after
the user submits the form.
Critical problems These problems are imperative to fix before the product can
be released. They make the application very difficult to use or even not usable at
all.
• System crashes
42
• The user prevents himself from further use
Minor problems These problems are also important to fix, but normal usage of
the product is not affected. They can confuse users while using the product or
increase the time a user needs for the performance of a task.
• Loss of functionality
• Layout inconsistency
Cosmetic problems These problems need not be fixed unless extra time is avail-
able on the project. As already the name points out, they are cosmetic and there-
fore not affecting the usage of the product in a disturbing way.
• Spelling problems
43
detect serious problems prior to the release of the product. Usually, such reports
provide proposals to improve the quality of the software.
Usability testing provides business value and lowers the risk of product failure.
For a software product, a low level of usability can increase market risk such as
increasing support costs, failing to meet customer usability requirements, loss of
brand reputation of a company, or products that are late on the market because of
necessary redesign and consecutive loss of market share [Mea02].
As a matter of fact, one of the most important motives for usability testing is that
designers or programmers are not the users in the majority of cases. End-users
have to be integrated in the whole development process to ensure high usability
standards. Project members are routine-blinded if it comes to usability evaluation.
It is psychologically nearly impossible to forget or ignore already learned issues
when implementing a design or program. Therefore, such a think back into the
end-users point of view is very difficult for programmers and designers but ab-
solutely necessary for usability testing if no end-users are available. In addition,
project team members are usually computer-experienced and use the computer
and the Internet quite regularly. They are mostly not the users of the website, ex-
cept the website is a portal for designers or programmers. To evaluate usability of
a website and uncover its faults efficiently, the website has to be definitely tested
also by the end-users. These test persons should be ideally users of the target
group. To quote Nielsen: "Designers are not users" or "The user is always right"
[Nie93]. Usability tests can take place for example in a usability laboratory, in a
workplace setting, over the web or anywhere else where the required infrastruc-
ture is available.
There are several options to test usability. Some methods are mentioned below:
44
Scenario-based testing The test users have to complete several predefined tasks
or scenarios in a specific length of time. "A scenario is an encapsulated descrip-
tion of an individual user, using a specific set of computer facilities to achieve a
specific outcome under specified circumstances over a certain time interval (this
in contrast to simple static collection of screens and menus: The scenario explic-
itly includes a time dimension of what happens when)." [Nie00] By performing
the tasks, the test users should find usability problems and document them.
Thinking aloud In this method, the test user articulates his problem, impres-
sions and questions which arise during the usability test. The test user is guided
by an observer who quotes these statements and analyse it afterwards.
Questionnaire By filling out a questionnaire, the test user can communicate his
experiences from testing the website.
There are other usability testing methods, and most of them can be combined to
improve the evaluation. A good approach would be: First select representative
test users and set up time and location for the usability test. Then introduce the
test and give the users the tasks which they have to perform. Ask them to attend
the tasks and collect data via videotape, notes or data logging. Conclude the test
with a questionnaire and compensate the test users for the participation afterwards
[MM02, Nie93, Laz01].
45
7.1 Introduction - Project goal
"Open Science Workplace (OSWP) started as a Cooperation Project
between University of Kerman (Iran) and Vienna University of Tech-
nology (Austria) financed by the Technology Cooperation Organisa-
tion (TCO, Iran) and the Ministry of Science (Austria). OSWP is
a web-based project-management and communication tool. It sup-
ports (scientific) cooperation, resource management, project moni-
toring and information distribution." [OSW05]
• OSWP is web-based and can therefore be accessed at any place just by using
a web browser.
• The used technologies are platform independent (Java, XML) and there is
no restriction to a specified database because a JDBC capable relational
database system is supported [AS04].
• Finally, OSWP is a full open source project under the Apache license.
The first version of the communication module in the OSWP-portal only included
a simple form where users were able to send a mail to several addresses.
To enhance project-related communication, new features were added. The ap-
proach was to keep a mail history of all mails which were sent through the portal
and enabling of email/project association. This history now allows administrating,
viewing of and replying to messages. Mails are not only sent anymore, each mail
is stored in an eml-file on the server’s file system and can be accessed through the
portal anytime. The possibility of sending and/or assigning mails to projects al-
lows project-related communication. It also provides a growing knowledge-base
for each of the projects. Users can discuss their proposals or problems, for exam-
ple, like in a forum or a mailing list. But they can also address people who are not
registered as users in the system.
Furthermore, every user can configure his own mail-accounts to retrieve mails via
POP3. These mails can also be integrated as project mails by assigning them to
46
the desired project. Additional features such as signatures, contacts and mail fil-
ters have also been implemented.
47
Figure 6: Overview and structure of the used components
48
technology [Sun05a].
For this reason, a J2EE server is needed. JBoss plays that vital role for OSWP.
This server is a J2EE implemented open source software, only documentation
and support are charged. JBoss includes the JBossServer, the EJB-container (En-
terprise Java Beans) and the JMX-infrastructure (Java Management eXtension)
[JBo].
A customized JBoss distribution is available at the OSWP-website [OSW05].
• Operations such as sub selects, outer joins, views, trigger, and referential
integrity and transactions are supported.
Tables The following tables were created to store all the data which is needed
for the new features of the email-communication part of OSWP:
49
mail_email: This table stores a reference to all emails which were sent, received
and assigned to any project. If an email is needed, the corresponding eml-file is
loaded from the file system.
* This attribute is set with the appropriate user-ID, if a user has sent an email
through OSWP. If set, this email is shown via Sent mail of the corresponding user.
** This attribute is set with the appropriate pop3-account-ID, if this mail has been
received by a POP3-account of a user. If set, this mail is shown in the equivalent
POP3-account of the user.
*** This attribute is set, if the email has attachments.
50
mail_mailuser: This many-to-many relationship between emails and users con-
tains the information which emails were sent through OSWP directly to users or
to projects where the users were assigned.
* If set, all emails are deleted from the mail server after retrieval.
mail_smtpaccount: Every user can manage several SMTP- accounts and sent
emails through them. All needed information to authorise the user to the accord-
ing SMTP-mail server is stored in this table.
51
Restrictions Data type Restrictions Description
id Integer Not null Primary key
name String Not null Name of account
servername String Not null Name of host, e.g. smtp.gmx.net
username String Not null Name of user
password String Not null Password of account
emailfrom String Not null Send address of user *
userid Integer Not null Foreign key person
52
Restrictions Data type Restrictions Description
id Integer Not null Primary key
name String Not null Name of filter
filter String Not null Filter
type Integer Not null Type *
projectid Integer Not null Foreign key task
userid Integer Not null Foreign key person
53
Figure 7: Database model
54
OJB To ease communication with the database, an object/relational mapping
tool is used. Such a tool allows committing the actual content of a Java Bean eas-
ily into the according database table and vice versa getting data out of the table
into the Java Bean transparently. The properties of the Java Bean correspond with
the attributes of the database table.
• All needed SQL-queries are generated by the tool. Therefore, the program-
mer is discharged of testing SQL-statements which were written. This as-
pect decreases the number of test runs and heightens the stability of the
product.
• The first project with a mapping tool needs some time to work in, but after
that time every software development cycle is accelerated.
• You are getting independent from the used database. Many O/R mapping
tools support varying databases. So it is possible to migrate to another data-
base without changing any code, only the mapping tool has to be reconfig-
ured.
One disadvantage of OJB is the reduced performance because only the own SQL-
code can be optimized to the used database. This loss of performance can be
compensated by so called proxy-classes. Database access is only executed if data
is actually needed. For example, a Java-collection is filled with proxy-classes and
only filled with data if the corresponding Java Bean is accessed with a get-method.
There exist many O/R-tools, for OSWP OJB (ObJect RelationalBridge) [Apaa]
was chosen. OJB is open source and programmed in Java.
There are four different APIs which can be used. OTM (Object Transaction Man-
ager), ODMG (Object Data Management Group) and JDO (Java Data Objects)
are all based on the PersistenceBroker kernel API. This is the most basic API and
provides low level access to the database. It is used for OSWP. It follows a short
introduction how OJB is used in OSWP.
55
• JavaBeans accessed by the application corresponding to each database table.
These beans must provide get- and set-methods for each member variable
which accord to the database table attributes.
• OJB needs to know which bean and database table corresponds together.
This information has to be defined in a XML-file called repository.xml.
56
XDoclet The additional expenses which result in creating and maintaining the
repository.xml can be annoying since every change in the database also has to be
applied in the JavaBeans and the repository.xml. The OJB website proposes five
different approaches to automate some of these steps which include:
The first three approaches generate the required Java-code, database scheme and,
in case of the first two, the repository.xml out of defined XML-files as well. They
are recommended if you begin a project from scratch having a large number of
persistent classes, because you are not bounded to any database restrictions yet.
By using reverse engineering from database the Java-code and the repository.xml
are generated out of it. Tools such as Druid or the Impart Eclipse Plug-in for OJB
take over this task [Apaa].
For OSWP the XDoclet transformation from Java-code was opted [Sou05]. By
adding meta data attributes to the Java-beans, like database specifications, the
XDoclet code generation engine parses the source files and creates the reposi-
tory.xml and the database scheme automatically. These meta data begins with
@ojb and has to include all necessary information such as table name, field name,
database restrictions (e.g. length) and OJB-internal options (e.g. auto-retrieve,
auto-update, auto-delete). The used meta data attributes are listed below:
Class/table definition: Each Java Bean represents a database table. This infor-
mation has to be inserted at the beginning of the class.
Example:
/** @ojb.class
* table="mail_smtpaccount" */
public class SMTPAccount { ...
57
Member variable/attribute definition: For each database attribute an equiva-
lent member variable must exist in the Java Bean.
Examples:
/** @ojb.field
* length="255" */
String username;
/** @ojb:field
* conversion=
"info.oswp.ojb.converter.Calendar2SqlTimestampFieldConversion"
* jdbc-type="TIMESTAMP" */
Calendar sentDate;
Example:
/** @ojb.field */
Integer userId;
/** @ojb.reference
* element-class-ref="info.oswp.model.User"
* auto-retrieve="true"
* auto-update="false"
* foreignkey="userId" */
User user;
58
Many-to-many relations definition: Such relations are very comfortable to
handle, as the many-to-many table does not have to be accessed directly. Just
by calling the get-method you gain a collection filled with the corresponding ob-
jects of the other table.
Example:
59
Figure 9: XDoclet engine
The created repository.xml is ready to use, but the database scheme has to be trans-
formed into a database-SQL-script to create the required database tables. This
script is generated by Torque [Apad] out of the database scheme created by the
XDoclet code generation engine and can be executed to the database.
60
7.2.3 Presentation layer Struts/Tiles
Like any web-application which is implemented in Java, the presentation layer
contains the dynamic web pages called JSPs (JavaServerPages) and the logic be-
hind is made up of Java-Servlets and JavaBeans. In small projects it is no problem
to code the workflow without a planned structure. But the bigger a project grows,
the more it is essential to implement a central and standardized control of all re-
quests and responses.
The open-source framework Struts was used to ease implementing the GUI of
OSWP [Apab].
• Break-up of dialogues and logic: When changing logic you do not need
to adapt the dialogues as well. That leads to improved clarity and mainte-
nance. Furthermore, multiple usage of the same logic for different dialogues
becomes possible.
• Central control: By implementing the application flow directly into the busi-
ness logic, changing of sequences gets difficult. For this reason, a central
point for controlling of all application flows would be beneficial.
• Internationalisation: This feature is part of Struts and very ease to use. You
just have to manage the appropriate language text files.
The typical workflow is described as follows: The client requests a specific page
which has to be defined as an action mapping. If available, the referring action
class is executed which contains the logic for the application flow and calls the
corresponding JSP (this information is specified in the tiles-forward). A response
is sent to the client. The data which is shown to, created and modified by the user
via the JSPs is stored in form beans by the according action class.
61
Figure 10: Structure of presentation layer using Struts
<form-beans>
62
<form-bean name=
"emailForm" type="info.oswp.oswpmail.web.action.EmailForm"/>
</form-beans>
Each request URI has to be mapped to a specified action class which contains the
particular application flow. In addition, forwards can be defined. If any forward
is called from the action class, the forward path is looked up in the Tiles definition.
<action path="/Sendemail"
type="info.oswp.oswpmail.web.action.SendemailAction"
name="emailForm" scope="session"
attribute="form" parameter="method">
<forward name="send" redirect="false"
path=".view.oswpmail.sendemail.send"/>
<forward name="success" redirect="false"
path=".view.oswpmail.sendemail.success"/>
<forward name="failure" redirect="false"
path=".view.oswpmail.sendemail.failure"/>
</action>
Every forward of an action mapping must lead to specified JSPs, defined in the
tiles-def.xml. As shown below, the name corresponds with the forward-path of
the action mapping. The example extends another defined tile and adds one page.
<definition name=".view.oswpmail.sendemail.send"
extends=".biglist.layout">
<put name="title" value="OSWP - open science work place"/>
<put name="centerbox_title" value="Compose Email"/>
<put name="centerbox_content"
63
value="/WEB-INF/jsp/oswpmail/sendemail/compose.jsp"/>
</definition>
• User: The user of the mail-system who sends and / or receives emails
• Mail User Agent (MUA): The interface between the user and the mail-
system.
64
• Message Transfer Agent (MTA): These are individual components of the
Message Transfer System and are responsible for the actual transmission of
messages.
• Message Transfer System (MTS): The MTS is the collectivity of all MTAs
and their connections.
Message transmissions are handled by these components at which the user creates
the message through his MUA. Afterwards, the MUA transfers the message to the
MTA. These agents are responsible for transmitting the message to its recipient(s).
This happens either directly if the recipient is in the same network as the sender, or
via store-and-forward delivered to the recipient of the message. After sending, the
recipients MTA retrieves the email and passes it to the recipients MUA [Gal04].
Now the protocols for sending and retrieving emails which were used in the
OSWP-implementation are described briefly.
SMTP SMTP stands for Simple Mail Transfer Protocol and manages the trans-
mission of emails in computer networks. It belongs to the TCP/IP protocol-family.
More precisely, SMTP is a protocol of the application layer of the TCP/IP model
[Uws].
SMTP is used to send messages from a mail client to a specified mail server but
not to retrieve them from the mail server. This is why you need to specify both
65
the POP or IMAP server and the SMTP server when you configure your email
application. Other SMTP-servers can be used as interstation to deliver emails to
its final destination.
The SMTP-server usually uses the port 25 as defined by the IANA (Internet As-
signed Numbers Authority) [Ian].
SMTP is a really simple protocol. You can send emails from command line just
by using telnet [Web], for example. Sender and recipient are arbitrary, even the
addresses in the MAIL FROM and RCPT TO can differ from the addresses in the
To: and From:-fields of the mail header. In 1982, when SMTP was defined in
RFC821 [IETb], reliability was much more important than today because of the
little amount of hosts. In addition, the connections were slow and unstable. Every
mail server was an open relay. An open relay is a SMTP email server that does not
prohibit third party users to relay email messages. It is easy for any user to misuse
these mail servers to spam others, for example. Other expressions for open relay
are spam relay, third-party relay or insecure relay.
To prevent spammers from flooding other mailboxes, an extension to the SMTP-
66
protocol named ESMTP (Extended SMTP) was introduced. One important en-
hancement was the implementation of authentication on the mail server with user-
name and password. Usually, all authenticated users who used the ESMTP-mail
server are documented in a log file [Wikd].
67
There are several POP3-server available, some of them are:
• Windows: Usually the POP3-server is integrated in the mail server-package
installed on the server (e.g. Microsoft Exchange)
• Unix: courier-pop, cyrus-pop3d, ipopd, popa3d, qpop3d (part of qmail),
qpopper, ipop3d
A typical POP3-session is listed below:
68
Usually, every mail server includes a SMTP- and a POP3-server which handle
mail-traffic as shown in the following illustration:
MIME In the early days of the Internet, an email consisted of readable, English
text messages. In time, the RFC822 standard (text messages) [IETc] got inade-
quate and several extensions were defined because the RFC 822 cannot encode
the following data [Gal04]:
To find a remedy, MIME was defined. MIME stands for Multi-purpose Inter-
net Mail Extensions. Nowadays, Multimedia Internet Message Extensions also
is usual. It is not a protocol, but it rather defines the content which is sent. It
69
sets the standard for the format, the structure and builds up of an email and other
Internet-messages. MIME allows exchanging information about the type of the
transmitted data (content-type) between sender and recipient. Simultaneously in-
formation about the encoding of the message (content-transfer-encoding) is also
transposed. There are several options to encode non-ASCII messages. Non-text
elements are usually base64-encoded, non-ASCII characters are often encoded by
using quoted/printable. MIME messages can contain multiple body parts which
are separated by boundaries [Wikc].
70
The purpose of the JavaMail API is not to transport, deliver or redirect the mes-
sages like sending email in UNIX or other MTAs, but rather to provide protocol-
independent access to send and retrieve messages. To communicate with a mail-
server, a so called provider for the required protocol is needed. There are provider-
packages available from Sun which contain the most common protocols such as
POP, SMTP, IMAP or MIME. JavaMail allocates many useful methods to imple-
ment the features which are needed when implementing a mail-application.
The implementation structure of the email business logic is illustrated below:
71
be very large. Therefore, a folder on the application server has to be configured to
store the emails. Each email is saved in a separate file with the extension ’.eml’
which has been widely accepted for storing emails. Most of the email clients can
open this file type.
72
Figure 18: Screenshot - General mail options
SMTP- and POP3-accounts Both account types can be created, edited and
deleted in the same way. They need an account name, a server name, a user-
name and a password. Supplementary, for the SMTP-account a send address has
to be specified. An internal SMTP account is also available. The user can choose
whether the mails are deleted from the POP3-account after retrieval or not.
73
Figure 19: Screenshot - Edit SMTP account / POP3 account
Signatures Signatures are used for adding information, such as the name or the
contact information of the sender, at the end of a message. Every user can manage
several signatures and select one when sending an email.
Contacts Not all regular recipients who receive emails through the portal are
registered as user in the system. This contact list allows to choose comfortably
recipients who are not regular project members or OSWP-users. The list is global
and every user can create new and edit existing contacts.
Mail filters These filters allow automated assignment of retrieved mails to projects.
Three filter types are available, including subject, sender and text. If any of the
specified filters apply to a downloaded message, it is assigned to the specified
project.
74
Figure 20: Screenshot - List of all filters
• Projects: All projects where the user is allocated can be selected. Mails are
automatically assigned to any selected project.
• Additional recipients: Any valid email addresses are possible, they have to
be separated by commas.
Beneath the entered subject and written text it is possible to add self-defined sig-
natures. Files can be attached by browsing to its location and simply click on add
selected. The file names of already attached files are shown below.
75
Figure 21: Screenshot - Compose email
To send the message, you just have to click on Send. Afterwards, a dialogue dis-
plays either a success or a detailed error message.
76
Figure 22: Screenshot - Feedback after sending email
77
be saved to disk per "Save attachment".
78
knowledge base for the according project. Email discussions held via this portal
according to a project can be traced and accessed.
I defined the following tasks which the test user had to perform. They were de-
fined in form of scenarios like those described in a previous chapter. The required
data for logging in and creating accounts and also the needed passwords were
given to the test users prior to the evaluation.
After a short introduction, the test users had to complete two scenarios:
• Scenario 1: Please login and create a new SMTP-account and a new sig-
nature. Then compose a new email, attach some files, choose the created
signature and send the message to a project.
The duration of each scenario should not extend ten minutes. I used the Thinking
Aloud Method during the evaluation and I noted the comments of the test users.
Afterwards, the test users had to fill in a prepared questionnaire by grading ques-
tions from 1 to 5. 1 was the best grade (very good, very easy, etc.) and 5 the worst
(very bad, very difficult, etc.).
79
Question Count best grade Average value
How clearly arranged and in- 3 1,4
tuitive are the features?
Is the navigational concept 4 1,2
well situated?
Is the feedback of the portal 3 1,6
adequate?
How do you like the design? 3 1,6
Table 10: Results of questionnaire
I categorised the usability problems which were found during the evaluation test
and during a meeting with Dr. Alexander Schatten. The problems were fixed
afterwards:
80
7.4.3 Cosmetic usability problems
• Some translations were missing or not correct.
7.5.1 IMAP
Receiving emails is only possible via the POP3-protocol by now, which lacks
some valuable feature provided by IMAP (Internet Message Access Protocol)
such as central archiving of the emails on the IMAP-server and therefore re-
duction of local space needed for the downloaded messages, conjoint usage of
mailboxes by several users, server-side sorting and searching, etc. In contrast to
POP3-servers, the messages remain on the IMAP-server and are only transferred
to the client if actually needed. Implementing an IMAP-client besides the POP3-
client would further improve the OSWP portal [Wikb].
81
would be enabled. This feature would be comparable to search methods which
can be managed and the results viewed anytime without conducting a search.
The Internet allows new forms of direct communication which are very effi-
cient and applicable for many different tasks. Mankind finally arrived in the
Information Age and the Internet with its communication channels such as email,
chat, telephone/video conferences etc. brings people closer together than they
ever were before. These communication channels can be utilised for many tasks
improving collaboration within project teams.
82
If utilised correctly, emails can be a valuable addition to knowledge man-
agement by creating new knowledge during email discussions. To also ben-
efit from communication afterwards, the aquired information somehow has to be
stored and structured. Including new built knowledge created during email dis-
cussions into a knowledge base can represent a great value for companies, univer-
sities, etc. This knowledge development process via email and, in addition, two
examples for this kind of knowledge development are discussed.
This master thesis was elaborated, implemented and finally written between au-
tumn 2004 and summer 2005.
83
References
[Ank99] Patti Anklam: Technical communications as knowledge management:
Evolution of a profession. In: ACM Proceedings of the 17th annual
international conference on Computer documentation (1999), p. 36–
44
84
[FC03] Fang Chen, Nicholas C. Romano Jr., Jay F. Nunamaker Jr., Robert O.
Briggs: A collaborative project management architecture. In: IEEE
Proceedings of the 36th Hawaii International conference on system
sciences (2003), p. 12 pp.
[IETc] IETF: Standard for the format of ARPA internet text messages. http:
//www.ietf.org/rfc/rfc822.txt. – last visited 08.07.2005
85
[JBo] JBoss: JBoss application server. http://www.jboss.org. – last
visited 02.07.2005
[Kin97] Roger L. King: Learning how to use the Internet and Web resources.
In: IEEE Computer applications in Power, Volume 10, Issue 2 (1997),
p. 20–25
[Laz01] Jonathan Lazar: User centered web development. Jones and Bartlett
Publishers International, 2001
[MCB02] Marco C. Bettoni, Robert Ottiger, Rolf Todesco, Kurt Zwimpfer: Indi-
vidual knowledge management with MailTack. In: IEEE Proceedings
of 13th International Workshop on Database and Expert Systems Ap-
plications (Sep. 2-6. 2002), p. 157–161. – Aix-en-Provence, France
86
[MD01] Michael Dain, Jack Brzezinski: MEME: An adaptive email-based
information sharing system for educational institutions. In: IEEE Pro-
ceedings. 12th International Workshop on Database and Expert Sys-
tems Applications (2001), p. 449–453
[NCRJ02] Nicholas C. Romano Jr., Fang Chen, Jay F. Nunamaker Jr.: Collabo-
rative project management software. In: IEEE HICSS. Proceedings of
the 35th Annual Hawaii International Conference on System Sciences
(2002), p. 233 – 242
[Nie00] Jakob Nielsen: Designing Web Usability. 2nd edition. Boston Acad-
emic Press, 2000
87
[PL00] Paul Layzell, O. Pearl Brereton, Andrew French: Supporting collab-
oration in distributed software engineering teams. In: IEEE Proceed-
ings. Seventh Asia-Pacific Software Engineering Conference APSEC
2000 (Dec. 5-8 2000), p. 38–45. – Singapore
[Pos05] PostgreSQL: PostgreSQL. http://www.postgresql.org.
Version: 2005. – last visited 02.07.2005
[Sch98] Celia Schahczenski: Experiment substituting in-class discussions with
email discussions. In: IEEE FIE ’98. 28th Annual Frontiers in Educa-
tion Conference, Volume 1 (1998), p. 136–140. – Tempe, AZ
[Sch00] Michael Peter Schmidt: Knowledge communities. Addison-Wesley
Verlag, 2000
[Sou05] Sourceforge: What is XDoclet? http://xdoclet.
sourceforge.net. Version: 2005. – last visited 05.07.2005
[Sto04] Robert Stoyan: Management von Webprojekten. Springer Verlag
Berlin Heidelberg, 2004
[Sun05a] Sun: Java 2 Platform, Enterprise Edition (J2EE) Overview. http:
//java.sun.com/j2ee/overview.html. Version: 2005. –
last visited 20.07.2005
[Sun05b] Sun: Java Mail API documentation. http://java.sun.
com/products/javamail/javadocs/index.html.
Version: 2005. – last visited 10.06.2005
[TCF98] TCForum: Building Usability into Your Development Process.
http://www.tc-forum.org/topichig/hl04wher.htm.
Version: 1998. – last visited 04.03.2005
[Uws] Uwsg: ISO OSI 7 layer model forced with TCP/IP.
http://www.uwsg.iu.edu/usail/network/nfs/
network_layers.html. – last visited 13.07.2005
[Was] University of Washington: The IMAP connection. http://www.
imap.org. – last visited 14.07.2005
[Web] Webopedia: What is telnet? http://www.webopedia.com/
TERM/T/Telnet.html. – last visited 17.07.2005
88
[Wika] Wikipedia: E-Mail. http://de.wikipedia.org/wiki/
E-Mail. – last visited 27.07.2005
89
List of Figures
1 Management cycle [Hee93] . . . . . . . . . . . . . . . . . . . . . 4
2 Knowledge creation process . . . . . . . . . . . . . . . . . . . . 31
3 Overlap of IT and design in web projects . . . . . . . . . . . . . . 34
4 System architecture of a web project . . . . . . . . . . . . . . . . 38
5 Feature-overview of the email module . . . . . . . . . . . . . . . 47
6 Overview and structure of the used components . . . . . . . . . . 48
7 Database model . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8 Connection of OJB and Java Beans . . . . . . . . . . . . . . . . . 56
9 XDoclet engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10 Structure of presentation layer using Struts . . . . . . . . . . . . . 62
11 Screenshot of Struts Console . . . . . . . . . . . . . . . . . . . . 64
12 TCP/IP model layers . . . . . . . . . . . . . . . . . . . . . . . . 65
13 SMTP session example . . . . . . . . . . . . . . . . . . . . . . . 66
14 POP3 session example . . . . . . . . . . . . . . . . . . . . . . . 68
15 Mail traffic overview . . . . . . . . . . . . . . . . . . . . . . . . 69
16 MIME message example . . . . . . . . . . . . . . . . . . . . . . 70
17 Structure of business logic . . . . . . . . . . . . . . . . . . . . . 71
18 Screenshot - General mail options . . . . . . . . . . . . . . . . . 73
19 Screenshot - Edit SMTP account / POP3 account . . . . . . . . . 74
20 Screenshot - List of all filters . . . . . . . . . . . . . . . . . . . . 75
21 Screenshot - Compose email . . . . . . . . . . . . . . . . . . . . 76
22 Screenshot - Feedback after sending email . . . . . . . . . . . . . 77
23 Screenshot - Email overview of a POP3 account . . . . . . . . . . 77
24 Screenshot - Show email . . . . . . . . . . . . . . . . . . . . . . 78
90
List of Tables
1 Success probability of web projects . . . . . . . . . . . . . . . . 36
2 Database table: mail_email . . . . . . . . . . . . . . . . . . . . . 50
3 Database table: mail_task . . . . . . . . . . . . . . . . . . . . . . 50
4 Database table: mail_mailuser . . . . . . . . . . . . . . . . . . . 51
5 Database table: mail_pop3account . . . . . . . . . . . . . . . . . 51
6 Database table: mail_smtpaccount . . . . . . . . . . . . . . . . . 52
7 Database table: mail_signature . . . . . . . . . . . . . . . . . . . 52
8 Database table: mail_filter . . . . . . . . . . . . . . . . . . . . . 53
9 Database table: mail_contact . . . . . . . . . . . . . . . . . . . . 53
10 Results of questionnaire . . . . . . . . . . . . . . . . . . . . . . . 80
91
Index
Abstract, ii Knowledge development cycle, 30
Acknowledgements, i Knowledge development:Examples, 32
Advantages of e-mail, 17
MailTack, 32
Benefits of project management, 2 Means of project information, 6
Meetings, 14
Chats, 16 MEME, 32
Collaborated PM, 23 MIME, 69
Communicational aspects, 8
Comp. supported comm. (CSC), 9 OJB, 54
Conclusion, 82 OSWP, 46
OSWP: Application server, 48
Direct communication, 12 OSWP: Database layer, 49
Direct communication channels, 14 OSWP: Database model, 53
Discussion forums, 16 OSWP: Database tables, 49
Distributed PM, 23 OSWP: E-mail systems, 64
Distributed PM: Advantages, 25 OSWP: Future outlook, 81
Distributed PM: Challenges, 23 OSWP: GUI, 72
Distributed PM: Difficulties, 25 OSWP: Needed components, 47
Distributed PM: Reasons, 24 OSWP: New features, 46
OSWP: Presentation layer, 61
E-mail: individual influence, 21
OSWP: Usability evaluation, 79
E-mail: individual perception, 19
E-mail: organisational influence, 22 POP3, 67
E-mail: social impact, 19 PostgreSQL, 49
E-mails, 16 Project documentation, 12
Eidesstattliche Erklärung, i Project goal, 46
Project Management, 1
Goals of an information system, 7 Project related communication, 8
Groupware systems: Classification, 26 Project reporting, 11
Groupware systems: Communication, 28
SMTP, 65
Implementation, 45 Struts, 61
JavaMail API, 70 Tasks of PM - Controlling, 5
Tasks of PM - Organization and com-
Knowledge development, 29
munication, 6
92
Tasks of PM - Planning, 4
Tasks of PM - Team leadership, 5
Tasks of project management, 4
Telephone, 15
Telephone conferences, 14
The three C-s, 8
Trends caused by CSC, 10
Types of project related comm., 11
Usability evaluation, 43
Usability test methods, 44
Video conferences, 14
XDoclet, 57
Zusammenfassung, ii
93