technological educational institute of thessaly

3 downloads 104 Views 3MB Size Report
W3C Standards, W3C compliance for HTML/ XHTML (Strict and Transitional). Methodologies and modelling involved. • Rational Unified Process (RUP). • UML ...
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