TECHNOLOGICAL EDUCATIONAL INSTITUTE OF THESSALY
ΚΝΟWLEDGE MANAGEMENT for SOFTWARE PROJECT MANAGEMENT USING ONTOLOGIES AND SOCIAL NETWΟRKS - ONSOCIAL SP19-D5 Commercial Software Project Case Study
Contact Person: Panos Fitsilis (
[email protected]) October 2015
1
Table of Contents 1 2
Project Description ................................................................................................ 3
Project Team Organization .................................................................................... 6
2.1
Organisation Chart......................................................................................... 6
2.3
Required technical and management skills ................................................. 15
2.2 3
Case study methodology ..................................................................................... 16
3.1
5 6
Building the enterprise corpus .................................................................... 17
3.2
Modelling the competences ........................................................................ 18
3.4
Locating and recommending experts/project team members. ...................... 21
3.3 4
Roles and Responsibilities ........................................................................... 10
Analyzing the social network ....................................................................... 20
Case study scenario ............................................................................................. 23 Conclusions .......................................................................................................... 33 APPENDIX A – MEASURES REPORT ...................................................................... 35
2
1 Project Description
This case study with the assistance of Intrasoft International company, where one of
the members of ONSOCIAL team is working. A commercial company was selected in order to
investigate the applicability of the tools and of the methodology that was used in the context of ONSOCIAL project.
INTRASOFT International is a leading European IT Solutions and Services Group with
strong international presence and expertise that serves the needs of over 500 EU institutions, national governments, telecommunication companies, banks and private sector enterprises. INTRASOFT International's expertise and strength lie in its:
proven capacity and successful track record in undertaking and delivering,
ability to combine technical expertise with thorough understanding of
complex, mission - critical projects customer’s business needs
highly-skilled, efficient and flexible human resources base with an international culture.
INTRASOFT International was established in 1996 and the head office is at
Luxembourg. The company is present in 18 countries such as Belgium, Bulgaria, Denmark, Cyprus, Greece, Iraq, Jordan, Luxembourg, Moldova, Morocco, Romania, Palestine, Philippines, Saudi Arabia, UAE, UK, USA, Yemen, etc. (www.intrasoft-intl.com)
The project that was selected was concerned with the development of European e-
Justice Portal. INTRASOFT International SA is developing the European e-Justice Portal (https://e-justice.europa.eu/home.do), which is conceived as a "one-stop (electronic) shop"
for information on European justice and access to European judicial procedures. It is currently available in 23 languages. The project is executed via Fixed Price and Quoted Time and Means Specific Contracts.
The European e-Justice Portal provides, in a consolidated system, a single entry point
for all justice questions and online procedures, as well as access to interconnected judicial
registers and databases. The European e-Justice Portal project was mooted by the Justice and
Home Affairs Council to address the increasing EU cross-border justice workload and the demands questioning the applied working methods. The Portal gives an answer to the
identified requirements. The priorities for the development of the Portal are set by the European e-Justice action plan (Council Multi-Annual European e-justice Action Plan 20093
2013 (2009/C 75/01), OJEC 31.3.2009 C 75/1). The Portal was designed to offer a user-friendly
experience since it is targeted at disparate groups i.e. Citizens, businesses, legal practitioners
and members of the judiciary access content and on-line procedures on the Portal, in all official EU languages. The Portal’s content organisation is based on a multi-level taxonomy, organising its “static content” (general information pages and links) and its “dynamic content”
(external databases accessed via links and interactive applications) allowing, for example, users to fill, save, print and submit forms.
The business layer of the European e-Justice Portal is developed on the J2EE platform.
It provides a wide range of functions such as role-based access control, content management
workflow, validation of external and internal links, electronic forms, email notifications and other.
The Portal is connected to external systems such as the ECAS server (the EC’s
authentication server), the LDAP server of the EC, an IDOL7 server, and the Insolvency
Registers. The Portal is also connected via web services to additional external systems such as the e-TrustEx, which will be used as an intermediary in the communication with e-CODEX .
The Portal integrates a number of open source products such as: JBoss application
server; Jasper Reports;Castor XML; Struts framework; OWASP ESAPI Java library; MySQL Database (Open source); JibX (XML Binding); Apache CXF (web services api and provisioning); EhCache (Portal content and data caching); Spring Framework (introduced in the latest version for the e-Codex integration).
The Portal encompasses a sophisticated Content Management System that uses
Alfresco. An Alfresco cluster is used in order to achieve high service availability as well as load
balancing among the Alfresco servers. The systems features a number of advanced functions including: Role based content editing, reviewing and publishing workflows; Custom content
versioning mechanism; Implementation of special content translation workflows, with
embedded translation notification mechanism; A content comparison mechanism; An advanced link management functionality, which supports link groups, batch link updates, broken link checks and notifications; Bulk uploads of content.
The Portal supports an advanced search functionality which utilises the IDOL7 server
of Autonomy. The content (including attachments in PDF and DOC format) is indexed through
the Autonomy IDOL Alfresco connector. A REST API is used for invoking queries and retrieving search results. The search function supports multilingual search and the results are post processed by the Portal business logic.
4
The system is used from all member states in order to include content and it supports
23 official EU languages. We perform extensive testing activities in all languages in order to ensure that the contents of the system, of the relative forms etc. are correct. The portal covers the following horizontal technical requirements:
Information Providers Guide (IPG) compliance
Data protection aspects (mainly personal data)
Performance requirements
Security requirements (mainly Commission’s policy on Security of Information Systems (ISSP))
Navigation, design, usability and look and feel Multilingualism
Access to the Portal – Web accessibility (including responsive web design) Scalability , resilience and availability aspects Standards and best practices compliance
5
2 Project Team Organization 2.1 Organisation Chart
The project team organization was engineered to answer to the following needs: Team Scalability. The project team shall be able to carry out in parallel several
individual work orders, especially under TASK 01, and scale up to undertake without delays the execution of new orders.
Teams coordination. Given that the project team had to work in several parallel
individual work orders, the project sub-teams working on different orders should be in position to coordinate their activities in an efficient and effective way.
Single overall management layer and point of contact. The project team had to
provide a single overall management for all project activities and a single point of contact for the management of the contract.
Availability of competence resources to address peaks on work. The proposed
organisation foresaw a pool of resources that will be available to be assigned to new work order without delays
The following picture depicts the project organisation that is proposed to address the
above-listed main needs of the project. The project organisation is explained thereafter.
6
Figure 1: Project Organisation Chart
The whole project is managed by the Contract Manager, who is also the prime contact
person of Intrasoft International for contractual and management issues. A Deputy Contract Manager assists and replaces the Contract Manager in case he or she is not available.
The Contract Manager reports to the management team of DG JUSTICE via regular
progress meetings (usually once every two weeks) and status reports that detail the progress,
issues and risks of all sub-projects as well as the plan of future work. The Contract Manager is also responsible for providing offers for new QTM assignments in response to requests from the Commission.
The Project Planning and Risk Management team consists of:
The Contract Manager;
The QA Manager;
The Deputy Contract Manager; Sub-Project team Leaders;
Key technical persons from different sub-project teams (Application Architects, Analysts and Consultants). 7
The project organisation foresees a number of sub-project teams, each of which will
be working on different parts of the portal. In principle the organisation of the sub-project
teams will reflect the structure of the work on different parts of the Portal. For example, one sub-team may be responsible for the evolutive work on the Portal core, while another team
may be responsible for a new development outside the Portal core. This way multiple orders can be executed in parallel and new sub-project teams may be added as required for serving new orders.
Each sub-project team will consist of:
One sub-project leader;
A number of sub-team teams according to the activities that need to be carried out; a sub-project team may consist of all of some of the following: o
Analysis and Design Team;
o
Development Team;
o o o o
Prototyping Team;
Deployment and Configuration Team; Technical Support Team;
Technical Documentation and Training Team;
In order to ensure scalability of the project team and swift response to new requests,
the sub-project teams can get resources from a Pool of resources of both companies of the Consortium.
In addition to the sub-project teams, a Maintenance Team and a Development
Operations Team are foreseen.
The Maintenance Team will consist of a Corrective Maintenance sub team and a
Technical Support sub team. The Technical Support will provide a 1st and 2nd level support
for the handling of the incoming incidents and requests. The Corrective Maintenance sub team will provide corrective maintenance mainly for Portal systems that are not under evolutive development. Corrective maintenance for Portal systems that are still under
evolutive maintenance will be provided by the sub team that will be responsible for that
system. For example corrective maintenance for the Portal core will be provided by the subproject team responsible for the Portal core on the assumption that the Portal core is under
evolutive maintenance. In this case incidents concerning defects in the Portal core will be assigned to the responsible Portal core sub-project team by the Technical Support.
8
The Maintenance service team will consist of:
One Maintenance Manager;
One or more analysts and consultants;
IS User Assistance Persons;
Developers and, if required, Interface Designers/Developers; Technical Assistance Persons.
Any testing that might be required for work performed by the maintenance team
(typically verification of defect resolutions in the context of corrective maintenance) will be
performed by a testing team that will not be managed by the Maintenance Manager. Instead the testing team will be managed by the QA Manager (similarly to the way testing teams assigned to sub-projects will be managed by the QA Manager).
The Development Operations Team will be responsible for the management of the
development and testing environments used by the various sub-teams as well as of the demonstration environment.
In particular, the Development Operations Team will be responsible for the:
Configuration and Management of various development and testing
environments used by the various sub-project teams as well as of the demonstration environment;
Creation of deployment templates and scripts;
Preventive Maintenance of the above mentioned environments (monitoring, software upgrades, etc.).
In order to ensure seamless integration of all system modules as well as overall sound
system architecture, the project organisation foresees an Architecture Team that
superintends the architectural designs of all Portal systems. The architecture team consists of:
Sub-project team leaders;
Key technical staff from different sub-project teams and the Development Operations team (Application Architects, Analysts and Consultants).
Security Experts, who will responsible for addressing the security-related aspects of the Portal systems.
While the architecture team ensures synchronisation among all sub-teams at the level
of the system architecture and design, a Project Planning and Risk Management Team ensures 9
synchronization of all sub-teams in terms of planning and risk management. Given that tasks
undertaken by different sub-teams may have interdependencies and issues or risks in one team may affect the work of other teams, there is a need to ensure that project planning and
risk management is performed effectively for the entire project and this is achieved by the Project Planning and Risk Management team.
The Quality Assurance will be undertaken by a Quality Assurance Team that will be
managed by a Quality Assurance Manager. The Quality Assurance Manager will also manage
the testing teams assigned to the various sub-projects. The Quality Assurance Manager will report directly to the DG JUST Project Managers.
2.2 Roles and Responsibilities
The responsibilities of the main roles foreseen in the proposed project organisation
are described in the following sections. Not all roles were described in detailed since not all of the were used in the case study. Contract Manager The consortium’s Contract Manager will take the overall responsibility for the success
of the Quoted Time & Means contract.
His/her main responsibilities include:
Overall responsible for the execution of the Quoted Time & Means contract
Acts as the Single Point of Contact (SPOC) to the Project Managers of the
and of the different tasks/sub-tasks executed in its context.
Commission for any issue related to the contract and to the different tasks/sub-tasks executed in its context.
Selecting staff and building the sub-project teams.
Producing, in close collaboration with the Application Architect and/or the
key analysts and the sub-project team leaders (and if necessary, the Interface Designer/Developer) offers for the execution of specific sub-tasks.
Initiating and closing-up sub-tasks executed in the context of the contract. Monitoring and control of the proper execution of sub-tasks.
Time management, scope management, procurement management, risk
management, and integration management (including change management). Service level management and continual service improvement. Reporting to the Commission and to the Delivery Directors. 10
Participating in the progress meetings, Steering Committee meetings, other
managerial meetings as well as other ad-hoc meetings and technical meetings organised with the Commission.
Escalating potential issues, risks and delays to the Delivery Directors.
Leading the Project Planning and Risk Management team of the Contractor and chairing the meetings of the team
System Architect The System Architect is the key technical person in the execution of the project. He or
she has the overall understanding of all the modules of the Portal (Portal core, IRI, Court DB,
etc.) in terms of business needs addressed by the system, functionality, architecture, design and technology and plays a leading role in the design and integration of new modules. He or
she is responsible for the overall architectural design of the Portal and the integration of all the system modules.
His/her main responsibilities include:
Leads the Architecture team and chairs the meetings of the team.
Attends progress meetings and, if necessary the Steering Committee
Attends the meetings of the Project Planning and Risk Management team. Meetings.
Provides assistance to the Contract Manager for the production of sub-tasks offers.
Leads the architectural design of new modules in cooperation with subprojects leaders and key analysts and consultants. Reviews analysis and design documents.
Provides consultancy and support to the members of the development teams.
Application Architect The application architects are involved in the sub-task offer production process and
they undertake the design and development of Portal modules architecture under the coordination of the sub-project team leaders.
The main responsibilities of the application architect include:
Architecture and design of Portal modules
Review of the architecture of existing systems 11
Design and development of module architecture and building blocks
Data analysis and data modelling.
Analysis of the integration of different Portal modules
Coordination of the implementation of the technical architecture
Technical interface between the sub-project leader and the developers Production of software architecture documents
Participation in technical working groups, progress meetings and meetings of the Architecture Team
Assistance in the testing, the technical documentation, the deployment, the evaluation and the reporting
Security Expert The security experts undertake the security design and security studies of the Portal. The main responsibilities of the application architect include:
Security Requirements analysis
Security Risk Assessment;
Business Impact assessment
Production of security plans;
Production of other related security studies; Security Design of Portal Systems; Security testing.
Analyst The analysts are involved in the sub-task offer production process and they undertake
the execution of analysis tasks under the coordination of the sub-project team leaders. Their main responsibilities include:
Provides assistance to the Contract Manager for the production of sub-tasks
Estimates the effort required for the execution of specific sub-tasks.
offers.
Undertakes the analysis of new works and produces the necessary documentation (Use Cases, requirements, etc.)
Analyses problems and change requests, proposes solutions and performs impact analysis for the requests for corrective maintenance. 12
Updates the information system documentation and manuals according to
Produces and updates Test Plans.
the changes.
Provides support for the acceptance testing of new releases (including on-site interventions if necessary).
Provides consultancy and support to the Developers.
Developer The consortium’s Developers are responsible for the execution of software
development tasks under the coordination of the sub-project team leaders. The main responsibilities of a developer include:
Development and maintenance of Portal modules
Prototyping
Development and integration of technological components Execution of Unit Tests
Participation in the execution of performance tests Writing of technical documentation
Deployment and configuration of the system
Interface Designer/Developer The consortium’s Interface Designers/Developers are involved in the design and
development of user interfaces.
Their main responsibilities include:
Provision of assistance to the sub-project team leaders in addressing user
Analysis of new requirements related to user interfaces.
interface design issues during the sub-task offer production process. Impact analysis for changes related to user interfaces.
Estimating the effort required for the execution of specific activities related to the design and development of user interfaces. Design and development of user interfaces.
Performance of corrective and evolutive maintenance activities (relating to user interfaces).
Quality Assurance Manager 13
The Quality Assurance Manager will be responsible for:
Overall responsible for the performance of the Quality Assurance team of the
Selecting QA staff and building QA team of the Consortium.
Contractor.
Coaching the QA team.
Defining quality criteria and metrics applicable to specific sub-tasks executed in the context of the contract.
Allocate QA Engineers to various QA tasks of the project.
Escalating potential quality issues and risks to the Delivery Directors.
Reporting to the Commission and to the Delivery Directors on QA matters.
Participating in the progress meetings, Steering Committee meetings, and other managerial meetings organised with the Commission.
Being an active member of the Project Planning and Risk Management team of the project, which entails:
Participating in the meetings of the Project Planning and Risk Management team.
Reviewing project plans and risk management plans. Participating in the risk management process.
Tester The consortium’s testers are involved in the planning and execution of different types
of testing.
Their main responsibilities include:
Participation in the sizing and planning of the work related to the execution
Production of test plans and test cases and definition of test data
of different types of testing
Writing of scripts to be used for automated testing (functional, performance etc.)
Execution of tests
Writing of test reports
14
2.3 Required technical and management skills
The following list presents the technical skills that should be available within the
project team
Programming languages, API, tools
MySQL
Eclipse, Sonar
Alfresco, IDOL 7, JBoss App Server, Jasper Reports, JAVA, Java Server Pages (JSP) – Struts 1.x, JavaScript, CSS, jQuery, JDBC,
HP Load Runner, JMeter
SOA/ webservices (REST), SOAP, Visual Paradigm
Standards/guidelines
W3C Standards, W3C compliance for HTML/ XHTML (Strict and Transitional)
Methodologies and modelling involved
Rational Unified Process (RUP) UML
15
3 Case study methodology
It is evident that project management success depends heavily from human capital
management. This factor is even more important in the case of software project management since software development is based mainly on intellectual effort.
Our approach, as it was implemented wi1th ONSOCIAL system is facilitating the
process of project team selection by combining in an intuitive manner ontologies, social networks, and social network analysis.
In Figure 2, we present the high level use case diagram of the ONSOCIAL system. The
system is interacting with five different actors, namely:
the Employees that Donate Own Social Network Data to the enterprise data
the Administrator that initiates the use case of Constructing the Enterprise
corpus,
Data Corpus (operation of the crawler) and the use case Analyze Social Network than computes network metrics
the Human Resource (HR) manager that is constructing/maintaining the ontology and finally
the Project Manager that defines the project team requirements as a set of competences/skills in accordance with the ontology and searches within enterprise data corpus for possible matches.
Donate Own Social Network Data employee
extend extend extend
include
Construct Enterprise Data Corpus Administrator
facebook crawler LinkedIn crawler Google+ crawler Select project team
Enterprise data Corpus
Analyse Social Network
Define project team requirements
Project Manager
Construct/maintain Ontology HR manager
Figure 2. ONSOCIAL system use cases
In our proposed approach, four are the basic steps involved (see Figure 3):
16
Building the enterprise corpus Modelling the competences Analyzing the social network Locating and recommending experts/project team members Figure 3: Methodology overview
3.1 Building the enterprise corpus
Building the enterprise corpus of data based on data extracted from commercial social
networks. The basic scenario used is that all enterprise employees will authorize ONSOCIAL system to crawl on their own data collecting profiles and established social links in order to build an enterprise social corpus (see Figure 4 and 5). According to this view, the enterprise social corpus is considered to be the sum of the profiles of all employees.
The ONSOCIAL Crawler is the component of the system that constantly runs in the
background, with the task of gathering information from the supported social networks, translating it to an internal common representation and storing it in a form that is appropriate
for querying. The crawler is using an incremental approach for building the group’s corpus of data, containing all profiles of the persons belonging to the specific group that have accepted to invitation issued by ONSOCIAL system. The internal representation is based on HR-XML in order to maximize the data interoperability with similar systems.
17
facebook
LinkedIn
Google+
Facebook adaptor
LinkedIn adaptor
Google adaptor
Allow access to personal profile employee
CRAWLER
Entreprise corpus
Figure 4. ONSOCIAL building enterprise corpus
Figure 5. ONSOCIAL crawler user interface
3.2 Modelling the competences
Modelling the competences and the knowledge required for successfully
implementing a software project using custom developed software project management ontology. The ontology has been developed using protégé system.
18
The ontology was developed using Protégé system and it models competencies which
a human resource may possess for the performance of a project activity. Furthermore, the ontology includes concepts that enable to associate employees with sector of activity where they acquired the competences, seniority level, location where they worked etc. A brief description of ontology classes is presented in the Table 1. Table 1. ONSOCIAL ontology main classes. Class name
Description
Education Type
The type of education of a person (High School, Graduate School,
Job
A job may be related to a company and one or more projects.
Project
The project type
School Type
The type of a school (e.g. College, University etc.)
Seniority Level
A level of seniority (Junior, Moderate or Senior)
Task
A task is part of a project.
Competence
A competence is a technical, social or other type of skill.
Education Subject Area
An education field
Education Level
Education level
Location
A geographical location
Sector
Categorization of industry sectors.
College)
19
Figure 6: Onsocial ontology
3.3 Analyzing the social network
Except the specific technical knowledge that can be identified through a direct
keyword we have to analyze the social network for extracting behavioral competences.
Interestingly enough patterns on behaviour that have been identified in literature that
can be of use are:
Central connectors have the maximum number of direct connections in a
Peripheral players are loosely connected or isolated employees that represent
network, playing a critical role in the community effectiveness. under-utilized resources of a community.
Brokers are employees that are disproportionately important for community connectivity. This type of people can be found on the shortest path between two different community members.
Ego network size index for measuring the diversity of contacts. Ego network size index is measures as the degree centrality within the social network and it is the number of different contact each node of the social network has.
Ego average tie strength index for measuring the tie strengths. Tie strength is
measuring the frequency of communication or collaboration between two actors. The sum of tie strengths of an author is the total number of
collaborations an actor has.
Ego betweenness centrality index for measuring the structural position. Betweenness centrality is a measure of the potential of an employee to control 20
the communication flow within the group of people. When an actor is consider
central within a group this implies that this individual exhibits bridging behavior. Ego-betweenness centrality is computed as the sum of the times an
actor is within the shortest path between other actors of the network.
Individual effectiveness index for measuring brokerage and diversity. Effectiveness of an actor is defined as the number of non-redundant (not connected) contacts. It is measured as the number of contacts that an actor
has, minus the average number of links that each contact has to other contacts
of the specific actor.
Contact status (power) for measuring the embeddedness of resources. Power is measured either o
by degree centrality: actors who have more ties to other actors may
be advantaged positions, or measuring the immediate ties that an actor has, or the ties of the actor's neighbors, rather than indirect ties
o
to all others, or
by betweenness centrality where an actor is being in a favored position to the extent that the actor falls on the geodesic paths between other pairs of actors in the network.
3.4 Locating and recommending experts/project team members.
This is a two steps process that includes definition of project team requirements and
querying the enterprise data corpus for finding matches for the empty project positions.
When searching for team members, a project manager or a representative of human
resource department can ask for all profiles that match the profile needed. In this matching, we are interested in determining whether or not a profile satisfies a set of requirements. Since the requested requirements could be mandatory or optional the matching in many cases is partial. This implies that a fuzzy approach for the recommendation is the most appropriate in our case.
To address human resource evaluation and selection in software development tasks, we suggest a group-based fuzzy multicriteria approach using the fuzzy linguistic 2- tuple representation model.The proposed approach consists of 3 different stages, which further
include nine distinct steps as presented in the flowchart of Figure 7. Specifically, in stage 1,
consisting of Steps 1 to 5, the task profile (with respect to the required skills) is estimated using
21
linguistic evaluations provided by experts on the skills required for the particular task. In stage
2, which includes Steps 6 to 7, the capabilities of the available human resources are evaluated using linguistic evaluations provided by experts on their skills. Last, in stage 3, consisting of Steps 8 to 9, the capabilities of the available human resources are reevaluated using linguistic
evaluations of skill relationships provided also by experts/decision makers. Steps 2 to 4 are
common to the three different stages of the algorithm to ensure the objectivity of the experts’
evaluations. The nine steps of the approach are described in detail in the following subsections.
Figure 7: Flowchart of the proposed approach for the evaluation of human resources considering skill relationships
22
Since the above developed method has not been developed in software we will use
simpler social networks metrics in order to evaluate the profiles of team members and to propose additions to the existing team.
4 Case study scenario
In order to conduct the case study we have used a number of steps. These steps are:
We have selected a number of team members of the specific project
We have used ONSOCIAL system to collect data through facebook. The data have been uploaded to ONSOCIAL database. We have extracted these data and we have uploaded these data to ΟΡΑ tool, where we have done the analysis of the extracted data.
ORA is a dynamic meta-network assessment and analysis tool developed by CASOS at
Carnegie Mellon. It contains hundreds of social network, dynamic network metrics, trail
metrics, procedures for grouping nodes, identifying local patterns, comparing and contrasting networks, groups, and individuals from a dynamic meta-network perspective. ORA has been
used to examine how networks change through space and time, contains procedures for
moving back and forth between trail data (e.g. who was where when) and network data (who is connected to whom, who is connected to where …), and has a variety of geo-spatial network
metrics, and change detection techniques. *ORA can handle multi-mode, multi-plex, multilevel networks. It can identify key players, groups and vulnerabilities, model network changes over time, and perform COA analysis. It has been tested with large networks (106 nodes per 5 entity classes).Distance based, algorithmic, and statistical procedures for comparing and contrasting networks are part of this toolkit (http://www.casos.cs.cmu.edu/projects/ora/).
In ORA tool the user is able to define a network and within the network a number of
nodesets that were defined in accordance with ONSOCIAL ontology. Further, we have defined
a set of networks that combines one of more nodesets. Typical social network analysis handles one mode data (e.g. a people to people network). In this case, the metrics identify which node
in the network are critical. The grouping algorithms cluster the nodes, (e.g., the people, into groups). Sometimes you have two mode data such as people by events, (e.g. the classic Southern Women Study).
In ORA, Nodesets can be cross indexed as being related to agents, organizations,
locations, tasks, events, resources, knowledge, beliefs, roles. If you do this there are some
23
additional metrics that rely on knowing what Nodesets you have that you can take advantage of (e.g., with locations you can run the locations reports).
In general, all metrics that run on agents also run on organizations and roles. For tasks
and events - there are other special temporal metrics. All metrics that run on resources also
run on knowledge and beliefs. The standard social network measures run on any square one
mode network - however in ORA - some guidance is provided on how to interpret this based on the type of nodes. 8.
The ONSOCIAL model that we have constructed with ORA tool is presented in Figure
Figure 8: OnSocial model using ORA
In this model we have defined nine nodesets namely:
Educational Type representing type of educations (see figure 9).
Employee representing real employees. The name of employees have been encoded in order to satisfy privacy rules (see figure 10).
Friends. The friends of the selected employees. The friends’ names have been
transformed accordingly, in order to avoid disclosure private employee’s data and therefore have been transformed to names such as “friend_1”, “friend_2”, etc. Actually, the real information used in this nodeset is the
relationships between employees and friends (see figure 11).
Knowledge. Information in this nodeset was given by the project manager of the selected project and it is mainly technical (see figure 12).
24
Location. The location of friends and employees. Friends in other countries than the selected one have been filtered out. Therefore, only friends from the selected countries are used in the network (see figure 13).
Organization. The organization the employee or friend is working. It was only partially used in the conducted analysis (see figure 14).
Role. The role of the employee within the selected project (see figure 15).
Sector. The industry sector where the employee or friend has experience (see figure 16).
Task. Partially used to describe the task (see figure 17).
Figure 9: Educational Type nodeset
Figure 10: Employee nodeset
25
Figure 11: Friends nodeset
26
Figure 12: Knowledge nodeset
Figure 13: Location nodeset
27
Figure 14: Organization nodeset
Figure 15: Role nodeset
28
Figure 16: Sector nodeset
Figure 17: Task nodeset
Similarly we have defined a number of networks. A network defines a relationship
between two different nodesets. A network N is a triple consisting of two sets of nodes, called
U and V, and a set of links E⊂UxV. Thus, we write N=(U,V,E). An element e = (i,j) in E indicates a relationship or tie between nodes i∈U and j∈V. A network where U=V and therefore E⊂VxV
is called unimodal; otherwise the network is bimodal. We write G=(V,E) for unimodal
networks. For our purposes, unimodal networks will not contain self loops, which means that
29
(i,i)∉E for i∈V1. In order to simplify our work we have used binary relationships (exists of does not exist). However, it is possible to use weights, fuzzy logic, etc. In this case study we have used the following networks:
Employee x Educational Type representing the education level of each
Employee x Friend representing the friendship relationships of each
employee
employee for those friends that reside within the available locations
Employee x Knowledge that represents the knowledge of each employee from the lst of useful according to the project manager list
Employee x Location. The location where the employee resides Employee x Role. The role of the employee within the project
Employee x Sector. The sector where the employee has knowledge Friend x Educational Type. The education type of the friend
Friend x Knowledge. The knowledge of the friends according to the list of skills Friend x Location. The location where the friend is active. Only selected locations are considered.
Figure 17: Employee x Knowledge example matrix.
The possibilities to analyse the above describe networks is practically unlimited. A full
report produced by the tool will be presented as appendix.
A few figures will be presented and we will give some interesting observation.
1
ORA users guide, www.casos.cs.cmu.edu/publications/papers/CMU-ISR-13-108.pdf
30
Figure 18 presents the education type of employees and friend of employees. Friends
without education type implies that their profile was empty for this entry in the social network.
Figure 18: Employee and friend education type.
In figure 19 we present the friendship network of the project team members. Of
course project team members have common friends.
31
Figure 19: Employee x friend network
In Figure 20 we can observe which of the friends have the required knowledge by this
project in order to fill a possible empty project position.
32
Figure 19: friends with required knowledge
If from the above figure we select friends that have more than three of the requested
skills we end up with the following figure.
Figure 19: Friends with most of the required knowledge
5 Conclusions
We used the OnSocial PM-Ontology and OnSocial software for determining the most
appropriate candidates. For visualizations and metrics calculation we have used social analysis tool ORA.
The conclusions from using these technologies and tools are the following:
Social Network Analysis as a business tool for selecting personnel offers quite
In order SNA to be used we have to obtain high quality data that are not
promising opportunities, both for further research and for commercialization. available through a single source. For overcoming this problem we have to address different and diverse data source. In many cases the data are open
data and can be accessed freely. In other cases data have to be acquired
through unstable and quite limiting API.
Social networks are quite protective over their data, since it is a legal requirement but at the same time they consider these data as a company commercial asset and therefore they are limiting their usage. 33
Data obtained from social networks are sparse and as such their value is
Further, the interpretation of data especially when it refers to social skills is
limited
ambiguous and further research is required in this area.
34
6 APPENDIX A – MEASURES REPORT
35
