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

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

Wolfgang Reinhardt, University of Paderborn, Germany – [email protected]

Sebastian Nuhn, University of Paderborn, Germany – [email protected]

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

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

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

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/

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/.

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

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

dashboard my-eCopSoft dashboard

project dashboard

desktop dashboard

pod eCopSoft server

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

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

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

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

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

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.

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.

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