Search

Identifying the central people in information flow networks is essential to understanding how people communicate and coordinate as well as who controls the information flows in the network. However, the appropriate usage of centrality metrics depends on an understanding of the type of network flow. Networks can vary in the way node-to-node transmission takes place, or in the way a course through the network is taken, thereby leading to different types of information flow processes. When metrics are used for an inappropriate flow process, the result of the metric can be misleading and often incorrect. In this paper we create a simulation of the flow of information in a network, and then we investigate the relation of information centrality as well as other network centralities, like betweenness, closeness and eigenvector along with the outcome of simulations with information flowing through walks rather than paths, trails or geodesics. We find that Information Centrality is more similar to Eigenvector and Degree centrality than to Closeness centrality as postulated by previous literature. We also find an interesting pattern emerge from the inter metric correlations., Comment: I think I have made a mistake in the correlations in the analysis on page 6 and in the Appendix

Abuse in any form is a grave threat to a child's health. Public health institutions in the Netherlands try to identify and prevent different kinds of abuse, and building a decision support system can help such institutions achieve this goal. Such decision support relies on the analysis of relevant child health data. A significant part of the medical data that the institutions have on children is unstructured, and in the form of free text notes. In this research, we employ machine learning and text mining techniques to detect patterns of possible child abuse in the data. The resulting model achieves a high score in classifying cases of possible abuse. We then describe our implementation of the decision support API at a municipality in the Netherlands., Comment: 31 pages, 7 figures and 12 tables

Today's dynamic and iterative development environment brings significant challenges for software project management. In distributed project settings, "management by walking around" is no longer an option and project managers may miss out on key project insights. The TESNA (TEchnical Social Network Analysis) method and tool aims to provide project managers both a method and a tool for gaining insights and taking corrective action. TESNA achieves this by analysing a project's evolving social and technical network structures using data from multiple sources, including CVS, email and chat repositories. Using pattern theory, TESNA helps to identify areas where the current state of the project's social and technical networks conflicts with what patterns suggest. We refer to such a conflict as a Socio-Technical Structure Clash (STSC). In this paper we report on our experience of using TESNA to identify STSCs in a corporate environment through the mining of software repositories. We find multiple instances of three STSCs (Conway's Law, Code Ownership and Project Coordination) in many of the on-going development projects, thereby validating the method and tool that we have developed.

Software development is rarely an individual effort and generally involves teams of developers collaborating to generate good reliable code. Among the software code there exist technical dependencies that arise from software components using services from other components. The different ways of assigning the design, development, and testing of these software modules to people can cause various coordination problems among them. We claim that the collaboration of the developers, designers and testers must be related to and governed by the technical task structure. These collaboration practices are handled in what we call Socio-Technical Patterns. The TESNA project (Technical Social Network Analysis) we report on in this paper addresses this issue. We propose a method and a tool that a project manager can use in order to detect the socio-technical coordination problems. We test the method and tool in a case study of a small and innovative software product company.

In this paper we apply the social network concept of core-periphery structure to the sociotechnical structure of a software development team. We propose a socio-technical pattern that can be used to locate emerging coordination problems in Open Source projects. With the help of our tool and method called TESNA, we demonstrate a method to monitor the socio-technical core-periphery movement in Open Source projects. We then study the impact of different core-periphery movements on Open Source projects. We conclude that a steady core-periphery shift towards the core is beneficial to the project, whereas shifts away from the core are clearly not good. Furthermore, oscillatory shifts towards and away from the core can be considered as an indication of the instability of the project. Such an analysis can provide developers with a good insight into the health of an Open Source project. Researchers can gain from the pattern theory, and from the method we use to study the core-periphery movements.