1. Personal dashboards for individual learning and
project awareness in social software engineering
Wolfgang Reinhardt, University of Paderborn, Germany – wolle@upb.de
Sebastian Nuhn, University of Paderborn, Germany – spider@upb.de
Abstract
Software is created by people, with people, and for people. These people work in
ever-changing environments, they have their particular backgrounds and act under
different conditions. The successful work in such teams of developers requires
regular learning as well as high dimension of coordination, communication, and
collaboration of the developers. To facilitate the cooperative work and individual
learning of those teams many synchronous and asynchronous tools, focusing on the
re-establishment of shared content and context are available. Those cooperative
development environments (CDE) are most often made to support single projects.
We introduced eCopSoft as a solution approach to overcome organizational and
usability issues for developers in social software engineering teams. eCopSoft’s
main desire is to support the individual developer in being more aware of actions and
tasks in his multiple projects and thus to improve individual learning opportunities
with the developers. eCopSoft provides customizable interfaces that connect data
from multiple projects and relevant information resources from outside the project,
hence serving as PWLE (Personal Working & Learning Environment). Furthermore
eCopSoft tries to enrich the project’s artifacts with additional metadata to expose the
connections between artifacts and developers from different data sources or
projects. In this paper we introduce the concept and prototypical implementation of
three types of dashboards: a) a community dashboard, b) a project dashboard, and
c) a my-eCopSoft dashboard that are to enhance the project and user awareness in
software teams. A dashboard is a software application that is able for hosting
multiple single-purpose mini applications. The developed dashboard concept is
geared to existing web dashboard approaches but as existing approaches did not fit
to the eCopSoft environment we decided to design and implement an own
dashboard based on an existing Adobe Flex codebase. Our dashboards are
designed to be executable in the browser and on the desktop using Adobe’s Flex
and AIR technologies. Doing this, it becomes feasible to synchronize the states and
views of the dashboards between the Web and the local version, maintaining the
work context of a learner. For learners in this enables context consistency across the
borders of applications and furthermore enhances group and artifact awareness
within the group of developers.
1. Introduction
The requirements for software solutions are constantly increasing. Both the technical
tasks as well as the internal qualities of the software must always meet higher
requirements. The development of modern software systems is a complex process
that is executed almost exclusively in cooperative software development teams no
matter whether the development takes place in companies, in university
environments or in open source applications. Within the development team the
technical, social and cultural backgrounds of members vary. As Altmann and
Pomberger (1999) point out, the cooperation within such teams and between the
team and other projects is one of the decisive factors for the success of a
project. The formation and coordination of teams is a difficult task, in which the

2. communication amongst and awareness about the project and the team members
are important.
The successful work in a development teams requires a high level of coordination,
communication, and cooperation of the developers. The size of teams varies from
small local groups to large globally distributed communities. As technical support for
the partially spatially and temporally separated working teams, different applications
are used. Booch and Brown (2003) classified those so-called collaborative
development environments (CDEs) and point out that these applications support
both, synchronous and asynchronous work but are often designed to only support
one single project. On the one hand, it is therefore necessary that new application
instances must be created for each new project. On the other hand, correlations
between different projects cannot be displayed. In addition, the artifacts of the
different applications within a project are seldom explicitly linked with each other.
This fact negatively influences the awareness of developers and project
artifacts. Through the above-mentioned problems with existing software solutions
used for software development, the transparency of the development process, the
awareness about people, processes and artifacts as well as the organization of the
teams is not supported properly.
In this paper we introduce a concept for three awareness dashboards tempting to
overcome these limitations and providing a customizable Personal Learning and
Working Environment interfacing our community-embedded collaborative
development environment (CCDE) eCopSoft (Reinhardt and Rinne, 2010). The main
endeavor of the dashboards is to enhance awareness within software development
projects, to support developers with a more compendious overview about their work
contexts and co-workers and finally to leverage communication and cooperation
within social software engineering projects.
2. Informal learning in social software engineering projects
The term social software engineering denotes both the engineering process of so
called social software and the software engineering within social relationship in
collaborative teams. For this paper the latter denotation is the focus of interest.
Studies show, that the main part of today’s software engineering is carried out in
teams, requiring many social interactions between the people involved in a project
(Jones, 1986, DeMarco and Lister, 1987, Ahmadi, 2008). Social activity thus
represents a substantial part of the daily work of a developer. Whereas network
structures in social networking sites (SNSs) mainly emerge by adding explicit
friendship connections between users, social networks in software engineering
mainly result from artifact-based sociality (see Knorr-Cetina’s (1997) effectuations
regarding sociality with objects). Developers do not just communicate with each
other – they connect through shared artifacts that may serve as boundary objects
(Star and Griesemer, 1989) to connect several communities. The social connections
normally exist only within a project even though many of the used artifacts come
from outside of the project. The consulted domain specific experts often do not
reside within the own organization, but in other communities. Learning thus takes
place in a personal learning network comprising domain expert, fellow developers
and relevant artifacts such as matured source code, examples, documents, and
other objects. Koper and Sloep (2003) as well as Siemens (2005) emphasize the
importance of learning in such connected learning networks.
In the last 15 years the social side of software engineering moved more and more in
the focus of research after software engineering be solely regarded as a domain of

3. technical interest. Research focused on optimization of data structures, algorithms
and software to support the developmental processes. The engineering process was
often regarded as a knowledge management project, where knowledge could be
shifted from one project to another, from one developer to his fellows. But Nonaka et
al. (2001) prod to the fact that “you cannot store knowledge“ because knowledge is a
rational capacity and not a transferable item. Nevertheless, the social interaction
between individuals in the process, where the developer is centered in the
development process and surrounded by eventually more knowledgeable peers
(Vygotsky, 1978) was long underestimated. Nowadays it became more obvious, that
the informal learning activities during water cooler talks and other ad-hoc
communications, in reciprocal help with upcoming issues and unofficial personal
relations are the situations where learning takes place in software engineering and
other learning systems. Informal learning is characterized as a process that does not
follow a specified curriculum but rather happens by accident, sporadically and
naturally during daily interactions and shared relationships. Cross (2006) shows that
the majority of individual learning is informal and happens when tacit knowledge
(Polyani, 1966) of an individual is communicated to another person, which cognizes,
interprets and internalizes the data and thus expands his own knowledge (see also
Nonaka and Takeushi, 1995).
Examples of such informal learning situations within social software engineering
projects are spontaneous meetings, short messages, phone calls but also
asynchronous communication like entries in bulletin boards, comments in source
code or comments in blogs. As hardly any formal training for developers takes place,
in software engineering informal learning is the only way to stay up to date. Previous
approaches for supporting ad hoc communication focus on intra-project
improvements and do not include experts from outside the project (Robillard, 1999).
Connecting with others, using artifacts and people from outside the own project –
and thus profit by the power of one’s learning network – seem to be a crucial factor
in supporting learning within a project (Siemens, 2005, Downes, 2005). The PLE
approach to facilitating user-centered, self-directed and reflective learning marks a
major shift from traditional institutional learning and has gained a lot of attention and
has matured in recent years. In PLEs learners are connecting with people and
resources of their choice, relevant for the individual learning goals and knowledge
deficits.
Regardless of the ambiguous definitions of knowledge and the claims for necessity
and importance for knowledge management, software engineering is a dynamic
process, which is reliant on latest know-what and know-how in the subject domain.
This knowledge evolves with technology, organizational culture and changing needs
of both the individual and the organization (Aurum, Daneshgar, Ward, 2008).
Knowledge management in software engineering can be improved by recognizing
the need for informal communication, perennial learning and interchange of data in
order to support the exchange of implicit knowledge amongst developers. Personal
Learning and Working Environments (PLWEs) thus should support awareness of
projects and fellow developers, allow for easy interaction with co-workers. Moreover,
PLWEs should support sharing of implicit knowledge and foster informal, ad hoc
exchange of short messages (Robillard and Robillard, 2000, Reinhardt, 2009) as
well as facilitating inter-project social networks in form of communities of interest.
Following one of the main PLE ideas (Wilson 2005, Educause, 2009) the user
interface for learners (developers) should be customizable and not limited with
regards to the composition and configuration of the content. For us, a combination

4. between web-based dashboard and desktop application with single-purpose mini-
applications that can be freely arranged and configured is a suitable approach for
supporting the request for user-centeredness and self-directed composition of
learning environments.
3. Theoretical foundation, solution concept and implementation of
eCopSoft dashboards
In the context of a student research project at the Computer Science Education
group at the University of Paderborn, the eCopSoft platform was created. eCopSoft
is a collaborative, event-based multi-project software development platform
incorporating various tools for coordination, cooperation and communication
between software development teams. Belonging to these tools is a community
application with bulletin boards, blogs, wiki and groups, an issue tracking system, a
version control system and a wiki. The eCopSoft platform facilitates the
organizational efforts by providing developers a one-click-deployment of new
projects with all the means for communication and cooperation that they desire
(Reinhardt and Rinne, 2010). The data from the single tools and projects are stored
in various semantic and relational databases and need to be provided to the user in
an understandable and easily to use system. The goal of the eCopSoft dashboards
is to combine the system-wide distributed data and to provide the developer with a
central access point to the stored data in order to enhance his project awareness
and ease his work. The customizable dashboards thereby allow the developer to
decide what data is display. The scope for visualization can be one single project or
aggregated data from multiple projects.
3.1 Dashboards to support learning and awareness in mashup environments
The concept of eCopSoft dashboards is based on the ideas of the Personal Learning
Environment (PLE) and the concepts of mashups. In the following we introduce two
established Web-based platforms, which already have been successfully integrated
dashboards. The aim is to derive properties from the existing systems that serve as
requirements for this concept. In IT systems, a dashboard represents an executive
information system user interface, usually comprising multiple single-purpose mini-
applications that are designed to be easy to handle and to allow comprehensive
customization. Following Sorenson (2002) most dashboards integrate “information
from multiple components into a unified display” following the now mainstream
design pattern of mashups.
The first examined platform is SourceForge1. SourceForge is a proprietary, free-to-
use platform for collaborative software development projects, whose aim is to
support teams of software developers with tools for software development in various
fields. SourceForge provides dashboards in the user and in the project area. Widgets
that can be placed within the dashboard visualize specific data from the respective
information sources. Available widgets are selectable from a shelf at the top of the
dashboard. Widgets in the project area are primarily visualizing data from the
available software development tools of the project. In contrast, user area widgets
are providing cross-project or general data of the SourceForge platform. The
developer decides what widgets are shown in the respective areas by enabling or
1
http://sourceforge.net/

5. disabling individual widgets. The two dashboard areas are supporting the developer
in the process of keeping track of his various projects. The division of the dashboard
into different areas such as project and user area flows into the concept of the
eCopSoft dashboard.
The second examined platform is iGoogle2. The central feature of the platform is to
encapsulate information and services from various sources in the so-called gadgets
that are provided to the user within its dashboards. Similar to the SourceForge
platform, the gadgets can be selected from a directory service and be placed within
the three-column iGoogle Dashboards by the user. Noteworthy is the easy authoring
of new gadgets for iGoogle. This is made possible by a three-component gadget
architecture that allows the developer to develop and publish new gadgets with
common techniques such as XML, JavaScript and HTML. In addition to a web-based
runtime environment, iGoogle offers also a desktop runtime environment for
Windows and Linux. Decoupling the gadgets of the Web-based platform gives users
a highly flexible tool to embed the latest information within their individual working
environment. This idea also flows into the concept of the eCopSoft dashboard.
As iGoogle already provides essential characteristics of the desired eCopSoft
dashboards one could be suggesting building on this platform. At time of writing,
Google only supports the development of iGoogle gadgets; an adaptation of the
runtime environment for the eCopSoft platform is currently not possible. Google
currently offers integration capabilities for gadgets in their own websites and projects
but this is limited to viewing those gadgets. For now, there is no runtime environment
available, which makes it possible to arrange these gadgets within the own project,
or to allow a communication between the gadgets. Moreover, the SourceForge
dashboards can only be used within the proprietary framework of their webpage.
Those circumstances require that a new dashboard concept be designed for the
application within the eCopSoft platform.
3.2 Solution concept
Based on these findings, further requirements on the eCopSoft dashboards are
specified in the following section. To avoid confusion with existing dashboards
approaches and the used terms widget3 and gadget, a mini-application within our
dashboard is called a pod. A pod prepares data from a data source and displays this
data within the dashboard. The eCopSoft dashboard should support developers
taking part in multiple projects simultaneously with a condensed view on their
working activities and their professional networks comprising people and artifacts.
Doing so the dashboard shall ease the cognitive load during re-contextualization and
re-focusing on new tasks and contexts and simplifying cross-project networking and
sharing.
2
http://www.google.com/ig
3
Besides the usage of the term within the SourceForge platform, the term widget is
often related to a W3C specification for a client-side application that is authored
using Web standards, packaged into a zip archive together with a configuration file
and executable in web documents (see the W3C specification at
http://www.w3.org/TR/widgets/.

6. 3.2.1 Extensibility
The idea of the eCopSoft dashboard is to provide a central information point for
members of the eCopSoft community. In its current implementation eCopSoft
provides applications like wiki, issues tracker, project mail, and version control. The
data from these sources are shown in eCopSoft dashboard. In future increments the
platform will be extended by additional services like blogs and microblogs or social
bookmarking. Data from those services should also be accessible within the
dashboard and custom pods shall be made available. A simple pod deployment is
therefore one of the key requirements of the eCopSoft dashboards and will
significantly contribute to its extensibility. The extensibility of eCopSoft dashboards is
further relevant as pods should not only display data from within the platform but also
external data from data sources outside eCopSoft (e.g. calendar data, RSS).
3.2.2 Flexibility
In the fashion of the SourceForge platform, the eCopSoft dashboards should be
available for different objectives. In the first prototypical implementation we will
realize the following three dashboard types:
• A community dashboard,
• A project dashboards, and
• A user-centered dashboard called my-eCopSoft.
The dashboards make different demands on their runtime environment and provide
different pods that can be used.
3.2.3 Customizability
A PLE should be individually customizable to support the informal learning process
of the user as much as possible. This refers not only to graphical design and
changing colors, but also to the information to be displayed, their arrangement and
level of detail. The user-specific settings should be stored on the server. Following
the stateless client design pattern, the state of the eCopSoft dashboard should be
recovered from the latest stored settings file whenever a user comes back to his
dashboard. The dashboard configuration should be stored for all previously
mentioned dashboards.
3.2.4 Communication
Derived from the above-mentioned earlier dashboard systems, in particular the
architecture of the iGoogle gadget and its runtime environment, the eCopSoft
dashboard architecture will comprise the following components:
• The eCopSoft dashboards as runtime environment,
• Pods as mini-applications, and
• Data sources for the pods within the eCopSoft server.
Table 1 lists the conceptual communication between the three components. The
following discusses the communication between different dashboards and on
communication between pods.
3.3 Architectural design and implementation of the solution
The architectural concept of the eCopSoft dashboards is based on two basic
components that are divided into modules. Following the client-server-principle one

7. module is used as data source and the other as data consumer. The respective
communication pairs and their positioning within the basic components are shown in
Figure 1.
Table 1: Conceptual communication possibilities between the central
components of the eCopSoft dashboard concept
community my- project desktop pod eCopSoft
dashboard eCopSoft dashboard dashboard server
dashboard
community  
dashboard
my-eCopSoft  
dashboard
project   
dashboard
desktop    
dashboard
pod      
eCopSoft     
server
Figure 1: Schematic overview of the client-server architecture
The first basic component is the Dashboard-Manager, whose responsibility is to
manage the pods within the dashboard area and to visualize the dashboard for the
client. The second basic component is the pod itself. A pod visualizes data from any

8. data source and provides them to the user. The modular design ensures scalability
of the system. Complex calculations can be performed server-side to spare the
resources of the client. The pod is connected to the server via its server-side living
pod adapter.
The main task of the Dashboard-Manager is to manage the pods and to arrange
them within the dashboards. Additionally, it coordinates and controls the data flow
between the dashboards and the server and is thus in charge of exerting the
communication between the components (see Table 1). The information referred to
in Section 3.2.2 are represented by classes of dashboards, whose specific tasks ill
be explained below:
• Dashboard class projectweb: each user of the eCopSoft system can participate
in multiple projects. The purpose of this dashboard class is to provide the
developer with information from a selected project. It mainly serves pods that
rely on project-specific data, for example open tickets in the current project,
the latest wiki entries or contacting other project members.
• Dashboard class projectdesktop: This dashboard class represents an addition to
the projectweb class. This dashboard allows interacting with project-specific
data on the desktop of the user.
• Dashboard class communityweb: In order to provide a centralized, user-
independent and cross-project information point to the users of the eCopSoft
platform this dashboard class is necessary. The pods within this class are
visualizing data like new members, latest wiki changes, new projects and calls
for participation.
• Dashboard class my-eCopSoft: The purpose of this class dashboard is to
provide developers with a central place in which to cross-project information is
presented. For example an issue pod aggregates the issues from all projects
the user is assigned to.
The dashboard manager takes the following tasks for each dashboard class:
• Initializing the dashboard,
• Adding and removing pods,
• Customizing the dashboards,
• Assuring pod-to-pod communication, and
• Assuring dashboard-to-dashboard communication.
3.3.1 Initializing the dashboard
During the initialization of the eCopSoft dashboards, the Dashboard-Manager is
looking for the following parameters: (1) URI of the dashboard adapter, (2)
dashboard class, (3) user name, (4) user password, (5) name of the project. The first
parameter is used for the connection between Dashboard-Manager and dashboard
adapter. Depending on the dashboard class the initialization is performed. To
generate the dashboard interface the Dashboard-Manager needs information
describing which pods are loaded into the single views and where the pods are to be
place in the respective view. The server-side dashboard adapter manages this
information. Using the dashboard class, the corresponding configuration file from the
server-side dashboard adapter is located and its content is transferred to the
Dashboard-Manager. During the initialization of the dashboards different containers

9. within the Dashboard-Manager are filled with content. Figure 2 depicts the containers
and their respective components.
Figure 2: Containers in the Dashboard-Manager and their components
View-Container
To meet the requirements of Section 3.2.3 for a customizable surface, the view
container provides basic operations for the arrangement of pods. These include the
administration of maximized and minimized pods within a view and the positioning of
the pods within the surface. Moreover, it is possible to semantically group pods in
views. Multiple views are visualized as tabs in the dashboard, allowing the easy
extension of the dashboards. Each view container is filled with pods and a pod
container surrounds each pod.
Pod-Container
Each pod is providing a basic set of functionalities that are needed for the realization
of the eCopSoft dashboard. Amongst them are (1) minimizing, maximizing and
closing of pods, (2) restoring of minimized pods, (3) loading of a pod in the view
container and (4) calculating the size and location of a pod within a view.
During the initialization of the eCopSoft dashboards, each pod-container is assigned
to one view-container
If any of the above-mentioned basic functions of the pod-container is called, the
associated view container is being updated. Depending on the function it performed
all other pods within the same view are updated. If for example, a pod container is
minimized or closed then the view-container calculates the size of the cells and re-
adjusts the size of the other pods (cf. Figure 3). Once the container is initialized with
the basic information, the actual pods in the pod container are loaded and the user
can use the dashboard.
3.3.2 Pod-to-pod communication
In addition to the initialization, the Dashboard-Manger secures communication
between active pods within the eCopSoft dashboards. Therefore, the Dashboard-
Manager provides an interface that accepts pod events and broadcasts those events
to all active pods within the dashboards. The components of pod events are: (1) the
event-source-PID, (2) the event type and (3) additional event information. The event-
source-PID is set by the producing pod and serves as unique identifier of the
pod. Using the event type, the receiving pod determines whether it responds to the

10. received event or not. The event information contains information about the pod
event and is stored as key value pairs. Using this information the producing pod can
define what actions the receiving pods should be executing.
Figure 3: Adjustment of the visible cells in the dashboard after the closing of a
pod
Figure 4: Distribution of events between pods
3.3.1 Dashboard-to-dashboard communication
One key requirement of the eCopSoft dashboard concept is to provide dashboards
for both the Web platform as well as for the desktop. The dashboard classes
projectweb and projectdesktop realize this requirement and may be synchronized with
each other. This is made possible through a synchronizer, which is integrated in both
dashboards. The task of the synchronizers is to share events between the partnering
dashboards and to execute the related tasks. To synchronize the dashboards, both
dashboards need to connect with each other. Regardless of the technology used, it
can proceed as follows:
The projectdesktop dashboard on the user’s device provides a predefined service
endpoint. The projectweb dashboard then connects to this endpoint. During
connection, the dynamic service endpoint of the projectweb is transmitted to the
desktop dashboard. At the time of the connection the dashboards can exchange

11. data bidirectional. Regarding the synchronized events the concept supports the
following operations:
• Matching the key-value pairs of a pod,
• Minimizing, maximizing and closing of a pod,
• Changing the position of a pod,
• Adding and deleting of pods from a dashboard.
3.4 Implementation
The proposed concept of eCopSoft dashboards was implemented as a prototype
and integrated in the eCopSoft platform (see Reinhardt and Rinne (2010) for more
information about the implementation of the eCopSoft server). The server-side
components are implemented as Java OSGI bundles. The client-side components
are developed with Adobe Flex 44. Flex allows the easy integration of the dashboard
in the PHP-based interface of the eCopSoft platform. On the other hand Flex offers
the possibility to easily provide the eCopSoft dashboards as desktop application. The
dashboard manager was built on top of the modified and extended Flex 3 dashboard
WASI5 that already implemented the basic functions of the proposed eCopSoft
dashboards. Table 2 shows, which features were modified in the existing
implementation and added during our implementation.
Table 2: Modified and added functions of the Flex-based WASI dashboard
function modified added
prepare views 
prepare pods 
layout pods 
drag & drop pods 
minimize pods 
maximize pods 
close pods 
save pod 
configuration
save views 
create views 
dynamically load 
pods
The Web-based dashboards are implemented as Flex 4 applications (see Figure 5
for a screenshot). The desktop dashboard is a derivation of the Web-based
dashboards with many reworking and developed using the Adobe AIR runtime. The
synchronization between the desktop and web dashboards is implemented using the
4
http://www.adobe.com/products/flex/
5
http://www.adobe.com/devnet/flex/samples/dashboard/dashboard.html

12. Flash concept of LocalConnections. For now the following events are synchronized
between the two dashboards: (1) adding new pods, (2) minimizing a pod, (3)
restoring a pod and (4) closing a pod.
5. Recapitulation and application possibilities
In this paper we introduced a dashboard concept for the community-embedded
collaborative development environment eCopSoft whose main goal is to support
developers in keeping track about their activities in multiple projects and thus
enhancing the overall person and project awareness. Following the goals on
Personal Learning Environments and taking into account existing dashboard
implementations we implemented a Flex-based Web dashboard that synchronizes its
configuration with a desktop equivalent and thus minimizing the developers need to
re-contextualizing when changing his working environment. The dashboards were
integrated into the eCopSoft server and tested during the student research project
eCopSoft. The tests showed that the prototypical implementation got well accepted
and enhanced developers overall overview about their cross-project tasks and
connections between fellow developers and other projects. On the other hand the
tests also revealed room for conceptual and developmental makeover of the solution
especially regarding stability and synchronization between the dashboards.

13. Figure 5: Web-based project dashboard for the project TightVNC showing a
member pod and a ticket pod
Figure 6: Synchronized desktop dashboard for the project TightVNC showing a
member pod and a ticket pod
6. References
Ahmadi, N., Jazayeri, M., Lelli, F. and Nescic, S. 2008. A survey of social software
engineering. Proceedings of 23rd IEEE/ACM International Conference on Automated
Software Engineering - Workshops, pages 1–12.
Altmann, J. and Pomberger, G. 1999. Cooperative Software Development:
Concepts, Model and Tools. In Firesmith, D. and Riehle, R. and Pour, G. and Meyer,
B. (eds.) Tools 30:194 et seq.
Aurum, A., Daneshgar, F. and Ward, J. 2008. Investigating Knowledge Management
practices in software development organisations – An Australian experience.
Information and Software Technology, 50:511-533.
Booch, G. and Brown, A. W. 2003. Collaborative development environments.
Advances in Computers, 59:2–29.
Cross, J. 2006. Informal Learning – Rediscovering the Pathways that inspire
innovation and performance. Pfeiffer.

14. DeMarco, T. and Lister, T. 1987. Peopleware: productive projects and teams. Dorset
House Publishing, New York.
Downes, S. 2005. E-learning 2.0. ACM eLearn Magazine, 2005(10).
Educause Learning Initiative. 2009. 7 things you should know about … Personal
Learning Environments.
Jones, C. 1986. Programming productivity. McGraw-Hill, New York.
Knorr-Cetina, K. 1997. Sociality with Objects: Social Relations in Postsocial
Knowledge Societies. Theory, Culture & Society, 14(4):1-30, 1997
Koper, R. and Sloep, P. 2003. Learning Networks - connecting people,
organizations, autonomous agents and learning resources to establish the
emergence of effective lifelong learning. Programme plan, Open University of the
Netherlands.
Nonaka, I. and Takeuchi, H. 1995. The Knowledge Creating Company: How
Japanese Companies Create the Dynamics of Innovation. Oxford University Press.
Nonaka, I. et al. 2001. Emergence of “Ba”. Knowledge Emergence.
Polyani, M. 1966. The Tacit Dimension. Routledge & Kegan Paul, London.
Reinhardt, W. 2009: Communication is the key – Support Durable Knowledge
Sharing in Software Engineering by Microblogging. Proceedings of Software
Engineering 2009.
Reinhardt, W. and Rinne, S. 2010. An architecture to support learning, awareness,
and transparency in social software engineering. In Ebner, M. and Klamma, R. and
Schaffert, S. (eds.) International Journal of Emerging Technologies in Learning
(iJET): Special Issue: ICL2009 - MashUps for Learning, 5.
Sorenson, M. 2002. Dictionary definition of dashboards.
http://searchcio.techtarget.com/sDefinition/0,,sid182_gci804078,00.html
Robillard, P. N. 1999. The role of knowledge management in software development.
Communications of the ACM, 42(1):87-94.
Robillard, P. N. and Robillard, M. P. 2000. Types of collaborative work in software
engineering. Journal of Systems and Software, 53(3):219–224.
Siemens, G. 2005. Connectivism: A learning theory for the digital age. International
Journal of Instructional Technology and Distance Learning, 2(1):3–10.
Star, S. L. and Griesemer, J. R. 1989. Institutional ecology, ’translations’ and
boundary objects: Amateurs and professionals in Berkeley’s museum of vertebrate
zoology. Social Studies of Science, 19(3):387–420.
Vygotsky, L.S. 1962. Thought and Language. Cambridge University Press.
Vygotsky, L.S. 1978. Mind and society: The development of higher mental
processes. Harvard University Press.
Wilson, S. 2005. Architecture of Virtual Spaces and the Future of VLEs.
http://zope.cetis.ac.uk/members/scott/resources/itslearning.ppt