Personal dashboards for individual learning and project awareness in social software engineering


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Personal dashboards for individual learning and project awareness in social software engineering

  1. 1. Personal dashboards for individual learning and project awareness in social software engineering Wolfgang Reinhardt, University of Paderborn, Germany – Sebastian Nuhn, University of Paderborn, Germany – spider@upb.deAbstractSoftware is created by people, with people, and for people. These people work inever-changing environments, they have their particular backgrounds and act underdifferent conditions. The successful work in such teams of developers requiresregular learning as well as high dimension of coordination, communication, andcollaboration of the developers. To facilitate the cooperative work and individuallearning of those teams many synchronous and asynchronous tools, focusing on there-establishment of shared content and context are available. Those cooperativedevelopment environments (CDE) are most often made to support single projects.We introduced eCopSoft as a solution approach to overcome organizational andusability issues for developers in social software engineering teams. eCopSoft’smain desire is to support the individual developer in being more aware of actions andtasks in his multiple projects and thus to improve individual learning opportunitieswith the developers. eCopSoft provides customizable interfaces that connect datafrom multiple projects and relevant information resources from outside the project,hence serving as PWLE (Personal Working & Learning Environment). FurthermoreeCopSoft tries to enrich the project’s artifacts with additional metadata to expose theconnections between artifacts and developers from different data sources orprojects. In this paper we introduce the concept and prototypical implementation ofthree types of dashboards: a) a community dashboard, b) a project dashboard, andc) a my-eCopSoft dashboard that are to enhance the project and user awareness insoftware teams. A dashboard is a software application that is able for hostingmultiple single-purpose mini applications. The developed dashboard concept isgeared to existing web dashboard approaches but as existing approaches did not fitto the eCopSoft environment we decided to design and implement an owndashboard based on an existing Adobe Flex codebase. Our dashboards aredesigned to be executable in the browser and on the desktop using Adobe’s Flexand AIR technologies. Doing this, it becomes feasible to synchronize the states andviews of the dashboards between the Web and the local version, maintaining thework context of a learner. For learners in this enables context consistency across theborders of applications and furthermore enhances group and artifact awarenesswithin the group of developers.1. IntroductionThe requirements for software solutions are constantly increasing. Both the technicaltasks as well as the internal qualities of the software must always meet higherrequirements. The development of modern software systems is a complex processthat is executed almost exclusively in cooperative software development teams nomatter whether the development takes place in companies, in universityenvironments or in open source applications. Within the development team thetechnical, social and cultural backgrounds of members vary. As Altmann andPomberger (1999) point out, the cooperation within such teams and between theteam and other projects is one of the decisive factors for the success of aproject. The formation and coordination of teams is a difficult task, in which the
  2. 2. communication amongst and awareness about the project and the team membersare 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 fromsmall local groups to large globally distributed communities. As technical support forthe partially spatially and temporally separated working teams, different applicationsare used. Booch and Brown (2003) classified those so-called collaborativedevelopment environments (CDEs) and point out that these applications supportboth, synchronous and asynchronous work but are often designed to only supportone single project. On the one hand, it is therefore necessary that new applicationinstances must be created for each new project. On the other hand, correlationsbetween different projects cannot be displayed. In addition, the artifacts of thedifferent applications within a project are seldom explicitly linked with each other.This fact negatively influences the awareness of developers and projectartifacts. Through the above-mentioned problems with existing software solutionsused for software development, the transparency of the development process, theawareness about people, processes and artifacts as well as the organization of theteams is not supported properly.In this paper we introduce a concept for three awareness dashboards tempting toovercome these limitations and providing a customizable Personal Learning andWorking Environment interfacing our community-embedded collaborativedevelopment environment (CCDE) eCopSoft (Reinhardt and Rinne, 2010). The mainendeavor of the dashboards is to enhance awareness within software developmentprojects, to support developers with a more compendious overview about their workcontexts and co-workers and finally to leverage communication and cooperationwithin social software engineering projects.2. Informal learning in social software engineering projectsThe term social software engineering denotes both the engineering process of socalled social software and the software engineering within social relationship incollaborative 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 inteams, requiring many social interactions between the people involved in a project(Jones, 1986, DeMarco and Lister, 1987, Ahmadi, 2008). Social activity thusrepresents a substantial part of the daily work of a developer. Whereas networkstructures in social networking sites (SNSs) mainly emerge by adding explicitfriendship connections between users, social networks in software engineeringmainly result from artifact-based sociality (see Knorr-Cetina’s (1997) effectuationsregarding sociality with objects). Developers do not just communicate with eachother – they connect through shared artifacts that may serve as boundary objects(Star and Griesemer, 1989) to connect several communities. The social connectionsnormally exist only within a project even though many of the used artifacts comefrom outside of the project. The consulted domain specific experts often do notreside within the own organization, but in other communities. Learning thus takesplace in a personal learning network comprising domain expert, fellow developersand relevant artifacts such as matured source code, examples, documents, andother objects. Koper and Sloep (2003) as well as Siemens (2005) emphasize theimportance of learning in such connected learning networks.In the last 15 years the social side of software engineering moved more and more inthe focus of research after software engineering be solely regarded as a domain of
  3. 3. technical interest. Research focused on optimization of data structures, algorithmsand software to support the developmental processes. The engineering process wasoften regarded as a knowledge management project, where knowledge could beshifted from one project to another, from one developer to his fellows. But Nonaka etal. (2001) prod to the fact that “you cannot store knowledge“ because knowledge is arational capacity and not a transferable item. Nevertheless, the social interactionbetween individuals in the process, where the developer is centered in thedevelopment process and surrounded by eventually more knowledgeable peers(Vygotsky, 1978) was long underestimated. Nowadays it became more obvious, thatthe informal learning activities during water cooler talks and other ad-hoccommunications, in reciprocal help with upcoming issues and unofficial personalrelations are the situations where learning takes place in software engineering andother learning systems. Informal learning is characterized as a process that does notfollow a specified curriculum but rather happens by accident, sporadically andnaturally during daily interactions and shared relationships. Cross (2006) shows thatthe 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 alsoNonaka and Takeushi, 1995).Examples of such informal learning situations within social software engineeringprojects are spontaneous meetings, short messages, phone calls but alsoasynchronous communication like entries in bulletin boards, comments in sourcecode 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. Previousapproaches for supporting ad hoc communication focus on intra-projectimprovements 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 factorin supporting learning within a project (Siemens, 2005, Downes, 2005). The PLEapproach to facilitating user-centered, self-directed and reflective learning marks amajor shift from traditional institutional learning and has gained a lot of attention andhas matured in recent years. In PLEs learners are connecting with people andresources of their choice, relevant for the individual learning goals and knowledgedeficits.Regardless of the ambiguous definitions of knowledge and the claims for necessityand importance for knowledge management, software engineering is a dynamicprocess, which is reliant on latest know-what and know-how in the subject domain.This knowledge evolves with technology, organizational culture and changing needsof both the individual and the organization (Aurum, Daneshgar, Ward, 2008).Knowledge management in software engineering can be improved by recognizingthe need for informal communication, perennial learning and interchange of data inorder to support the exchange of implicit knowledge amongst developers. PersonalLearning and Working Environments (PLWEs) thus should support awareness ofprojects and fellow developers, allow for easy interaction with co-workers. Moreover,PLWEs should support sharing of implicit knowledge and foster informal, ad hocexchange of short messages (Robillard and Robillard, 2000, Reinhardt, 2009) aswell as facilitating inter-project social networks in form of communities of interest.Following one of the main PLE ideas (Wilson 2005, Educause, 2009) the userinterface for learners (developers) should be customizable and not limited withregards to the composition and configuration of the content. For us, a combination
  4. 4. between web-based dashboard and desktop application with single-purpose mini-applications that can be freely arranged and configured is a suitable approach forsupporting the request for user-centeredness and self-directed composition oflearning environments.3. Theoretical foundation, solution concept and implementation ofeCopSoft dashboardsIn the context of a student research project at the Computer Science Educationgroup at the University of Paderborn, the eCopSoft platform was created. eCopSoftis a collaborative, event-based multi-project software development platformincorporating various tools for coordination, cooperation and communicationbetween software development teams. Belonging to these tools is a communityapplication with bulletin boards, blogs, wiki and groups, an issue tracking system, aversion control system and a wiki. The eCopSoft platform facilitates theorganizational efforts by providing developers a one-click-deployment of newprojects with all the means for communication and cooperation that they desire(Reinhardt and Rinne, 2010). The data from the single tools and projects are storedin various semantic and relational databases and need to be provided to the user inan understandable and easily to use system. The goal of the eCopSoft dashboardsis to combine the system-wide distributed data and to provide the developer with acentral access point to the stored data in order to enhance his project awarenessand ease his work. The customizable dashboards thereby allow the developer todecide what data is display. The scope for visualization can be one single project oraggregated data from multiple projects.3.1 Dashboards to support learning and awareness in mashup environmentsThe concept of eCopSoft dashboards is based on the ideas of the Personal LearningEnvironment (PLE) and the concepts of mashups. In the following we introduce twoestablished Web-based platforms, which already have been successfully integrateddashboards. The aim is to derive properties from the existing systems that serve asrequirements for this concept. In IT systems, a dashboard represents an executiveinformation system user interface, usually comprising multiple single-purpose mini-applications that are designed to be easy to handle and to allow comprehensivecustomization. Following Sorenson (2002) most dashboards integrate “informationfrom multiple components into a unified display” following the now mainstreamdesign 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 tosupport teams of software developers with tools for software development in variousfields. SourceForge provides dashboards in the user and in the project area. Widgetsthat can be placed within the dashboard visualize specific data from the respectiveinformation sources. Available widgets are selectable from a shelf at the top of thedashboard. Widgets in the project area are primarily visualizing data from theavailable software development tools of the project. In contrast, user area widgetsare providing cross-project or general data of the SourceForge platform. Thedeveloper decides what widgets are shown in the respective areas by enabling or1
  5. 5. disabling individual widgets. The two dashboard areas are supporting the developerin the process of keeping track of his various projects. The division of the dashboardinto different areas such as project and user area flows into the concept of theeCopSoft dashboard.The second examined platform is iGoogle2. The central feature of the platform is toencapsulate information and services from various sources in the so-called gadgetsthat are provided to the user within its dashboards. Similar to the SourceForgeplatform, the gadgets can be selected from a directory service and be placed withinthe three-column iGoogle Dashboards by the user. Noteworthy is the easy authoringof new gadgets for iGoogle. This is made possible by a three-component gadgetarchitecture that allows the developer to develop and publish new gadgets withcommon techniques such as XML, JavaScript and HTML. In addition to a web-basedruntime environment, iGoogle offers also a desktop runtime environment forWindows and Linux. Decoupling the gadgets of the Web-based platform gives usersa highly flexible tool to embed the latest information within their individual workingenvironment. This idea also flows into the concept of the eCopSoft dashboard.As iGoogle already provides essential characteristics of the desired eCopSoftdashboards one could be suggesting building on this platform. At time of writing,Google only supports the development of iGoogle gadgets; an adaptation of theruntime environment for the eCopSoft platform is currently not possible. Googlecurrently offers integration capabilities for gadgets in their own websites and projectsbut this is limited to viewing those gadgets. For now, there is no runtime environmentavailable, which makes it possible to arrange these gadgets within the own project,or to allow a communication between the gadgets. Moreover, the SourceForgedashboards can only be used within the proprietary framework of their webpage.Those circumstances require that a new dashboard concept be designed for theapplication within the eCopSoft platform.3.2 Solution conceptBased on these findings, further requirements on the eCopSoft dashboards arespecified in the following section. To avoid confusion with existing dashboardsapproaches and the used terms widget3 and gadget, a mini-application within ourdashboard is called a pod. A pod prepares data from a data source and displays thisdata within the dashboard. The eCopSoft dashboard should support developerstaking part in multiple projects simultaneously with a condensed view on theirworking activities and their professional networks comprising people and artifacts.Doing so the dashboard shall ease the cognitive load during re-contextualization andre-focusing on new tasks and contexts and simplifying cross-project networking andsharing.2 Besides the usage of the term within the SourceForge platform, the term widget isoften related to a W3C specification for a client-side application that is authoredusing Web standards, packaged into a zip archive together with a configuration fileand executable in web documents (see the W3C specification at
  6. 6. 3.2.1 ExtensibilityThe idea of the eCopSoft dashboard is to provide a central information point formembers of the eCopSoft community. In its current implementation eCopSoftprovides applications like wiki, issues tracker, project mail, and version control. Thedata from these sources are shown in eCopSoft dashboard. In future increments theplatform will be extended by additional services like blogs and microblogs or socialbookmarking. Data from those services should also be accessible within thedashboard and custom pods shall be made available. A simple pod deployment istherefore one of the key requirements of the eCopSoft dashboards and willsignificantly contribute to its extensibility. The extensibility of eCopSoft dashboards isfurther relevant as pods should not only display data from within the platform but alsoexternal data from data sources outside eCopSoft (e.g. calendar data, RSS).3.2.2 FlexibilityIn the fashion of the SourceForge platform, the eCopSoft dashboards should beavailable for different objectives. In the first prototypical implementation we willrealize 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 providedifferent pods that can be used.3.2.3 CustomizabilityA PLE should be individually customizable to support the informal learning processof the user as much as possible. This refers not only to graphical design andchanging colors, but also to the information to be displayed, their arrangement andlevel of detail. The user-specific settings should be stored on the server. Followingthe stateless client design pattern, the state of the eCopSoft dashboard should berecovered from the latest stored settings file whenever a user comes back to hisdashboard. The dashboard configuration should be stored for all previouslymentioned dashboards.3.2.4 CommunicationDerived from the above-mentioned earlier dashboard systems, in particular thearchitecture of the iGoogle gadget and its runtime environment, the eCopSoftdashboard 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. Thefollowing discusses the communication between different dashboards and oncommunication between pods.3.3 Architectural design and implementation of the solutionThe architectural concept of the eCopSoft dashboards is based on two basiccomponents that are divided into modules. Following the client-server-principle one
  7. 7. module is used as data source and the other as data consumer. The respectivecommunication pairs and their positioning within the basic components are shown inFigure 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 dashboardcommunity  dashboardmy-eCopSoft  dashboardproject   dashboarddesktop    dashboardpod      eCopSoft     serverFigure 1: Schematic overview of the client-server architectureThe first basic component is the Dashboard-Manager, whose responsibility is tomanage the pods within the dashboard area and to visualize the dashboard for theclient. The second basic component is the pod itself. A pod visualizes data from any
  8. 8. data source and provides them to the user. The modular design ensures scalabilityof the system. Complex calculations can be performed server-side to spare theresources of the client. The pod is connected to the server via its server-side livingpod adapter.The main task of the Dashboard-Manager is to manage the pods and to arrangethem within the dashboards. Additionally, it coordinates and controls the data flowbetween the dashboards and the server and is thus in charge of exerting thecommunication between the components (see Table 1). The information referred toin Section 3.2.2 are represented by classes of dashboards, whose specific tasks illbe 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 dashboardDuring the initialization of the eCopSoft dashboards, the Dashboard-Manager islooking 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 firstparameter is used for the connection between Dashboard-Manager and dashboardadapter. Depending on the dashboard class the initialization is performed. Togenerate the dashboard interface the Dashboard-Manager needs informationdescribing which pods are loaded into the single views and where the pods are to beplace in the respective view. The server-side dashboard adapter manages thisinformation. Using the dashboard class, the corresponding configuration file from theserver-side dashboard adapter is located and its content is transferred to theDashboard-Manager. During the initialization of the dashboards different containers
  9. 9. within the Dashboard-Manager are filled with content. Figure 2 depicts the containersand their respective components.Figure 2: Containers in the Dashboard-Manager and their componentsView-ContainerTo meet the requirements of Section 3.2.3 for a customizable surface, the viewcontainer provides basic operations for the arrangement of pods. These include theadministration of maximized and minimized pods within a view and the positioning ofthe pods within the surface. Moreover, it is possible to semantically group pods inviews. Multiple views are visualized as tabs in the dashboard, allowing the easyextension of the dashboards. Each view container is filled with pods and a podcontainer surrounds each pod.Pod-ContainerEach pod is providing a basic set of functionalities that are needed for the realizationof the eCopSoft dashboard. Amongst them are (1) minimizing, maximizing andclosing of pods, (2) restoring of minimized pods, (3) loading of a pod in the viewcontainer and (4) calculating the size and location of a pod within a view.During the initialization of the eCopSoft dashboards, each pod-container is assignedto one view-containerIf any of the above-mentioned basic functions of the pod-container is called, theassociated view container is being updated. Depending on the function it performedall other pods within the same view are updated. If for example, a pod container isminimized 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 withthe basic information, the actual pods in the pod container are loaded and the usercan use the dashboard.3.3.2 Pod-to-pod communicationIn addition to the initialization, the Dashboard-Manger secures communicationbetween active pods within the eCopSoft dashboards. Therefore, the Dashboard-Manager provides an interface that accepts pod events and broadcasts those eventsto all active pods within the dashboards. The components of pod events are: (1) theevent-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 thepod. Using the event type, the receiving pod determines whether it responds to the
  10. 10. received event or not. The event information contains information about the podevent and is stored as key value pairs. Using this information the producing pod candefine what actions the receiving pods should be executing.Figure 3: Adjustment of the visible cells in the dashboard after the closing of a podFigure 4: Distribution of events between pods3.3.1 Dashboard-to-dashboard communicationOne key requirement of the eCopSoft dashboard concept is to provide dashboardsfor both the Web platform as well as for the desktop. The dashboard classesprojectweb and projectdesktop realize this requirement and may be synchronized witheach other. This is made possible through a synchronizer, which is integrated in bothdashboards. The task of the synchronizers is to share events between the partneringdashboards and to execute the related tasks. To synchronize the dashboards, bothdashboards need to connect with each other. Regardless of the technology used, itcan proceed as follows:The projectdesktop dashboard on the user’s device provides a predefined serviceendpoint. The projectweb dashboard then connects to this endpoint. Duringconnection, the dynamic service endpoint of the projectweb is transmitted to thedesktop dashboard. At the time of the connection the dashboards can exchange
  11. 11. data bidirectional. Regarding the synchronized events the concept supports thefollowing 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 ImplementationThe proposed concept of eCopSoft dashboards was implemented as a prototypeand integrated in the eCopSoft platform (see Reinhardt and Rinne (2010) for moreinformation about the implementation of the eCopSoft server). The server-sidecomponents are implemented as Java OSGI bundles. The client-side componentsare developed with Adobe Flex 44. Flex allows the easy integration of the dashboardin the PHP-based interface of the eCopSoft platform. On the other hand Flex offersthe possibility to easily provide the eCopSoft dashboards as desktop application. Thedashboard manager was built on top of the modified and extended Flex 3 dashboardWASI5 that already implemented the basic functions of the proposed eCopSoftdashboards. Table 2 shows, which features were modified in the existingimplementation 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  podsThe Web-based dashboards are implemented as Flex 4 applications (see Figure 5for a screenshot). The desktop dashboard is a derivation of the Web-baseddashboards with many reworking and developed using the Adobe AIR runtime. Thesynchronization between the desktop and web dashboards is implemented using the4
  12. 12. Flash concept of LocalConnections. For now the following events are synchronizedbetween the two dashboards: (1) adding new pods, (2) minimizing a pod, (3)restoring a pod and (4) closing a pod.5. Recapitulation and application possibilitiesIn this paper we introduced a dashboard concept for the community-embeddedcollaborative development environment eCopSoft whose main goal is to supportdevelopers in keeping track about their activities in multiple projects and thusenhancing the overall person and project awareness. Following the goals onPersonal Learning Environments and taking into account existing dashboardimplementations we implemented a Flex-based Web dashboard that synchronizes itsconfiguration with a desktop equivalent and thus minimizing the developers need tore-contextualizing when changing his working environment. The dashboards wereintegrated into the eCopSoft server and tested during the student research projecteCopSoft. The tests showed that the prototypical implementation got well acceptedand enhanced developers overall overview about their cross-project tasks andconnections between fellow developers and other projects. On the other hand thetests also revealed room for conceptual and developmental makeover of the solutionespecially regarding stability and synchronization between the dashboards.
  13. 13. Figure 5: Web-based project dashboard for the project TightVNC showing a member pod and a ticket podFigure 6: Synchronized desktop dashboard for the project TightVNC showing a member pod and a ticket pod6. ReferencesAhmadi, N., Jazayeri, M., Lelli, F. and Nescic, S. 2008. A survey of social softwareengineering. Proceedings of 23rd IEEE/ACM International Conference on AutomatedSoftware 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 Managementpractices 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 inspireinnovation and performance. Pfeiffer.
  14. 14. DeMarco, T. and Lister, T. 1987. Peopleware: productive projects and teams. DorsetHouse 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 … PersonalLearning Environments.Jones, C. 1986. Programming productivity. McGraw-Hill, New York.Knorr-Cetina, K. 1997. Sociality with Objects: Social Relations in PostsocialKnowledge Societies. Theory, Culture & Society, 14(4):1-30, 1997Koper, R. and Sloep, P. 2003. Learning Networks - connecting people,organizations, autonomous agents and learning resources to establish theemergence of effective lifelong learning. Programme plan, Open University of theNetherlands.Nonaka, I. and Takeuchi, H. 1995. The Knowledge Creating Company: HowJapanese 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 KnowledgeSharing in Software Engineering by Microblogging. Proceedings of SoftwareEngineering 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. andSchaffert, S. (eds.) International Journal of Emerging Technologies in Learning(iJET): Special Issue: ICL2009 - MashUps for Learning, 5.Sorenson, M. 2002. Dictionary definition of dashboards.,,sid182_gci804078,00.htmlRobillard, 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 softwareengineering. Journal of Systems and Software, 53(3):219–224.Siemens, G. 2005. Connectivism: A learning theory for the digital age. InternationalJournal of Instructional Technology and Distance Learning, 2(1):3–10.Star, S. L. and Griesemer, J. R. 1989. Institutional ecology, ’translations’ andboundary objects: Amateurs and professionals in Berkeley’s museum of vertebratezoology. 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 mentalprocesses. Harvard University Press.Wilson, S. 2005. Architecture of Virtual Spaces and the Future of VLEs.