Masters’ Degree in Informatics Engineering

Dissertation

InTeligent
Interoperable Telecommunications ITIL-compliant Services
Management System

September 3, 2013

João Casalta Nabais

[email protected]

Advisors at DEI:
Alexandre Pinto
Jorge Cardoso

Advisor at SAPO:
António Cruz
 Abstract

Over time services became bound to technology resources, consequently a

great need for IT service management (ITSM) appeared. With it, a set of
industry best practices were gathered and complied into, what is known today
as Information Technology Infrastructure Library (ITIL) and is highly adopted
in today’s industry.
Implementing ITIL is not linear and becomes highly expensive to compa-
nies, since costs for hiring ITIL certified professionals or for ITIL certification
of collaborators must be performed.
Today, each enterprise designs and provides a vast set of services, some of
which are ITSM Services, for a wide range os customers.
This thesis proposes the development of potentially standardizable ITIL
components interfaces, allowing companies to perform cost reductions by reusing
them, bypassing the process of analysing and modelling ITIL practices, reduc-
ing time and overall costs of ITIL adoption.
In order to allow companies have a proper method to manage their services,
globally, we propose the development of a Service Portfolio Management Sys-
tem so that companies can manage their ITSM services metadata.

Keywords: Components, ITSM, ITIL, Service, Service Portfolio

iii
 Acknowledgements

It is very rewarding to look back to the time where this thesis was a mere
hypothesis and see where did it took me and what I have learned and accom-
plished, not only as a student but also has a person.
First, I would like to thank my academic advisor Alexandre Pinto for all
the guidance and knowledge provided, all the motivational words provided in
hard times and for the patience and availability shown throughout the year. I
would also like to thank my co-advisor Jorge Cardoso, who pointed me through
the right research directions when needed.
Furthermore, I would like to thank my advisor at SAPO, António Cruz,
for the opportunity of working at an organizational industry level, for all the
knowledge provided, the healthy discussions and all the guidance related to
service design. I would also like to thank Sonia, Rui and Fernando, for all
their inputs regarding ITIL Service Interfaces Design.
I would like to thank to the Genssiz Research Group and the CISUC In-
formation System Group, for all the insights and feedback provided, as well as
all logistics.
In addition, I would like to thank to my family, my parents José and Maria,
my twin brother José, my sister Ana and my grandmother Barbara, for provid-
ing me everything I needed during the course of this thesis and for supporting
me in the big decisions taken.
Last, but not least, I would like to thank my friends and colleagues, for
the companionship, for making me comfortable in times of stress and for all
personal advices provided during this phase of my life.

João Casalta Nabais

v
Contents

Abstract ii

Acknowledgements iv

List of Figures xi

List of Acronyms xiv

List of Code Listings xvi

1 Introduction 1
1.1 Problem Contextualization - Placement . . . . . . . . . . . . . . 1
1.1.1 Organizational Context . . . . . . . . . . . . . . . . . . . 2
1.1.2 Economic and Social Context . . . . . . . . . . . . . . . 3
1.1.3 Technological Context . . . . . . . . . . . . . . . . . . . 3
1.1.3.1 Languages . . . . . . . . . . . . . . . . . . . . . 3
1.1.3.2 Frameworks . . . . . . . . . . . . . . . . . . . . 5
1.2 Problem Identification . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Business and Management Aspects . . . . . . . . . . . . 6
1.2.2 Technical Aspects . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Social and Economical Aspects . . . . . . . . . . . . . . 7
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Overall Goals and Requirements . . . . . . . . . . . . . . . . . . 9
1.5 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Development Methodology . . . . . . . . . . . . . . . . . 9
1.5.2 Risk Management . . . . . . . . . . . . . . . . . . . . . . 11

2 Related Work and State-of-the-Art 13

2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 ITIL & eTOM Compatibility . . . . . . . . . . . . . . . 13
2.1.2 Developed ITIL Process Design Methodology . . . . . . 14
2.1.3 Component . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3.1 Component as a Service . . . . . . . . . . . . . 16
 CONTENTS

2.1.3.2 Abstract IT Component . . . . . . . . . . . . . 16

2.1.3.3 ITIL (2011) and ITSM Components . . . . . . 17
2.1.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.4.1 ITIL Information Object . . . . . . . . . . . . . 19
2.1.5 Service Design Principles . . . . . . . . . . . . . . . . . . 19
2.1.5.1 Coupling . . . . . . . . . . . . . . . . . . . . . 20
2.1.5.2 Cohesion . . . . . . . . . . . . . . . . . . . . . 20
2.1.6 Service Description . . . . . . . . . . . . . . . . . . . . . 21
2.1.7 Process Modeling . . . . . . . . . . . . . . . . . . . . . . 22
2.1.8 Service Portfolio . . . . . . . . . . . . . . . . . . . . . . 23
2.1.8.1 Service Pipeline . . . . . . . . . . . . . . . . . . 24
2.1.8.2 Service Catalogue . . . . . . . . . . . . . . . . . 25
2.1.8.3 Retired Services . . . . . . . . . . . . . . . . . 25
2.2 State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Solutions Analysis . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Critical Assessment of Existing Solutions . . . . . . . . . 28

3 Requirements Analysis 31
3.1 Requirements Elicitation . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . 32
3.2.2 Non-Functional Requirements . . . . . . . . . . . . . . . 38

4 Architecture 43
4.1 First Level Architecture . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Second Level Architecture . . . . . . . . . . . . . . . . . . . . . 44
4.3 Third Level Architecture . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 ITIL Interfaces Design 49

5.1 Interface Design Process . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Analyse ITIL Process . . . . . . . . . . . . . . . . . . . . 50
5.1.2 Interface Design . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.2.1 Process Modeling via BPMN Diagram . . . . . 51
5.1.2.2 Cross Functional Design . . . . . . . . . . . . . 52
5.1.3 Team Discussion, Inspection and Revision . . . . . . . . 52
5.1.4 Enter the Interface information in the SDB Backoffice . . 53

vii
 CONTENTS

6 Development 55
6.1 Ontology Development . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.1 Ontological Specification Level . . . . . . . . . . . . . . . 56
6.1.2 Reused Ontologies . . . . . . . . . . . . . . . . . . . . . 57
6.1.3 Relevant Choices . . . . . . . . . . . . . . . . . . . . . . 59
6.2 SPMS Development . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Framework Selection . . . . . . . . . . . . . . . . . . . . 61
6.2.2 Technological Architecture Overview . . . . . . . . . . . 61
6.2.2.1 Django Models (MVC Models) . . . . . . . . . 62
6.2.2.2 Django Views (MVC Controllers) . . . . . . . . 62
6.2.2.3 Django Templates (MVC Views) . . . . . . . . 63
6.2.3 Semantic Web Tools . . . . . . . . . . . . . . . . . . . . 67
6.2.3.1 RDFLib . . . . . . . . . . . . . . . . . . . . . . 67
6.2.3.2 RDFLib-PostgreSQL . . . . . . . . . . . . . . . 68
6.2.3.3 Developed APIs . . . . . . . . . . . . . . . . . . 69
6.2.3.4 Important Features . . . . . . . . . . . . . . . . 69

7 Tests 73
7.1 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1.1 SAPO requirements Validation . . . . . . . . . . . . . . 73
7.1.2 Functional Requirements Testing . . . . . . . . . . . . . 73
7.1.3 Non-Functional Requirements Testing . . . . . . . . . . . 79
7.2 Test Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8 Conclusions 83
8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.2 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Bibliography 85

A Technological Analysis and Considerations 89

A.1 Web Applications Frameworks . . . . . . . . . . . . . . . . . . . 89
A.2 Django VS Ruby On Rails . . . . . . . . . . . . . . . . . . . . . 89
A.3 Why Python? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.4 Django Features in detail . . . . . . . . . . . . . . . . . . . . . . 91

B Requirements Methodology and Guidelines 93

B.1 Followed Methodology . . . . . . . . . . . . . . . . . . . . . . . 93
B.2 Adopted Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 94

viii
 CONTENTS

C Functional Requirements Mockups and Sequence Diagrams 97

C.1 Requirement F1. Register Company . . . . . . . . . . . . . . . 98
C.1.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 98
C.2 Requirement F2. Log Company In . . . . . . . . . . . . . . . . 99
C.2.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 99
C.3 Requirement F3. Add ITSM Service Instance . . . . . . . . . . 100
C.3.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 100
C.3.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 101
C.4 Requirement F5. Add ITSM Service . . . . . . . . . . . . . . . 102
C.4.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 102
C.4.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 103
C.5 Requirement F9. Edit ITSM Service Instance Properties . . . . 104
C.5.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 104
C.5.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 105
C.6 Requirement F10. Search Service . . . . . . . . . . . . . . . . 106
C.6.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 106
C.6.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 107
C.7 Requirement F11. Browse Service . . . . . . . . . . . . . . . . 108
C.7.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 108
C.7.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 109
C.8 Requirement F12. View Own Portfolio . . . . . . . . . . . . . 110
C.8.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 110
C.8.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 111
C.9 Requirement F13. View Consumer Company Catalogue . . . . 112
C.9.1 Graphical Mockup . . . . . . . . . . . . . . . . . . . . . 112
C.9.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . 113

D SAPO Interfaces Diagrams 115

D.1 Incident Management . . . . . . . . . . . . . . . . . . . . . . . . 116
D.1.1 Business Process . . . . . . . . . . . . . . . . . . . . . . 116
D.1.2 Cross-Functional Flowchart Diagrams . . . . . . . . . . . 118
D.2 Problem Management . . . . . . . . . . . . . . . . . . . . . . . 125
D.2.1 Business Process . . . . . . . . . . . . . . . . . . . . . . 125
D.2.2 Cross-Functional Flowchart Diagrams . . . . . . . . . . . 128

E BPMN Ontology 137

F Schedule 141
F.0.3 First Semester Schedule . . . . . . . . . . . . . . . . . . 141

ix
CONTENTS

F.1 Second Semester Schedule . . . . . . . . . . . . . . . . . . . . . 143

x
List of Figures

1.1 Risk process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Risk management . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Malcolm Fry Methodology for process design. . . . . . . . . . . 15

2.2 ITIL 2011 Processes and Functions. . . . . . . . . . . . . . . . . 17
2.3 Fry’s “Five key process questions”. . . . . . . . . . . . . . . . . 20
2.4 Fry’s procedure for building ITIL processes. . . . . . . . . . . . 21
2.5 Service Portfolio Subdivision. . . . . . . . . . . . . . . . . . . . 24
2.6 Service Portfolio and its contents. . . . . . . . . . . . . . . . . . 26

3.1 Use Case Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Selected ITIL
R functions and processes. A.
c Cruz (SAPO, PT) 37

4.1 Abstract architecture. . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Model-view-controller (MVC) pattern . . . . . . . . . . . . . . . 44
4.3 SPMS Components Diagram . . . . . . . . . . . . . . . . . . . . 46
4.4 SPMS Templates Component Diagram . . . . . . . . . . . . . . 47
4.5 SPMS Views Component Diagram . . . . . . . . . . . . . . . . . 47
4.6 SPMS Views Component Diagram . . . . . . . . . . . . . . . . . 48
4.7 SPMS APIs Component Diagram . . . . . . . . . . . . . . . . . 48

5.1 Process for designing ITIL interfaces . . . . . . . . . . . . . . . 50

5.2 Process describing the ITIL Process analysis . . . . . . . . . . . 51
5.3 Part of the process describing the ITIL IM Process . . . . . . . 51
5.4 Part of the cross functional diagram describing the ITIL IM
Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1 Practical example of OWL Lite FunctionalProperty construct. . 57

6.2 Practical example of OWL DL disjointWith construct. . . . . . 57
6.3 Part one of ITSM Service Ontology graph . . . . . . . . . . . . 59
6.4 Part two of ITSM Service Ontology graph . . . . . . . . . . . . 60
6.5 SPMS Installation Diagram . . . . . . . . . . . . . . . . . . . . 62
6.6 Screenshot of the interpreted fillITSMServices.html template . . 64

xi
LIST OF FIGURES

6.7 Screenshot of the editInstance.html template after an AJAX

request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.8 Screenshot of the template after the BPMN import . . . . . . . 70
6.9 Screenshot of the template after the WSDL import . . . . . . . 71

7.1 Functional requirement 5 test case . . . . . . . . . . . . . . . . . 75

7.2 Functional requirement 10 test case . . . . . . . . . . . . . . . . 77
7.3 Functional requirement 11 test case . . . . . . . . . . . . . . . . 78
7.4 Test Results Overview. . . . . . . . . . . . . . . . . . . . . . . . 81

B.1 Comparison between requirements methodology. . . . . . . . . . 94

C.1 Register Company Graphical Mockup . . . . . . . . . . . . . . . 98

C.2 Log Company In Graphical Mockup . . . . . . . . . . . . . . . . 99
C.3 Add ITSM Service Instance Graphical Mockup . . . . . . . . . . 100
C.4 Add ITSM Service Instance Sequence Diagram . . . . . . . . . . 101
C.5 Add ITSM Service Graphical Mockup . . . . . . . . . . . . . . . 102
C.6 Add ITSM Service Sequence Diagram . . . . . . . . . . . . . . . 103
C.7 Edit ITSM Service Instance Properties Graphical Mockup . . . 104
C.8 Edit ITSM Service Instance Properties Sequence Diagram . . . 105
C.9 Search Service Graphical Mockup . . . . . . . . . . . . . . . . . 106
C.10 Search Service Sequence Diagram . . . . . . . . . . . . . . . . . 107
C.11 Browse Service Graphical Mockup . . . . . . . . . . . . . . . . . 108
C.12 Browse Service Sequence Diagram . . . . . . . . . . . . . . . . . 109
C.13 View Own Portfolio Graphical Mockup . . . . . . . . . . . . . . 110
C.14 View Own Portfolio Sequence Diagram . . . . . . . . . . . . . . 111
C.15 View Consumer Company Catalogue Graphical Mockup . . . . 112
C.16 View Consumer Company Catalogue Sequence Diagram . . . . . 113

D.1 Part one of Incident Management Business Process . . . . . . . 116

D.2 Part two of Incident Management Business Process . . . . . . . 117
D.3 ITIL Incident Management Cross-Functional Flowchart Diagram
for Incident Identification . . . . . . . . . . . . . . . . . . . . . 118
D.4 ITIL Incident Management Cross-Functional Flowchart Diagram
for Is this really an Incident? . . . . . . . . . . . . . . . . . . . 119
D.5 ITIL Incident Management Cross-Functional Flowchart Diagram
for Incident Categorization and Prioritization . . . . . . . . . . 120
D.6 ITIL Incident Management Cross-Functional Flowchart Diagram
for Incident Matching, Initial Diagnosis and Escalation . . . . . 121
D.7 ITIL Incident Management Cross-Functional Flowchart Diagram
for Incident Resolution, Recovery and Closure . . . . . . . . . . 122

xii
 LIST OF FIGURES

D.8 ITIL Incident Management Cross-Functional Flowchart Diagram

for Search Incident . . . . . . . . . . . . . . . . . . . . . . . . . 123
D.9 ITIL Incident Management Cross-Functional Flowchart Diagram
for Change Incident Status or Owner . . . . . . . . . . . . . . . 124
D.10 Part one of Problem Management Business Process . . . . . . . 125
D.11 Part two of Problem Management Business Process . . . . . . . 126
D.12 Part three of Problem Management Business Process . . . . . . 127
D.13 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Problem Identification . . . . . . . . . . . . . . . . . . 128
D.14 Part one of ITIL Problem Management Cross-Functional Flowchart
Diagram for Problem Categorization and Prioritization . . . . . 129
D.15 Part two of ITIL Problem Management Cross-Functional Flowchart
Diagram for Problem Categorization and Prioritization . . . . . 130
D.16 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Problem Investigation and Diagnosis . . . . . . . . . . 131
D.17 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Workarounds and Known Errors . . . . . . . . . . . . 132
D.18 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Problem Identification . . . . . . . . . . . . . . . . . . 133
D.19 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Search Problem . . . . . . . . . . . . . . . . . . . . . . 134
D.20 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Change Problem Status or Owner . . . . . . . . . . . . 135
D.21 ITIL Problem Management Cross-Functional Flowchart Dia-
gram for Known Errors Management . . . . . . . . . . . . . . . 136

E.1 BPMN Ontology graph . . . . . . . . . . . . . . . . . . . . . . . 138

F.1 First Semester Work Schedule . . . . . . . . . . . . . . . . . . . 142

F.2 Second Semester Schedule . . . . . . . . . . . . . . . . . . . . . 144

xiii
 List of Acronyms

API Application Programming Interface

AUP Agile Unified Process

BPMN Business Process Model and Notation

CBSE Component-based Software engineering

COBIT Control Objectives for Information and related Technology

IT Information Technology

ITIL Information Technology Infrastructure Library

ITSM IT Service Management

MVC Model-view-controller

RDF Resource Description Framework

ROI Return on Investment

RUP Rational Unified Process

SDB Service Delivery Broker

SES Software Enabled Services

SLR Service Level Requirements

SPM Service Portfolio Management

SPMS Service Portfolio Management Syste

UML Unified Modeling Language

USDL Unified Service Description Language

WAF Web Application Framework

xv
 List of listings

1 Example of Django Models definition. . . . . . . . . . . . . . . . 62

2 View for listing all buyers of ITSM Services from a providing
company. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3 Template for Editing the attributes of a Running ITSM Service. 64
4 Script to get the form for editing a service through an AJAX
request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 Add or replace the publisher of a certain service in the Triple
Store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6 SPARQL query for retrieving information regarding an ITSM
Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7 Configuration of PostgreSQL DBMS. . . . . . . . . . . . . . . . 69

xvii
 Introduction
1
This chapter is organized in five sections. The first section describes the
problem context and placement. The second section describes the issues of
implementing a viable Information Technology Service Management (ITSM)
solution. The third section presents the motivation, highlighting the added
value and the innovative characteristics of this work. The fourth section de-
fines the overall goals and requirements. Finally, the last section describes a
preliminary thesis planning.

1.1 Problem Contextualization - Placement

With the appearance of IT (Information Technology), the need to manage
information in order to manage services has steadily increased. Therefore,
service providers need some sort of proven management framework to ensure
a high service quality & performance ratio. However the adoption of such
frameworks comes with adoption costs.
When implementing ITSM solutions companies might want to take different
approaches due to standards, dimension or specific industry policies issues.
Today, the software provided to manage companies ITSM services solutions
is limited, it does not take into account that companies might want to adopt
best practices or similar industry practices from service provider companies.
The main goals of this work are:

1. Alongside our SAPO partners contribute to the cost reduction of such

expensive implementations, by providing a set of interfaces that can, at
worst case scenario, serve as guidelines for ITSM;

2. Build a proof-of-concept application facilitating a plug-and-process ap-

proach when composing information management services, by taking ad-

1
 CHAPTER 1. INTRODUCTION

vantage of the developed ITSM interfaces. More specifically, a Service

Portfolio Management System (SPMS), which consists in an application
that operates as an analysis tool for services, which can be used by sys-
tems analysts or architects for building ITSM customizable solutions.

1.1.1 Organizational Context

This project was developed in the Department of Informatics Engineering

(DEI)1 of the University of Coimbra (UC)2 within the engineering masters
program3 . It counted with the support and collaboration of the Centre for
Informatics and Systems (CISUC)4 , more specifically the Information Systems
Group5 , it also count with the help and contribution of the people and resources
from Genssiz: Center for Service Systems Research6 .
During this thesis development we counted with the valuable help of our
partners at SAPO 7 , a Portugal Telecom (PT)8 subsidiary Internet Service
Provider. They provided the chance, expertise, as well the financial help, to
develop this project. Some artifacts defined within this thesis, will contribute
to SAPO Service Delivery Broker (SDB)9 and to the TM Forum Software
Enabled Services (SES)10 .
The users of ITSM services are the final clients of this project. At a first
level the organizations implementing ITSM Services are the clients, they pro-
vide their functional IT services (managed by ITSM Services) for their cos-
tumers.
This work also contributes to the the Information Technology Infrastruc-
ture Library (ITIL[19]) community, promoting companies financial savings,
through an ITIL 2011 practices adoption bypass.

1
Department of informatics engineering - http://www.uc.pt/en/fctuc/dei/quemsomos.
2
University of coimbra history - http://www.uc.pt/en/sobrenos/historia.
3
Department of informatics engineering - masters in informatics engineer- ing -
http://www.uc.pt/en/fctuc/dei/ieng/msc.
4
Cisuc centre for informatics and systems of the university of coimbra -
https://www.cisuc.uc.pt/home.
5
Cisuc centre for informatics and systems - information systems group -
https://www.cisuc.uc.pt/groups/show/is.
6
Genssiz: Center for service systems research - http://www.genssiz.org.
7
SAPO - http://www.sapo.pt
8
Portugal Telecom - http://www.telecom.pt/internetresource/ptsite/uk/canais/sobreapt
9
SDB - http://sdb.sapo.pt/en/index.html
10
SES - http://www.tmforum.org/softwareenabledservices/4664/home.html

2
 1.1. PROBLEM CONTEXTUALIZATION - PLACEMENT

1.1.2 Economic and Social Context

The present economical context, forces companies to cut expenses, which
might decrease the consumption rates and therefore cause service prices to drop
as well. So service providers need a way of keeping efficiency and effectiveness,
with minimum impact to service level.
Implementing ITSM solutions is a proven strategy of reducing structural
costs and optimizing their information management practices. By doing so,
IT service providers reduce costs and gain flexibility, by creating new services.
This work will allow organizations to adopt ITIL practices, in a faster and less
expensive way, through a set of ITIL interfaces.

1.1.3 Technological Context

During this project we relied in technologies, Languages, Notations, Frame-
works, etc.

1.1.3.1 Languages
In this work we resort to several languages as follows:

Descriptive Languages Are used to describe artifacts, schemas that rep-

resent something that can be described by a language, in this specific case
services. In this project we recur to the following:

• RDF/OWL- Both were used to ontologically represent and describe the

services and interfaces, “RDF is a standard model for data interchange on
the Web. RDF has features that facilitate data merging even if the under-
lying schemas differ, and it specifically supports the evolution of schemas
over time without requiring all the data consumers to be changed.”[18],
“OWL builds on RDF and RDF Schema and adds more vocabulary
for describing properties and classes: among others, relations between
classes (e.g. disjointness), cardinality (e.g. ”exactly one”), equality,
richer typing of properties, characteristics of properties (e.g. symme-
try), and enumerated classes.”[21]. The use of both languages became
advantageous, since its attributes make it extremely interoperable.

• USDL - is “a platform-neutral language for describing services consoli-

dated from SAP Research projects.”[34] and, as Cardoso, Barros, May
and Kylau state[3]: USDL “has been created to provide a solution to
describe services from a business, operational and technical (BOT) per-
spective (...) USDL enables organizations to describe and publish their

3
 CHAPTER 1. INTRODUCTION

business services by describing their BOT characteristics to enable con-

sumers to discover and select services.”.

• Linked-USDL - is “a remodeled version of USDL that builds upon the

Linked Data principles and the Web of Data. This effort is therefore most
concerned with remodeling the existing USDL specification as an RDF(S)
vocabulary that could better support machines in trading services on
the Web.”[34] Since it uses RDF(S)[18], Linked-USDL is much more
interoperable than USDL (which resorts to XML Metadata), as we can
verify with what was cited by Decker, Melnik, van Harmelen, Fensel,
Klein, Broekstra, Erdmann and Horrocks[12]: “RDF better facilitates
interoperation because it provides a data model that can be extended
to address sophisticated ontology representation techniques.”. Linked-
USDL is used to describe the service in a way that allow companies to
package, and export, their services to other platforms.

• WSDL - It is used for specifying technical services, by “describing net-

work services as a set of endpoints operating on messages containing
either document-oriented or procedure-oriented information. The opera-
tions and messages are described abstractly, and then bound to a concrete
network protocol and message format to define an endpoint. Related con-
crete endpoints are combined into abstract endpoints (services).”[6]. We
we use it to describe interface operations, used for ”feeding” the SPMS
services with interface information.

Programming Languages For the development of the Service Portfolio

Management System we selected the Python programming language11 , through
a development on top of the Django Web Framework12 , mostly because it is the
most familiar programming language to the author and provides abstract in-
terfaces (RDFLib13 and RDFLib-PostgreSQL14 ) for working with RDF/OWL.
In order to provide a more pleasant browsing experience to the users, we
used jQuery15 combined Bootstrap16

Notations In order to model ITIL practices interfaces, we used Business

Process Model Notation (BPMN)[41]. It is broadly accepted by the industry
and has primary goal to “provide a notation that is readily understandable
11
http://www.python.org
12
https://www.djangoproject.com
13
https://rdflib.readthedocs.org/en/latest/
14
https://github.com/RDFLib/rdflib-postgresql
15
http://jquery.com
16
http://getbootstrap.com/2.3.2/

4
 1.2. PROBLEM IDENTIFICATION

by all business users, from the business analysts that create the initial drafts
of the processes, to the technical developers responsible for implementing the
technology that will perform those processes, and finally, to the business people
who will manage and monitor those processes.”[41].

1.1.3.2 Frameworks

ITIL Information Technology Infrasctructure Library (ITIL) consists in a

set of ITSM best practices, addressing the IT service management. It was
gathered and compiled into a series of books by the Central Computer and
Telecommunications Agency (CCTA) and, on a later stage, by the Office for
Government Commerce (OGC), forming a framework that covers the manage-
ment of service’s lifecycle.
ITIL became the most popular framework for ITSM implementation. Pereira
and Silva state that [43] “It has been proven that when well implemented ITIL
allows organizations to provide services with greater efficiency, effectiveness,
quality and cost reduction”. As result, ITIL is the most adopted framework by
worldwide organizations and it is still growing: at June 2011 was estimated,
by the APM Group, that ITIL adoption has increased 20% per annum and
that the number of ITIL training attendees is increasing at a rate of 30% over
the last decade[16].

1.2 Problem Identification

Within the explained context, we identified two major problems that this
thesis addresses:

• Problem 1 -There are some concerns when some organization(s) only

want to adopt a sub-set of ITIL practices. Not only because it comes with
high costs but also due to the fact that such organizations might have to
recur to someone with ITIL certification in order to get this very focused
job done properly, or, instead, send someone within the organization to
get ITIL certification, just to implement a small portion of it.

• Problem 2 - The service world has a clear lack of a cloud ITSM service
portfolio management system that allows companies to adopt services,
technical interfaces and business processes already specified by ITSM
provider companies.

5
 CHAPTER 1. INTRODUCTION

1.2.1 Business and Management Aspects

Even though ITIL allows organizations to provide services with greater
efficiency, effectiveness, quality and cost reduction, as Pereira & Silva state[43],
“ITIL comes with big implementation costs which renders the decision to go
forward with such a transition a non-trivial one. Some think twice before
progressing with it”. Combining this with the fact that some may not yet
achieved financial return of the investment, constitutes a problem.
It should be stressed that “The obstacles to adoption are real, and benefits
are sometimes difficult to quantify”, some of the “barriers to adoption include
lengthy implementation, disruption of current processes, high up-front training
costs, and relatively slow return on investment”[14].
Subsequently, in order to ease such issues, we aim to develop a methodol-
ogy for ITSM service interfaces construction and provide specific ITIL service
interfaces, such as the ones present in Incident Management procedure. This
work helps companies to:
• increase Return on Investment (ROI) - ROI represents “a concept for
quantifying the value of an investment”[7], it is likely when companies im-
plement our interfaces that they save considerable implementation costs,
as well as costs associated with ITIL training without losing the benefits
of an ITIL implementation;

• reduce implementation risks and time - the developed interfaces are in

conformance with ITIL so the risks of failing or missing implement ITIL
are lower. Since part of the implementation is already provided in form
of interface(s), implementation time should be reduced;

• offer the possibility of increased flexibility - enhancing flexibility in devel-

opment of new services for clients, since the interfaces can serve as service
components, and therefore can be combined with other functional inter-
faces in a lot of ways;

1.2.2 Technical Aspects

The adoption of ITIL is growing[16], however some development teams,
unknowingly, adopt solutions similar to ITIL, probably repeating procedures
since there is no shared or standard set of ITIL interfaces. Our solution,
enables not only a bypass in ITIL adoption, but also a basic and normalized
solution, for ITIL processes.
Such interfaces will use the methodology described by Malcolm Fry [17]
based on designing and documenting process flow of services, or service com-
ponents.

6
 1.3. MOTIVATION

Nowadays, a lot of functional services, or functional service interfaces (more

specifically APIs), are available in cloud computing structures, like SAPO
SDB. Therefore, there should be a set of ITIL programming interfaces avail-
able on the cloud. SAPO is currently working on a solution and selected 19
ITIL functions out of a universe of 30 to develop, some of which, with our
collaboration.
The ITIL interfaces of such solution will be part of SAPO SDB service
offerings, which clients can use to bundle in their own applications in order
to manage their functional IT services, or can be offered as individual service
(e.g. independent interface/application for a company to manage its problem
records). It is also possible that SAPO develops an application, or web ser-
vice, based on the developed ITIL interfaces, that is provided as a service,
individually or composed with other services.

1.2.3 Social and Economical Aspects

Companies implementing ITSM practices, as ITIL, will help to ease the
need of having persons performing boring and annoying support and manage-
ment tasks. Subsequently, persons are granted with the opportunity of working
on more challenging and enjoyable labor functions thus contributing to their
psychological well-being. Our work will allow to build a solution where people
can be softly shifted to more enjoyable work positions.
Economically speaking a considerably return of capital can be achieved, by
saving costs associated to ITSM professionals hiring, or with the allocation of
human resources to ITSM specific training. With ITIL interfaces adoption,
companies save money while maintaining a steady consumption rate, without
the need of built everything from scratch.

1.3 Motivation
It is motivating to know that our work can have a major contribute in
the technological world. A variety of entities will gain with the successful
realization of this thesis, mostly because we present a fresh way to ease ITSM
implementation allowing an easier way in which to get value.
With this work the University of Coimbra, DEI CISUC, CISUC-ISG and
Genssiz contribute for the process of standardization, flexibility and automa-
tion of service management, more precisely, IT services, gaining reputation
and credit with the successful development of this project.
PT (SAPO) will benefit from getting a set of defined ITIL interfaces, as
well as the know-how of all the development of such interfaces. All SAPO SDB

7
 CHAPTER 1. INTRODUCTION

clients that will make use of the interfaces or applications based on it, which
makes the development of this thesis it extremely motivational.
IT service providers can execute a bypass in order to properly implement
ITIL, or some kind of ITSM approach, only by adopting a set of interfaces
defined in this project, which leads to time, effort, resources and financial
savings.
Since “Customers are outsourcing the delivery and support of their IT
Services to Telcos, so Telcos are offering IT Service Management as a sellable
service”[24], Telcos play a big role in IT service management. They can make
use of IT service components (interfaces) in order to manage sellable services,
so they can act as IT service providers as well as ITSM service providers.
TMForum17 will receive a set of ITIL interface specifications. This way, any
Communications Service Provider can adopt such interfaces and if they prove
to be successful, we can hope for some sort of ITIL interfaces specifications
standardization, which would be a great, probably the biggest, achievement
for all involved parts in this work.
All ITSM service providers, or organizations implementing ITSM, as well
as its clients will benefit from this work, since this project has, as objective, the
decrease of investment that organizations have to undergo for ITSM adoption.
We hope to contribute, as well, to a normalization of the ITIL levels, since
a study from November 2011[16], by the AMP Group, points that: “ITIL
adoption levels are clearly different around the world”. If our developed in-
terfaces became widely accepted, they would likely serve as a base for such
normalization, as companies adopting them, fully or partially, could compare
adoption levels between them with less effort, since the fundamental practices
were similar.
For the IT General Community, this project represents a step towards the
evolution of ITSM adoption, and will act as a principle, guideline, or even
as a standard for ITSM companies, which leads to a more agile and quicker
implementation of ITSM best practices.
Our proposed approach brings an all new perspective to the eyes of IT
services providers, since in order to be in conformity with ITIL, they only have
to adopt, some or all of the interfaces hereby developed. Taking advantage
of our new proposed approach is translatable into an ITSM adoption cost
reduction, not only at a financial level but as well at resources, effort and
time.

17
TMForum - http://www.tmforum.org

8
 1.4. OVERALL GOALS AND REQUIREMENTS

1.4 Overall Goals and Requirements

What is ultimately proposed in this thesis is:
• Objective 1 - In partnership with SAPO, create, build and model a
set of Abstract IT service components[13] (ITIL Interfaces). Despite the
fact that such Abstract IT service components are tailored for ITSM,
we will specifically use them to map ITIL practices and since such are
specific instances of IT service components, they can have an associated
abstract IT service component (interface).
The template associated with each interface includes a BPMN schema
of the respective component, a description of the component, a cross-
functional flowchart diagram and the associated ITIL information object[30]
(Transitions: Inputs & Outputs). Templates have enough information re-
garding transitions, processes and services, allowing the usage of a “Plug-
and-Process” paradigm, which consists in “reusability, plug-replaceability
(...) and extensibility”[42].

• Objective 2 -This work also has, as objective, the implementation of

a service portfolio management application. More specifically an ap-
plication that gathers services descriptions and specifications, which se-
mantically correlates stored service information with what the clients are
looking for. Services descriptions and specifications, will contain relevant
information about service.
Another quality this project brings to the table, especially if it contributes
towards a standardization, is a decrease of the difficulty in measuring the ITIL
adoption levels. Despite not being the central concern of this project, it can
help to lead to a standardization of ITIL adoption levels, easing the comparison
between organization ITSM practices, since there’s no need for surveys if they
both use a similar set of interfaces.

1.5 Planning
Like all other software development projects, this thesis performs a thor-
ough planning analysis by adopting elements of a proven methodology, per-
forming rigorous risk management and scheduling project tasks.

1.5.1 Development Methodology

The adopted methodology for the is based on the Agile Unified Process
(AUP)[1], since “It describes a simple, easy to understand approach to de-

9
 CHAPTER 1. INTRODUCTION

veloping business application software using agile techniques and concepts yet
still remaining true to the RUP”. RUP stands for Rational Unified Process,
which is an unified software development methodology, that takes advantage
of the experience of the process of standardization and concepts of Unified
Modeling Language (UML)[50].
From AUP we reuse the following disciplines:

• Model - Since there is a need to “understand the business of the organi-

zation, the problem domain being addressed by the project, and identify
a viable solution to address the problem domain”;

• Implementation - There is also a need to “Transform model(s) into

executable code and perform a basic level of testing, in particular unit
testing”;

• Test - All built artifacts from the implementation discipline are targeted
by an “objective evaluation to ensure quality. This includes finding de-
fects, validating that the system works as designed, and verifying that
the requirements are met.”;

• Deployment - The developed interfaces for SAPO are planned “for

delivery (...) and to execute a plan to make the system available to end
users”. It is important to state that our application, at least an early
version, is not being developed having deployment in mind, however
the application can be deployed to a cloud-based infrastructure (like
Heroku18 ) for test or presentation purposes;

• Project Management - There is also a need to manage risks and to

coordinate “with people and systems outside the scope of the project to
be sure that it is delivered on time”;

• Environment - During the course of this thesis it is ensured “that the

proper processes, guidance (standards and guidelines), and tools (hard-
ware, software, etc.) are available (...) as needed”;

The methodology hereby presented also relies in the concepts of incremen-

tal and iterative processes. Meaning that the scope and achievement of the
system is refined little by little and is enlarged little by little during the project
progress[51].
18
http://www.heroku.com

10
 1.5. PLANNING

1.5.2 Risk Management

In order to perform a proper risk management we opt to use the process
described by Sommerville[47], that defines the following considered stages:

1. Risk identification - “Identify possible project, product, and business

risks.”;

2. Risk analysis - “Access the likelihood and consequences of these risks.”;

3. Risk planning - “Make plans to address the risk, either by avoiding it

or minimizing its effects on the project”;

4. Risk monitoring - “Regularly assess the risk and your plans for risk
mitigation and revise these when you learn more about the risk”;

It should be pointed that after risk definition, the risks were sent to super-
visors for reviews, which originated some corrections that were made during
the thesis course.
Figure 1.1 Shows Sommerville’s risk process flow.

Figure 1.1: Risk process

Figure 1.2 Shows the risks, affection, type, description, probability, effect,
strategies and possible indicators considered during the course of the project.

11
 CHAPTER 1. INTRODUCTION
12

Figure 1.2: Risk management

 Related Work and State-of-the-Art
2
This chapter is organized in two sections. The first section addresses the
relevant work already developed by others that could add value to our work, or
that has been analysed in order to increase our background knowledge required
to perform this thesis. The second section includes the analysis and review of
the alternatives to our application and ends with a critical overview of such.

2.1 Related Work

Software engineering evolved during the course of time. Nowadays, a big
part of software development is based in software reuse. Sommerville states
[47] that, this approach “tries to maximize the reuse of existing software”, it
also has “an obvious advantage”, being “that overall development costs should
be reduced”.
Part of the work that we present, alongside with SAPO, concerns the cre-
ation of ITIL services defined, at a practical level, by a set of ITIL best practices
interfaces (e.g. Incident Management), which are part of what is defined as
reusable components, or services.

2.1.1 ITIL & eTOM Compatibility

Telcos usually adopt eTOM1 (enhanced Telecom Operations Map), pub-
lished by TMForum, which consists in a guidebook that defines the most
widely used and accepted standard for business processes in the telecommu-
nications industry. Actually, SAPO SDB team is working in the alignment
with eTOM [9]. ITIL and eTOM can work alongside each other, as stated
by Jenny Huang[24], “ITIL can be used very effectively in conjunction with
1
http://www.tmforum.org/BusinessProcessFramework/1647/home.html

13
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

eTOM in that it will assist in creating a more complete Enterprise Business

Process Framework which includes all the functional elements needed for IT
support processes”.

2.1.2 Developed ITIL Process Design Methodology

Malcolm Fry [17], developed considerable and related work in his book
“ITIL R Lite - A road map to full or partial ITIL implementation.”, regarding

ITIL process design.

His methodology focuses on just two steps:

1. Step 1 Design the process flow.

2. Step 2 Document the flow (this would also include installing metrics
etc.).

Malcolm’s process design procedure [Figure 2.1] includes four major defini-
tions that we will reuse in this thesis for the creation of interfaces and respective
BPMN process schemas:

• Transmission - “The method to get from one process activity to an-

other process activity”[17] (e.g. e-mail message), is subdivided in two
descriptive groups, inputs and outputs, constituting an ITIL informa-
tion object[30].

• Activity - “Where an activity has to be performed as a stage or step

in the process.”[17] (e.g. incident escalation). The description of the
activities will go further than that and will be, as ”defended” by Papa-
zoglou and Yang [42], a description of the signature of an operation that
is available to the service client for invocation.

• Work Instruction - “Work instructions are often procedure based and

explain how we should perform our activities. They are also used to build
parameters and rules for automation technology”[17] (e.g. If a priority
1 is allocated then the business contingency process must be initiated).

• Control and Quality (metrics) - “Control and quality is the final

piece in the jigsaw, where we put in place rules, controls and metrics to
ensure the highest possible levels of quality and accuracy”[17] (e.g. 99%
of all incidents are escalated to the correct support group at the first
time). This is where we make our work ready for the use of COBIT[25],
which in simple terms is a practice that applies checks and balances IT
and, in particular service management processes [17], for instance by

14
 2.1. RELATED WORK

comparing the targeted metrics with the real actual occurrence metrics
(e.g. we consider a target of 99% for all incidents to be escalated to
the correct support group first time, but in reality only 95% of incidents
are properly escalated in the first time, this can mean a lot of things, for
instance it can mean that the escalation procedure needs to be changed).

Figure 2.1: Malcolm Fry Methodology for process design.

2.1.3 Component
Component-based Software engineering (CBSE) emerged, and it is de-
scribed by Sommerville [47], as “the process of defining, implementing, and
integrating or composing loosely coupled, independent components into sys-
tems.”.
Our work takes into consideration an essential point of CBSE, approached
by Sommerville, more specifically, that “there should be a clear separation
between the component interface and its implementation. This means that one
implementation of a component can be replaced by another, without changing
other parts of the system”. This is why we only define interfaces, because some
might want to develop, or change, specific component implementations, (e.g.
the incident matching implementation can be different between two distinct
service providers, or the same service provider might want to update the way
that it performs the incident matching).

15
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

Since we developed interfaces associated with components, it should be

clarified exactly what do we understand by ”component” in order to have an
overall view of were interfaces stand, at a scientific level. Even if do not go for
”the long run” of developing specific and complete components.
We considered the two definitions of components, pointed out by Som-
merville.

• Council and Heineman [8], define component as: “a software element that
conforms to a component model and can be independently deployed and
composed without modification according to a composition standard.”;

• Szyperski [49] defines component as: “A software component is a unit of

composition with contractually-specified interfaces and explicit context
dependencies only. A software component can be deployed independently
and is subject to composition by third parties.”

2.1.3.1 Component as a Service

Sommerville states[47], regarding the above definitions, that “both of these
definitions are based on the notion of a component as an element that is
included in a system, rather than a service that is referenced by the system”.
He also points that a “notion of a component as a service was developed”, in
response to problems such as the standards and protocols that “have hindered
the uptake of CBSE”, since they are “complex and difficult to understand”.
This way, if components are, in fact services the reuse or integration processes
will be eased, since we do not need to have concerns regarding the combination
of different components using different technologies (e.g.NET and J2EE).
In light of the above, since we need a definition of component more from
a component as a service perspective, we based our definition in the “critical
characteristics” of reusable components, pointed out by Sommerville [47], and
came up with the following definition:
A component is an independent executable entity that is defined
by interfaces, abstracting itself from source code, which could be
referenced as an external service or included directly in a program.

2.1.3.2 Abstract IT Component

The components, or services, discussed above should be defined and speci-
fied as an Abstract IT Components perspective, which is defined by Dudeck,
Ubernickel & Brenner [13] “represent the templates for specific instances of IT
service components”. Therefore we consider the template adopted for repre-
senting components and its interfaces as an Abstract IT Component.

16
 2.1. RELATED WORK

2.1.3.3 ITIL (2011) and ITSM Components

ITIL 2011 Components Fry [17] considers the twenty six processes and
four functions that one can choose in order to properly implement ITIL. Such
are denominated, in his work, as ”ITIL 2011 components”.
Figure 2.2 Shows the processes and functions considered by Fry.

Figure 2.2: ITIL 2011 Processes and Functions.

In fact, Fry[17] categorizes such components in four distinct categories:

• Action Components - “require actions of operational nature to be
performed as part of their normal functionality”, (e.g. Service Desk,
Incident Management, Problem Management, Event Management, etc.);

• Influencing Components - “modify and influence the way that action

components perform their actions” (e.g. Service Level Management, Ser-
vice Validation and testing, Service Catalogue Management, etc.);

• Resourcing Components - “ensure that the other components have

the resources to meet their service commitments”(e.g. Capacity Manage-
ment, Availability Management, Transition Planning and Support,etc.);

• Underpinning Components - “provide the underpinning facilities re-

quired by all components. Some of these components, such as financial

17
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

management, may also serve other areas of IT.” (e.g. Financial Manage-
ment, IT Service Continuity Management, Strategy Generation, etc.);

ITSM components The notion, provided by Fry, of ”ITIL component”, can

be abstracted to ”ITSM Component” and therefore an ITSM service can be
considered a component that implements ITSM (not obligatorily ITIL), such
component reflects a practice that some company adopts in order to manage
certain IT services.
Such definition does not conflict with the definition, provided above, of
”component”, since ITSM services (or components), can be defined by inter-
faces and could be referenced as external services or included directly into a
program.
It is important to define component at an ITSM level, since some companies
are not interested in general best-practices (ITIL), therefore they look for ITSM
practices of other companies in the same business sector. If such have already
been specified there is no reason to want to adopt a generic ITIL solution
instead of a proven solution, implemented by similar companies, generating a
win-win situation for both consumer and provider companies.

2.1.4 Interface
As Sommerville states [47], “the services offered by a component are made
available through an interface and all interactions are through that interface”
and “an important part of any design process is the specification of the inter-
faces between the components in the design” therefore there is a need for us
to clarify what we do understand by ”interface”.
Council and Heineman [8] define interface as “An abstraction of the be-
havior of a component that consists of a subset of the interactions of that
component together with a set of constraints describing when they may oc-
cur. The interface describes the behavior of a component that is obtained
by considering only the interactions of that interface and by hiding all other
interactions.”.
Silva and Vieira [51] define interface as “a contract, in a form of a col-
lection of operations definitions, which provides a mechanism for a clear sep-
aration between an external and internal view of a determined element and
allows establishing ”client-provider” relationship mediated by the notion of
”contract”.”.
Papazoglou and Yang [42] state that “interface is the description of the
signatures of a set of operations that are available to the service client for
invocation.”.

18
 2.1. RELATED WORK

In light of the above we consider interface, to be:

An abstraction and description of the behavior, more specifically

operations (in the form of signatures) regarding a software com-
ponent, providing a clear separation between external and internal
view.

The interfaces contain information regarding Fry’s [17] Activities, Trans-

missions, Work Instructions and Control and Quality metrics.
Each ITIL interface is specified using a standard template for specific ITIL
components (Abstract IT Component) and within it, information regarding
the ITIL component transmissions (inputs and outputs), in other words, as
explained in 2.1.4.1, ITIL information objects.

2.1.4.1 ITIL Information Object

As Sommerville states [47], “The services offered by a component are made

available through an interface and all interactions are through that interface.
The component interface is expressed in terms of parameterized operations
and its internal state is never exposed.”.
Such interactions, or as Fry[17] define it, such transmissions, between op-
erations, or activities, can be performed in two ways, as input, or output.
Therefore every Abstract IT Component has present, in its interface, such
transmissions.
Kempter & Kempter[30] dub such input and output flows as ITIL Informa-
tion Objects, posteriorly reused by Wang [52], there is a necessity of including
this definition, since “Process levels are usually contemplated as a step of sepa-
rate project before getting involved in process internal parts in detail. Indeed,
before being able to introduce detailed activities, should be clarified what out-
puts need to be produced by a process, and what inputs a process ought to
expect prior processes”.

2.1.5 Service Design Principles

As well as Papazoglou [42], we considered “two well-known software design
guidelines: coupling and cohesion” since these “garantee that services are self-
contained, modular and able to support service composability”.
Service, or component, interfaces will represent actions (atomic or not),
and interactions between them as well as the order they follow are represented
by business processes.

19
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

2.1.5.1 Coupling

In terms of Service coupling “the objective is to minimize coupling, that

is, to make (self-contained) business processes as independent as possible by
not having any knowledge of or relying on any other business processes”[42].
This overlaps with the definition of discrete process provided by Fry[17]: “A
discrete process is a stand-alone process that can be completed in a linear fash-
ion without impact from another process.”. As explained by de Champeaux,
Lea and Faure [11], and reused by Papazoglou and Yang [42]: “The central
tactic” for low coupling, “stems from the ideia of abstract classes in object-
oriented design where composite classes and actions minimize dependencies on
irrelevant representional and computational details”.

2.1.5.2 Cohesion

In terms of cohesion, during the ITIL interfaces development, we created

“strong, highly cohesive business processes, business processes whose services
and service operations are strongly and genuinely related to one another.”[42].
Since ITIL publications already describe some processes of the components
(services), operations (activities) and transmissions, components and opera-
tions are already related to one another.
If there is no process ”recommended” by ITIL publications, then we should,
as proposed by Fry[17], answer five questions (present in Figure 2.3) in order
to extrapolate the activities from an ITIL practice, and posteriorly build the
related process, and interface, using a procedure for building ITIL processes,
pointed by Fry (Present in Figure 2.4). It should be noticed that the ac-
tivities will be, as well, developed using ITIL descriptions and therefore the
components (services) and their activities are related to one another.

Figure 2.3: Fry’s “Five key process questions”.

20
 2.1. RELATED WORK

Figure 2.4: Fry’s procedure for building ITIL processes.

2.1.6 Service Description

Since our project aims to build a Service Portfolio Management System,
we need to describe services in a formal notation or language.
As pointed by Cardoso et al. [4], “Service descriptions (e.g. WSDL,
SAWSDL, OWL-S, and WSMO) bring various ways to describe services’ in-
terfaces using schema, models and semantics.”.

Web Services Description Language WSDL is “an XML language for

describing Web services. This specification defines the core language which
can be used to describe Web services based on an abstract model of what the
service offers”[5]. WSDL is used to specify already developed interfaces that
will ”feed” SPMS ITSM Service specifications.

Semantic Annotations for WSDL SAWSDL, “allows description of ad-

ditional semantics of WSDL components. The specification defines how se-
mantic annotation is accomplished using references to semantic models, e.g.
ontologies”[33].

Semantic Markup for Web Services OWL-S, is an ontology of services

that allows users and software to “be able to discover, invoke, compose, and
monitor Web resources offering particular services and having particular prop-
erties, and should be able to do so with a high degree of automation if desired”[35]

Web Service Modeling Ontology The WSMO “provides a conceptual

framework and a formal language for semantically describing all relevant as-
pects of Web services in order to facilitate the automation of discovering,
combining and invoking electronic services over the Web”[10].

21
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

Linked-USDL We want to be able to adopt one language that richly de-

scribes services. Such description should emphasize, not only the services
technical part, but also business aspects, e.g. overall service price.
Since “USDL (...) models service concepts and properties such as ser-
vice level, pricing, legal aspects, participants, marketing material, distribu-
tion channels, bundling, operations, interfaces, resources, etc.”[4] it seems that
it should be considered. However it does not represent data using semantic
Web principles, which would be an advantage to our web application (Service
Portfolio Management System), since, as pointed by Berners-Lee et al.[46],
semantic web languages spread “enhance the Web’s functionality and interop-
erability”, and thus semantic Web brings important contributions to achieve
integration[4].
However there is a version of USDL that resorts to semantic web notation
to represent services, more specifically, “Linked-USDL emerged using semantic
Web principles (...). The goal of Linked-USDL is to develop an ontology to
represent services by establishing explicit ontological links to other existing
ontologies emerging from Linked Data initiatives.”[4]. Our work can benefit
from the use of Linked-USDL, since it “was designed based on Linked Data
principles and practices”[4] and allows a complete interoperable definition of
services.

2.1.7 Process Modeling

Since interfaces represent operations, there is a need to represent the pro-

cess flow in an orderly way.
Languages and notations for process modeling, such as BPEL, WS-CDL
and BPMN “use choreographies, control-flow elements, events, and temporal
dependencies (e.g. Sa is executed after Sb ) to define the valid sequences for
the invocation of services.”[4].

BPEL The Web Services Business Process Execution Language is “a lan-

guage for specifying business process behavior based on Web Services (...).
WS-BPEL provides a language for the specification of Executable and Ab-
stract business processes. By doing so, it extends the Web Services interaction
model and enables it to support business transactions. WS-BPEL defines an
interoperable integration model that should facilitate the expansion of auto-
mated process integration in both the intra-corporate and the business-to-
business spaces”[27].

22
 2.1. RELATED WORK

WS-CDL The Web Services Choreography Description Language “is an

XML-based language that describes peer-to-peer collaborations of participants
by defining, from a global viewpoint, their common and complementary ob-
servable behavior; where ordered message exchanges result in accomplishing a
common business goal”[29].

BPMN Business Process Model and Notation (BPMN), “represents the

amalgamation of best practices within the business modeling community to
define the notation and semantic of Collaboration diagrams, Process diagrams,
and Choreography diagrams.”[41]. According to Jana Koehler [31], this stan-
dard “provides a rich modeling notation for complex processes and process
colaboration”.
In light of the above, BPMN “creates a standardized bridge for the gap
between business process and implementation”[41] which is exactly what we
need to model ITIL processes. This way modelled ITSM processes can be
represented in a way that the persons, or organizations, developing ITSM so-
lutions based on our interfaces, can have a better understanding of the process
instead of only having a set of spread interfaces without clearing indication of
order of flow.
To ease the activities/interface mapping understanding, cross-functional
flowchart diagrams2 will are provided along with the BPMN diagrams.

2.1.8 Service Portfolio

We present a service portfolio management system, as an application, there-
fore we should stress what we mean by “Service Portfolio”.
Since we are already working with ITIL for developing interfaces and it
represents the best practices for ITSM, we thought that we should use its
definition of Service Portfolio. It is defined as being an artifact that “repre-
sents the commitments and investments made by a Service Provider across
all costumers and market spaces”[7] [40], whereas the term “market place”
stands for “a set of opportunities for service providers to deliver value to a
customer’s business through one or more services” [40]. More specifically the
Service Portfolio “represents contractual commitments, new service develop-
ment, and ongoing service improvement plans initiated by Continual Service
Improvement”, as well as, “third-party services, which are an integral part of
service offerings to customers”.[40].
2
http://office.microsoft.com/en-us/visio-help/
getting-started-with-cross-functional-flowcharts-RZ102657954.
aspx?section=2

23
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

The Service Portfolio is divided into three phases: Service Catalogue, Ser-
vice Pipeline and Retired Services (Figure 2.5).

Figure 2.5: Service Portfolio Subdivision.

2.1.8.1 Service Pipeline

ITIL defines Service Pipeline as “a subset of the overall Service Portfolio

and contains details of all of the business requirements that have not yet be-
come services released to the live environment”[39], more specifically, it “con-
sists of services under development for a given market space or costumer”[40].
Accordingly with ITIL [39], Service Pipeline should include services with
the following status:

• Requirements - a set of outline requirements have been received from

the business or IT for a new or changed service;

• Defined - the set of requirements for the new service are being assessed,
defined and documented and SLR is being produced;

24
 2.1. RELATED WORK

• Analysed - the set of requirements for the new service are being analysed
and prioritized;

• Approved - the set of requirements for the new service have been final-
ized and authorized.

2.1.8.2 Service Catalogue

Service Catalogue is defined in ITIL publications[40] as a “subset of Ser-
vice Portfolio visible to customers. It consists of services presently active in
the Service Operation phase and those approved to be readily offered to cur-
rent or prospective customers.It is in the Service Catalogue that services are
decomposed into components; it is where assets, processes and systems are in-
troduced with entry points and terms for their use and provisioning.”. Service
Catalogue also serves as “an expression of the provider’s operational capability
within the context of a costumer or market space”.
Service may have a subset of third-party (or outsourced) services. These
services can be offered to customers with varying levels of value or can be
combined with other Catalogue services [40].
According to ITIL [39], Service Catalogue should include services with the
following status:

• Chartered - the new service requirements are being communicated and

resources and budgets allocated;

• Designed - the new service and its constituent components are being
designed - and produced, if required;

• Developed - the service and constituent components are being devel-

oped or harvested, if applicable;

• Built - the service and its constituent components are being built;

• Test - the service and its constituent components are being tested;

• Released - the service and its constituent components are being released;

• Operational - the service and its constituent components are opera-

tional within the live environment.

2.1.8.3 Retired Services

Sometimes services become phased out or retired, for instance “If per-
formance drops below a threshold, then they are marked to retirement”[40].

25
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

When these Services become phased out, they are stored in a knowledge base
for future use.
A service with the retired status associated, means that the service and
its constituent components have been retired.
Figure 2.6 gives a better picture of ITIL Service Portfolio and its contents.

Figure 2.6: Service Portfolio and its contents.

2.2 State-of-the-Art

2.2.1 Solutions Analysis

In order to develop the Service Portfolio Management System we analyzed
other solutions that address the same problem(s), in a similar way.
In order to verify what’s the state of service portfolio applications in the
world, today, we analyzed five different solutions:

1. servicenowTM : Service Portfolio Management3 ;

R Service Portfolio Management4 ;

2. PLANEVIEW :
3
http://www.servicenow.com/service-portfolio.do
4
http://www.planview.com/products/enterprise/service-portfolio-management/

26
 2.2. STATE-OF-THE-ART

R Application Portfolio Management5 ;

3. IBM :

R Application Portfolio Management6 ;

4. HP :

R IT Service Catalog7 .
5. bmc :

For a better understanding of the state of portfolio systems nowadays we

further present a description of each and every solution considered.

servicenowTM SPM As could be extrapolated by the information that we

had access to, servicenowTM offers a service portfolio management that shows
services, their status and metrics, in a portfolio. However, no further informa-
tion regarding this solution could be drawn, is possible that another service
content is considered by them.

PLANEVIEW R SPM The most complete solution analyzed by us, “Plan-

view Enterprise Service Portfolio Management (SPM) delivers unprecedented

levels of transparency into services, assets, and applications, enabling you to
improve decision-making, reduce maintenance costs, and increase the value
you bring to the business.” and that they “incorporate the ITIL framework,
to provide a disciplined approach to service management.”. Consequently we
consider this solution to fully consider ITIL best practices for Service Portfolio
and their content.

IBM R APM The solution provided by IBM R consists in a Application

Portfolio Management (APM), which is defined by them as being “the prac-

tice of continuously assessing the applications that run on your business in
terms of their business value, enhancement potential, cost, and risk. APM
enables teams to make decisions about what actions to take with each of the
portfolio elements. It provides a transparent and objective process for manag-
ing investments in existing applications and can help teams make better and
faster decisions by using information gathering and analytics capabilities”.
This solution only considers applications, which not always can be seen (in
some case) as services. However ITIL Team [39], considers applications to be
content of services, and not to be services per se.
Even considering applications to be services, this solution, lacks in what
should be the descriptive content of a service, accordingly to ITIL. It also
5
http://public.dhe.ibm.com/common/ssi/ecm/en/raw14290usen/RAW14290USEN.PDF
6
http://www8.hp.com/us/en/software-solutions/software.html?
compURI=1174430#.UPQtNqWWTFI
7
http://www.bmc.com/products/product-listing/service-catalog.html

27
 CHAPTER 2. RELATED WORK AND STATE-OF-THE-ART

provides the following contents of service (that can in some way be linked to
ITIL ones):

• Applications (as explained pre- • Financial Analysis (which is de-

viously); scribed in ITIL by identify-
ing and analyze service costs,
• Workflows, which can be linked
charges, revenue amd metrics).
to what ITIL considers to be
business processes;

It should be stressed that likely more contents are present in this solu-
tion, however, the only clear ones that could be mapped to ITIL are the ones
described above.

HP R APM Like the previous solution, HP R only provides an APM. How-

ever, even if we consider, again, applications to be services, they lack in some

ITIL defined portfolio content. They provide a complete solution (for an
APM), describing: applications, their environment, service analysis, quality
surveys (wich can be transformed into metrics), ratings, service costs, service
charges, business processes, service status, owner, active users, objectives and
components. Despite the fact that they lack some service attributes, consid-
ered by ITIL, most of it can be linked to content described as service content
in ITIL publications.

bmc R ITSC This solution provides a complete service catalog solution,

however it lacks defining services from other scopes of the portfolio, namely:

• Demand Management; rather than have a bulk of silos

(to note that this holistic version
• Cost Transparency (which could
is relative to services within the
be linked to ITIL as describing
same organization);
the costs, charges and revenue
from services);
• Service Status, description and
• Holistic version of the services, SLAs(as described in ITIL).

Again, more contents could be present in this application, however no proof

of such was find by us in the solution description.

2.2.2 Critical Assessment of Existing Solutions

Is important to stress that the analysis made to Service Portfolio Man-
agement Applications is based on the available information, which may not
correspond to the whole real information.

28
 2.2. STATE-OF-THE-ART

Regarding the Solutions described in 2.2.1, some lack to consider all status
of portfolio services, only describing active services, some other only describe
applications that can be seen as a service, putting aside all other service status.
There is only one that is ITIL conformant, PLANEVIEW R SPM, however it

only provides management of the internal services of some organization, but

does not provide information about other practices considered to be the ”best
practices” or to be proven practices for their business sector.
None of the analyzed solutions provides a portfolio system for generating,
adding and exporting ITSM services metadata, neither proposes a cloud system
where organizations can adopt ITSM services specifications from ITSM com-
panies (e.g. consultant firm) and therefore adopt some of those services (prac-
tices) building better financial and ITSM operational solutions (instances) for
themselves and creating win-win situations for providers and consumers.

29
 Requirements Analysis
3
This Chapter is subdivided into two sections. The first one relates to
requirement elicitation, namely, finding out requirements by interacting with
stakeholders. The second section describes the requirements.
In this chapter we present the result of requirements analysis, which was
sent to all stakeholders so that revisions could be considered and performed.
We followed a FURPS+ requirements methodology and used a MoSCoW
analysis for specifying the requirements priority. For more information regard-
ing such, see Appendix B.

3.1 Requirements Elicitation

When performing requirements elicitation, we worked “with customers and
system end-users to find out about the application domain, what services the
system should provide(...), etc.” [47].
However ITIL publications [39] provide a set of questions in which ”ser-
vice portfolio either clarifies or helps to clarify”. Since ITIL presents a set of
gathered industry best practices, we considered such questions, presented by
ITIL, a “starting point” for eliciting the SPMS functional requirements of the
system:

• Why should a customer buy these services?

• Why should they buy these services from you?

• What are the pricing or chargeback models?

• What are my strengths and weaknesses, priorities and risk?

• How should my resources and capabilities be allocated?

31
 CHAPTER 3. REQUIREMENTS ANALYSIS

The requirements relating the interface(s) development were elicited in our

meeting with SAPO partners.
The elicitation of usability requirements were performed based on the “10
Usability Heuristics” by Nielsen[38].
Reliability, Performance, Supportability, Design, Implementation, Interface
and Physical requirements were elicited from the FURPS+ Document [15].

3.2 Requirements
As follows we present a list of the considered requirements, divided into
two categories:

1. Functional Requirements - “Statements of services the system should

provide, how the system should react to particular inputs, and how the
system should behave in particular situations. In some cases, the func-
tional requirements may also explicitly state what the system should not
do.”[47]

2. Non-functional Requirements - “These are constrains on the ser-

vices or functions offered by the system. They include timing constraints,
constraints on the development process, and constrains imposed by stan-
dards. Non-functional requirements often apply to the system as a whole,
rather than individual system features or services.”[47]

3.2.1 Functional Requirements

Functional requirements are based on completeness and Consistency[47]:
• Completeness - “means that all services required by the user should be
defined.”;

• Consistency - “means that requirements should not have contradictory

definitions.”;
Followingly we present, in natural language[47], the functional require-
ments:

F1. Register Company - The system must register a company into the in-
formation system, in order to provide authentication service for com-
panies, these need to be registered into the system.

F2. Log Company In - The system must allow companies, to identify

themselves as system users. In order to have access to some function-
alities, companies have to identify themselves.

32
 3.2. REQUIREMENTS

F3. Add ITSM Service Instance - The system must grant companies the
option of adopting available,“in file”, ITSM service solutions. One
of the goals of our work is to make possible for consumers to adopt ITSM
solutions, previously specified by ITSM providers. In order to add an
ITSM Service instance metadata, the service provider, has to explicitly
grant authorization to the requesting consumer.

F4. Allow ITSM Service Instantiation - ITSM Providers must explicitly al-
low consumers to adopt their set of proven ITSM service spec-
ifications. Only when providers agreed to provide a service metadata
specification to a company (through payment, trading or any other mar-
keting exchange method), companies can instantiate ITSM services.

F5. Add ITSM Service - It must be allowed to ITSM Providers to add ITSM
services (e.g. ITIL Incident Management). Companies that provide
ITSM solutions should be able to publish (or add) ITSM services in the
system.

F6. Import Workflow - The system should allow companies, when adding
an ITSM Service, to import a workflow model (BPMN2.0/XML).
This way the service has a structured flux in its metadata description.

F7. Import Interfaces - The system should allow companies, when adding an
ITSM Service, to import an interface specification (WSDL). This
way the service has a metadata description of the technical operations,
inputs and outputs.

F8. Edit ITSM Service - System should allow companies to edit ITSM
Services. When a service is updated to a newer version, a new service
record should be performed, instead of altering the “old” version, this
way, all versions remain available in the system. So only uninstantiated
ITSM services can be edited.

F9. Edit ITSM Service Instance Properties - The system must allow comsumer
companies to edit ITSM service instances metadata to some, or
all, of its properties. For example, a running ITSM service (instance)
with the “approved” status today can be “retired” in a matter of months,
therefore instances owners should be able to edit it.

F10. Search Service - The system must allow companies to search for ser-
vices in the system. Companies must be able to search for the ITSM
solutions available.

33
 CHAPTER 3. REQUIREMENTS ANALYSIS

F11. Browse Service/Instances - Companies must be able to browse a set

of ITSM services/service instances by category (e.g.ITIL action
services). If a company only wants to view (if it is only interested in
adopting some class ITSM services), for instance, action components,
then they should be able to view such services. This functionality its,
for instance, present in the same web page as the Search Service/Search
Service Instances requirements.

F12. View Own Portfolio - Each company must be able to view its own
service portfolio. Companies must be able to see all services present
in their portfolio so that they can manage their services properly and
have a better overall picture of their solutions.

F13. View Consumer Company Catalogue - ITSM Companies must be able

to view the consumer companies catalogues (active services only).
ITSM Companies should be able to see services in operational status of
their consumer companies. This will allow ITSM companies to sell ITSM
service specifications, that contain all the internal details of an “up and
running” service.

F14. Filter Catalogue Service Instances - The system, trough a filtering agent,
must be able to filter the edited instances of the ITSM services of
a provider. In order to present the catalogue of ITSM services instances,
the system has to check which ITSM services are in an operational phase
and then present those to the providing company.

F15. Filter Services by Searching Criteria - The system must group and
return all services that fit into the search specified by one specific
company. System must present the services with a certain characteristic
desired by the user.

F16. Filter Service Instance by category - The system must filter the ser-
vices by category (e.g. return only action components). When
browsing services, the system must be able to show only those from the
selected category.

F17. Export Service Instance - Users must have the possibility of exporting
the service to a service description language (e.g. Linked-USDL).
If the user wants to transpose the service present in our system to other
system it has to be able to export it to a interoperable representation.

F18. Search ITSM Service Instances - The system must allow companies to
search for service instances in the system. Companies must be
able to search for the adopted ITSM services.

34
 3.2. REQUIREMENTS

F19. Log Company Out - The system must allow companies, to become
unidentified in the system. Companies must be able to log out for
security measures, so that unauthorized entities are unable to make some
change to the system in their name.

F20. Display Services Status - The system should display an overview of

the services related to the company logged. When a company logs
in it should be possible to have a clear notion of the status of all the
services (e.g. the service is waiting for request to be accepted).

F21. Relate Interface operations With Process Activities - The system should
be able to interconnect interface operations of a service with
its own process operations. This functionality allows companies to
specify which operations are executed when a certain activity in a process
takes place.

F22. Provide Process Templates - The system should allow companies to

specify which process template they want to adopt by specifying
the company size. For instance, the incident management process for
a company with one hundred collaborators might be less complex than
for a company with one thousand.

F23. Assign Prices to Process Elements - The system should allow consumer
companies to associated costs to the elements of a service pro-
cess. This way consumers would be able to specify prices to all process
elements, which could lead to the extraction of valuable financial infor-
mations, from either a global perspective, as well as a individual one.

Sommerville recommends the development of a set of graphical system

models, such as, use case models, sequence diagrams and graphical mockups
(present in Appendix C). [47]
Figure 3.1 presents the use case diagram regarding the explained functional
requirements.

Selected Components for Interface Development It has to be stated,

that our partners at SAPO selected 19 out of 30 ITIL functions and processes
(Figure 3.2 shows such functions and processes), some, to be specified by
interfaces, with different priority level, therefore we present that agreement
in the form of four requirements:

SAPO1. Incident and Problem Management interface definition specification

- We must define interfaces Incident and Problem Management.

35
 CHAPTER 3. REQUIREMENTS ANALYSIS

Figure 3.1: Use Case Diagram.

The flow of such processes must be driven from ITIL publications and
must be described in interface specifications.

SAPO2. Present a Workflow Notation for each specified component - We

must present a diagram representing the workflow of the process
(BPMN Diagram). In order to help people understand which interfaces

36
 3.2. REQUIREMENTS

to call, their order and the way that messages are exchanged between
them (workflow) we shall specify the workflow in some notation (BPMN,
as previously justified).

SAPO3. Present the necessary cross-functional flowchart diagrams for each

specified component - We must present a set of diagrams represent-
ing the relation between process elements and interface oper-
ations of the ITIL function. This way we can provide clear examples
of which operations can be mapped to each activity, and provide some
guidance to those who will use the interface.

SAPO4. Insert interface specification into the SDB Backoffice - The inter-
faces specifications must be inserted in the SDB Backoffice after they are
validated by SAPO Partners.

Figure 3.2: Selected ITIL R functions and processes.

A.
c Cruz (SAPO, PT)

37
 CHAPTER 3. REQUIREMENTS ANALYSIS

3.2.2 Non-Functional Requirements

This class of requirements refers to the requirements that “are not directly
concerned with the specific services delivered by the system to its users”, “may
relate to emergent system properties such as reliability, response time, and
store occupancy”.[47]
The non-functional requirements are subdivided in four categories: usabil-
ity, reliability, performance and supportability.

Usability

U1. Indicate System Status - System should evince its own status. When
some performed action changes system status (e.g. Edit, Add or Delete
operations), the system should provide a clear statement informing the
“new” state.

U2. Minimize Disambiguation - The system should contain mainly sen-

tences that users understand. Sometimes a sentence can lead to
users’ misinterpretation, therefore system statements should be the most
clear and simple possible.

U3. Follow real-world conventions - The system should display functional-

ities in such a way that users implicitly understand. For instance,
destructive options, like cancelling, should have red as a background
colour.

U4. Allow Undo in web forms - System must allow users to undo operations
performed in the system. In the web forms (e.g. edit service instance)
the system should allow undo.

U5. Same terms for identical operations - The system terms must be consis-
tent. The system should refer to equivalent actions (or operations) with
same terms ,or icons, e.g. “cancel” in Edit Service web form must mean
semantically the same as “cancel” in Add Service web form.

U6. Present and Highlight errors - Errors originated by poor filling (e.g.
write letter in an number field) must be highlighted by the system.
When some user fails in properly filling a specific field, after the form
is submitted, the system must provide highlighted feedback to the user
explaining what went wrong.

U7. Limit Options - The system should present set of predefined values
when some properties are restricted to those values. When there is a

38
 3.2. REQUIREMENTS

system attribute that can only take limited values, the system should
only display those.

U8. Describe Input Fields - System should present a small description for
every input field. The system should present a description of each and
every input field, so that users understand exactly what is requested.

U9. Provide Accelerators - System must provide efficient ways so that new
users can effectively find any object. New users have to have ways
to find, for instance, an ITSM Service, in this case search forms provide
a quick way of finding what they are looking for.

U10. Describe errors and fixes in plain language - When an error occurs, the
system should present the error in a way that the user under-
stands it. There are only a some of persons that would understand
the meaning of an error code or the technical jargon used by some er-
ror descriptions, therefore errors should be presented in layman’s terms,
ideally the error fix should also be described.

U11. Provide Help Section - The system could provide a help section (e.g.
Frequently Asked Questions section). Even with error messages and well
defined options, some might not know “what to do”, therefore a web
page where such specific situations could be clarified (e.g. through a
question).

Reliability

R1. Twenty-four Hours Available - The system won’t be on-line for twenty
four hours within this thesis scope. However it should be if the system
were to be developed aiming for a real world application market.

R2. 99.999% Availability Accuracy - The system won’t be available 99.999%

of the time. However it would be a proper threshold since some compa-
nies would depend on the system. For a better notion it is the same to
state that the system could be down for 8.76 hours per year.

Performance

P1. 10% of users “served” in an instant - The throughput won’t be able to

provide response almost instantaneously to 10% of online users.
However, if this system went to production this threshold would be, in
our humble opinion, a good threshold to begin with.

39
 CHAPTER 3. REQUIREMENTS ANALYSIS

P2. 10 seconds Maximum Response Time - System could have a limit of

maximum response time of ten seconds. Since this maximum “is
about the limit for keeping the user’s attention focused on the dialogue.”[37].

P3. Feedback presentation of Actions with Response Time Between 1 and

10 seconds - System won’t present feedback for long actions, however
the system, would likely, present feedback for operations that take
more than one second and less than ten seconds, since “1.0 second
is about the limit for the user’s flow of thought to stay uninterrupted”
and for response times of “10 seconds (...) should be given feedback
indicating when the computer expects to be done.”.[37]

Supportability
S1. Testable System - The system must be testable. Since we propose some
system requirements, those must be verified by test to check if they
were, or not, achieved, for this purpose a test plan will be presented in
the second semester.

S2. Properly Document every functional requirement - We must have the

functional requircements well documented. In order to have a
good maintainability, the functional requirements must have associated
documentation, like Use Case, Sequence Diagrams and Graphical Mock-
ups of the linked system functions.

S3. Optimize Persistence Storage - We must opt for a data base manage-
ment system that optimizes persistence, through the use of Post-
greSQL (RDFLib-PostgreSQL API) over IO Memory (Python RDFLib
built-in), in order to make the application scalable.

Design
D1. Triplestore required - We must use a triplestore to store data. In
order to store the semantic values, classes, instances and properties of
services and services instances we must use a Triplestore.

Implementation
Im1. Recur to A Web Application Framework - The project should be de-
veloped using a Web Application Framework (WAF) - Django1 .
As explained before WAF’s incorporates one or more frameworks that
support, in this case, a more agile and quick development.
1
Django - https://www.djangoproject.com

40
 3.2. REQUIREMENTS

Im2. Use interfaces - The system must use APIs. Since there are already
developed interfaces, easing the development (e.g. RDFLib), they must
be used.

41
 Architecture
4
This chapter is subdivided in three sections. The first one presents a simple
view of the architecture. The second presents a component diagram and a
corresponding explanation. The final section presents a detailed analysis each
of the components. As Silva and Videira state[51], “The architectural diagrams
describe aspects from implementation phase and installation of a system in
general, a software system in particular.”, therefore we use such diagrams in
order to clarify the architecture of the system.

4.1 First Level Architecture

For a better understanding of the system it is explained how it operates in

an abstract way.

Primarily the system is accessed through a web browser, then the users’
requests are processed and transformed into operations to be taken by the
system, recurring to data (in the DBMS or in the Triplestore) and at last, the
system returns a response with the information requested by the user.

Figure 4.1 presents an Abstract and simplified system’ architecture.

43
 CHAPTER 4. ARCHITECTURE

Figure 4.1: Abstract architecture.

4.2 Second Level Architecture

In this chapter, we assume “component” to be a software artefact.

We make use, through Django Web Framework (view chapter 6), of Model-
view-controller (MVC) design pattern, which “separates data (model), user in-
terface (view), and data-handling logic (controller) so that one can be changed
without affecting the others. The benefits of this pattern are obvious. With
it, designers can work on the interface without worrying about data storage
or management. Developers are able to program the logic of data handling
without getting into the details of presentation. As a result, the MVC pattern
quickly found its way into web languages, and serious web developers started
to embrace it in preference to previous techniques”.[23]
Figure 4.2 Illustrates the Model-view-controller (MVC) pattern.

Figure 4.2: Model-view-controller (MVC) pattern

44
 4.2. SECOND LEVEL ARCHITECTURE

For a better understanding we describe each project component:

• Django Template (MVC Views) - Responsible by the interaction

with the system and visualization of system status and information, re-
curs to views, scripts and forms in order to built the interface that should
be presented to system’ users;

• Django Views (MVC Controllers) - Responsible for data-handling

logic, recurs to Models in order to retrieve needed data;

• Django Models (MVC Models) - Automatically-generated database-

access API (python) responsible for the abstraction of the non-semantic
data storage, recurs to a DBMS;

• Django Forms - “Encapsulates a sequence of form fields and a collection

of validation rules”1 ;

• DBMS - Data Base Management System, responsible for non-semantic

storage;

• Ontologies - Formal specifications of services which are subdivided into:

1. Individuals - Specification of the individuals (services or compa-

nies) in the system;
2. Schema - Specification of the information model and organization;

• Triplestore - Database responsible for storing the semantic information,

organized in triples;

• APIs - External APIs, responsible for semantic querying and semantic

data representation and storage;

• Persistence storage - Responsible for enhancing the efficiency of the se-

mantic querying recurring to more persistence solutions that in-memory
data;

The following component diagram (Figure 4.3) “illustrates the dependen-

cies between several software artifacts”[51].
1
https://docs.djangoproject.com/en/dev/topics/forms/

45
 CHAPTER 4. ARCHITECTURE

Figure 4.3: SPMS Components Diagram

4.3 Third Level Architecture

In this section we presented in detail the most relevant components of the
SPMS.

4.3.1 Templates
The templates are based in some of the use case diagram since each repre-
sents a sequence of actions of one or more actors taken by one or more users
in order to obtain a specific result[51].
In light of the above, Figure 4.4 presents in more detail the templates of the
system. It should be stressed that every template displays the base.html, which
is an html file containing a common layout through all system web pages.

4.3.2 Views
Each template has an associated view. Every searching, filtering or brows-
ing operation recurs to other defined views, hereby defined as “Filtering Agent
Views”.
Figure 4.5 presents in more detail the Views (components) of the system.

4.3.3 Models
In order to store user information we use two Django models: User and
Group. This way we can define a user (company) and its group (Provider or

46
 4.3. THIRD LEVEL ARCHITECTURE

Figure 4.4: SPMS Templates Component Diagram

Figure 4.5: SPMS Views Component Diagram

Consumer). The only model that we needed to define was the Instantiation-
Request, to represent the requests from consumers to customers in order to
instantiate an ITSM Service. All other information regarding services and its
attributes is stored in a triple store, accessible through an API.

47
 CHAPTER 4. ARCHITECTURE

Figure 4.6 presents in more detail the Models of the system.

Figure 4.6: SPMS Views Component Diagram

4.3.4 APIs
In order to filter, browse and/or search services through semantic web tech-
nologies we need to recur to three APIs: RDFLib and RDFLib-PostgreSQL.
RDFLib abstracts the triple store operations, which at a conceptual level
can be considered Model (in the MVC pattern), since it’s used to store and
retrieve information, in the form of triples. However, in order to avoid mis-
understandings we placed it in the API Layer, since it’s accessible through an
interface.
Figure 4.7 presents in more detail the APIs (components) of the system.

Figure 4.7: SPMS APIs Component Diagram

48
 ITIL Interfaces Design
5
One of the main goals of this thesis is the development of a set ITIL in-
terfaces, which will enable the eventual standardization and automatization
of some ITIL conformant IT services. Specifying the interfaces consists in
defining ITIL information objects, representing them through an abstract IT
component template containing business process (BPMN) and Technical In-
terface (WSDL) information. Alongside our SAPO partners we were able to
develop two interfaces for the Incident Management (IM) and Problem Man-
agement (PM) processes. The first is described by one business process and
seven cross-functional flowchart diagrams, the second is described by one busi-
ness process diagram and eight cross-functional flowchart diagrams, present in
Appendix D.

5.1 Interface Design Process

Since ITIL publications already came with the process description for PM
and IM, the process for designing the interfaces can be subdivided into four
major steps:

1. Analyse ITIL Process;

2. Design The Interface:

• Design BPMN Diagram;

• Design Cross Functional Diagram;

3. Team Discussion and Inspection;

• If the discussion leads to improvements in the diagrams an interface

review must be performed.

49
 CHAPTER 5. ITIL INTERFACES DESIGN

4. Enter the Interface information in the SDB Backoffice (c.f.

1.2.2)

If the process or function described in ITIL does not have a defined formal
process, the work described in section 2.1.5.2 should be considered instead of
step one and two.
For a better understanding of the process described, we present it in a
graphical model in Figure 5.1.

Figure 5.1: Process for designing ITIL interfaces

5.1.1 Analyse ITIL Process

In order to work close with ITIL, people must globally understand ITIL
and at least the introductory publication must be read. After knowing what
is ITIL and what it stands for, people should read and analyse the specific
process and the introductory section of the publication they are working on.
The process is considered understood when each activity, connection and
link to other process can be listed and described in an operation centric ap-
proach, instead of an activity centric approach. After reading and understand-
ing the process, identify which other processes the one being analysed interacts
with. It is also advised to list such processes and to keep a description of the
link between them. Auxiliary literature should be consulted in order to have
a better notion of what constitutes some artefacts of the process, e.g. under-
standing in what consists an Incident is extremely important for the IM pro-
cess. Besides ITIL publications, the IT Process Maps 1 is a valuable resource,
since it provides a lot of adequate information regarding ITIL processes and
stands as one more source of information for incident and problem records
attributes.
Figure 5.2 shows the process for analysing ITIL processes.
1
http://en.it-processmaps.com

50
 5.1. INTERFACE DESIGN PROCESS

Figure 5.2: Process describing the ITIL Process analysis

5.1.2 Interface Design

5.1.2.1 Process Modeling via BPMN Diagram

In order to formally represent an ITIL process we use a BPMN representa-

tion (standard notation), that, even if ITIL already provides a process diagram,
is more specific than the process diagram provided in the ITIL publications,
e.g. in the IM process the activity Resolution and recovery is subdivided into
two activities in our BPMN representation, Identify Resolution and Perform
Recovery Actions, since the process description explicitly indicates that these
two activities should take place.

Figure 5.3 shows part of the IM process (the full process diagram is illus-
trated in Appendix D).

Figure 5.3: Part of the process describing the ITIL IM Process

51
 CHAPTER 5. ITIL INTERFACES DESIGN

5.1.2.2 Cross Functional Design

It is important to look at the activities present in the BPMN and think

in which way can we subdivide them into logic interface operations, and how
they are organized and ordered “inside” each activity.
In order to derive operations inputs and outputs from the BPMN elements,
is important to take note of any artefact that can be represented as a vari-
able. Both IM and PM processes have a section in each process that list and
covers almost every attribute for the main record types (Incident and Problem
records). However some other data types might arise, for instance Catego-
ryRecord which represents the category of a problem during it’s lifecycle.
As advised by SAPO partners, when the analysis of the data types and
the operations is done, cross functional diagrams should be developed. These
diagrams link activities (or sub-activities) to interface operations, its inputs
and outputs, providing a global view of the relations between the elements
that constitute an interface.
Figure 5.4 shows part of one of the cross functional diagrams for IM (the
full cross functional diagrams are illustrated in Appendix D).

5.1.3 Team Discussion, Inspection and Revision

Every time a newer version of a BPMN diagram or a cross functional

flowchart diagram was developed, meetings with the SAPO partners took
place, following an iterative method. In these meetings, flaws and sugges-
tions were pointed out by the team, in order to gain knowledge of the pro-
cesses, interfaces and the way they should be represented. When necessary,
new meetings were scheduled so that the amendments were performed and a
new revision and inspection could be performed.
When a process and its interface reached a satisfactory state the devel-
opment of a new one, from a set of processes previously defined by SAPO
(Figure 3.2), was considered and discussed in order to decide what process
should be analysed and why. For instance, when the Incident Management in-
terface was finished, Change Management, Request or Problem Management
could all be analysed afterwards, since they all share links with IM process,
however business aspects and process implementation priorities were analysed
and we conclude that the best option was to develop Problem Management.

52
 5.1. INTERFACE DESIGN PROCESS

Figure 5.4: Part of the cross functional diagram describing the ITIL IM Process

5.1.4 Enter the Interface information in the SDB Back-

office
In order for the developed interfaces to eventually become, functional ser-
vices, they were entered in SBD Backoffice which allows these designed services
to generate, services Stub2 code.
Another suitable feature of SDB Backoffice is the one that allows users to
export interfaces to WSDL. It was used by us to export ITIL IM and PM
interfaces to WSDL, in order to import it in the SPMS application, so that
proper tests to the interface import requirement could be performed.

2
Module responsible for the interpretation of arguments and results of Remote Procedure
Call Protocol calls[2]

53
 Development
6
This Chapter is subdivided into two sections. The First describes the
development of the ontology used in SPMS to represent information concerning
ITSM Services.The Second describes, in detail, the development of the SPMS
Web Application.

6.1 Ontology Development

Before getting into any ontological details it is important to point out the
reason that drove us to resort to semantic web principles and technology in
this project.
Semantic web principles foster interoperability in a way that relational
databases do not, since “Ontologies give a concise, uniform, and declarative
description of semantic information, independent of the underlying syntac-
tic representation or conceptual models of information bases”[28]. Relational
databases, on the other hand, need “to be searched, integrated and processed
without prior negotiation”[54] in order to represent the same degree of infor-
mation as an ontology defined in a triple store.
When using relational databases, “the semantics of data is not explicitly
defined in the relational schema. Knowledge of a specific domain is user-
oriented and ad hoc. Necessary assumptions on the original design model of
the database and its related sources must be made”[54].
Ontologies allow us to define basic service related concepts, assert proper-
ties of such concepts and represent relationships among concepts in a reusable
way, so that “detailed, accurate, consistent, sound, and meaningful distinctions
can be made among the classes, properties, and relations”[20].
In order to develop SPMS, we had to create, or reuse, ontologies in order
to represent ITSM services information.

55
 CHAPTER 6. DEVELOPMENT

Since we were already working with ITIL practices, we selected the services
attributes present in the ITIL R Service Design publication [39] to informa-

tively represent an ITSM service.

Therefore, this ontology, which represents ITSM services, its running in-
stances, and its attributes was denominated ITSM Service
(http://genssiz.org/inteligent/itsmservice#) and consists of the following classes:

• Contract - ITIL clearly indicates that the service specification should in-
clude information regarding contracts, which is not specified in itsmo on-
tology (see section 6.1.2), despite possessing a specification of an itsmo:Agreement;

• Input - Represents the information of the input fields of an operation;

• ITSMService - Represents an ITSM service (abstract ITSM service) as

described in the previous chapters;

• ITSMServiceInterface - Interface of an ITSM service, containing ser-

vice inteface information (gathered from the WSDL specification);

• Metric - Represents a service metric, ITIL clearly specifies that metrics

should be present in the service information;

• Operation - Operation of an interface of an ITSM service, holds infor-

mation regarding its signature, decription, inputs and outputs;

• Output - One of the attributes of an interface is the information re-

garding the output, therefore it should be created a class that groups
together the output information;

• RunningITSMService - ITSM Service at an operational state, the

ITSM service is “up and running”, sub class of ITSM service;

• SLR - Service Level Requirement, another attribute that ITIL states

that should be present in an service description.

6.1.1 Ontological Specification Level

The created Ontology , recurs to OWL Lite and OWL-DL1 sublanguages.
For instance, we use OWL Lite FunctionalProperty construct, which allows us
to define that “For a given individual, there can be at most one individual that
is related to the individual via the property.”[22]. We make use of OWL-DL
disjointWith construct for specifying that an individual of one class cannot,
1
http://www.w3.org/TR/2004/REC-owl-features-20040210/#s1.3

56
 6.1. ONTOLOGY DEVELOPMENT

simultaneously, be a member of another class, for instance an individual of

inteligent:Output class, cannot be an inteligent:ITSMService.
Figure 6.1 shows a practical example, in our ontology, of a functional prop-
erty, the property hasProcess, an ITSM Service can only have one process.

Figure 6.1: Practical example of OWL Lite FunctionalProperty construct.

Figure 6.2 shows the practical example of the OWL-DL disjointWith con-
struct, given before.

Figure 6.2: Practical example of OWL DL disjointWith construct.

6.1.2 Reused Ontologies

Links to other ontologies were created for two main reasons:

1. Some ontologies allow us to follow a plug-and-process approach, since

they can bundle information regarding services, that can be imported
and/or exported between systems enhancing information reusability;

2. Some of the concepts we need to specify were already defined in other

ontologies;

The reused ontologies were:

1. itsmo (http://ontology.it/itsmo/v1#) - “IT Service Management Ontol-

ogy (ITSMO) is a powerful vocabulary for describing all of the detail of
IT Services” and “is for everyone that wants to describe or publish an

57
CHAPTER 6. DEVELOPMENT

IT Service Catalog according with ITIL best practices, ISO 20000 stan-
dards and LinkedData W3C principles.”2 . This is exactly what we need
to describe ITIL service attributes in our application;

2. usdl-core (http://www.linked-usdl.org/ns/usdl-core#) - The Linked USDL

Core “covers the main concepts and relationships characterising services,
leaving more specific aspects regarding some particular dimensions such
as technical interfaces, licensing or security aside”3 wich is exactly we
need, since we define service, or component, interfaces and the entities
providing, customizing and consuming those services. For instance, we
use the class ”Service” as basis for our definition of ”ITSMService”4 ;

3. bpmn(http://genssiz.org/inteligent/bpmn 20#) - Since the ITSM ser-

vices should have a bpmn schema associated with the process, we felt in
the need of reusing a BPMN ontology. However the BPMN ontology5 ,
that we had access to, was not the most appropriate to map with the
concepts we have considered in our developed interfaces, since it was an
ontology based on BPMN 1.1, and the processes were modelled in BOMN
2.0. Therefore we developed an BPMN ontology (This ontology is more
in detail in Appendix E);

4. requirement ontology - Since we had the need of defining the Service

Level Requirement (SLR) of a TITSM service we needed an ontology that
specifies the concept of “Requirement” in its vocabulary. The “Require-
ment Ontology (RO) aims to support an unambiguous, context-aware
representation of norms, criteria, requirements and other normative en-
tities”6 , therefore was the chosen ontology to define SLR (Service Level
Requirement);

5. usdl-price7 - Since we are importing data from service’s processes (from

BPMN specification), and these are composed of elements (activities,
gateways, etc.), the price of the service should be extrapolated from the
element prices. Taking this into account we find that each service should
constitute a service offering that had price components (price of each
element), which is exactly what this ontology allows us to describe;

6. usdl-sla8 - Since Linked-USDL already has an extension to describe

2
http://ontology.it/itsmo/home/
3
https://github.com/linked-usdl/usdl-core/wiki/Linked-USDL-Core-Vocabulary
4
http://rdf.genssiz.dei.uc.pt/usdlcore
5
https://dkm.fbk.eu/index.php/BPMN_Ontology
6
https://code.google.com/p/requirement-ontology/
7
http://www.linked-usdl.org/ns/usdl-price#
8
http://www.linked-usdl.org/ns/usdl-sla#

58
 6.1. ONTOLOGY DEVELOPMENT

service level agreements, we reused it in order to describe the sla’s of

ITSM Services;
There were other ontologies reused in our application (e.g. skos9 , gr10 ),
however they were reused because they were linked with ’primary’ ontologies
like Linked-USDL (core, sla and price).
In order to provide a better understanding of the ontology and how things
are connected we present below the ontological graph in Figure 6.3 and Fig-
ure 6.4.

Figure 6.3: Part one of ITSM Service Ontology graph

6.1.3 Relevant Choices

We opt to represent the instances of ITSM Services in a generic class,
RunningITSMService, instead of having a set of possible subclasses of ITSM-
Service that would have as individuals ITSM running services (ITSM services
9
http://www.w3.org/TR/2008/WD-skos-reference-20080829/skos.html
10
http://www.heppnetz.de/projects/goodrelations/

59
 CHAPTER 6. DEVELOPMENT

Figure 6.4: Part two of ITSM Service Ontology graph

instances). For example we could define a new ITSM service, say ”ITILChange-
Management” as a subclass of ITSMService, or we could have a class of
”ITILService”, a subclass of ITSMService, which could have another subclass
named ”ITILChangeManagement”, which in turn would have its individuals.
However this would implicate a schema change every time a new ITSM Service
or ITSM Service Type were to be added to the system.

Temporal Efficiency By not defining a new class for each instance of ITSM-
Service, when we want to filter services we only have to infer on data type
properties, instead of inferring on object type properties, since we only have
to access, for instance, to the guidelines that the service follows (e.g. ITIL,
ISO/IEC 20000, etc.), which leads us to temporal cost efficiency.

Spacial Efficiency Another advantage that this definition of ITSM Services

instances brings, is that by linking the classes ITSMService and RunningITSM-
Service by two inverse properties, hasInstance and isInstanceOf we only need
to recur to these two relations in order to filter the instances (running services)

60
 6.2. SPMS DEVELOPMENT

relative to a specific ITSM Service. By doing so we avoid inference over rela-

tions linking classes to its subclasses (rdfs:subClassOf ) and relations between
classes and its individuals (rdf:type). This way of spacial efficiency leads us to
time reduction when implementing and running queries.

6.2 SPMS Development

This section describes the development of the Service Portfolio Manage-
ment System application, one of the main goals of this thesis.

6.2.1 Framework Selection

In order to choose the programming related technology for the development
of this project we based ourselves in the following factors:

1. “programmer productivity, maintainability, efficiency, portability, tool

support, and software and hardware interfaces”[48];

2. RDF support;

Appendix A describes a more comprehensive analysis and comparison be-

tween the considered frameworks.

6.2.2 Technological Architecture Overview

The following diagram “illustrates the configuration of the processing and
software components, processes and objects supported within such processes”[51].
The system, as explained before will be developed using a Web Framework,
more specifically Django. Clients, through a web browser, can access the
application, through the HTTP Protocol. The Django application runs an
Apache Web Server11 and uses WSGI12 , Django ORM (a Django interface) and
specific application code. Within the source code, as explained before we need
to call functions from RFDFLib and RDFLib-PostgreSQL APIs to perform
querying actions on ITSM services or ITSM service instances information.
Figure 6.5 presents the architecture Installation Diagram.
Django relies in the MVC design pattern, already explained in section 4.2.
Next we explain and present examples of each component of Django MVC,
specific this project.
11
http://httpd.apache.org
12
https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/

61
 CHAPTER 6. DEVELOPMENT

Figure 6.5: SPMS Installation Diagram

6.2.2.1 Django Models (MVC Models)

As previously tackled, we only use Django built-in models to manage and

store data regarding companies and their type.
The User and Group models (bundled in Django) allow us to define com-
panies that are either ITSM Service providers or consumers. We make use of
username, password, email and groups attributes, already defined in the User
model, to store information about a company and we use the name attribute
of Group model to define which type of company we are creating.
The only model that we felt the need to create was a model to store data
regarding the purchase request of an ITSM Service. The code below shows the
InstantiationRequest model, created to represent a purchase request.

Listing 1 Example of Django Models definition.

from django.db import models
from django.contrib.auth.models import User, Group

class InstantiationRequest(models.Model):
provider_company = models.CharField(max_length=30)
consumer_company = models.CharField(max_length=30)
service_name = models.CharField(max_length=30)
accepted = models.BooleanField(default=False)

6.2.2.2 Django Views (MVC Controllers)

The views, used for data-handling logic, consist of python functions in

which data passed through REST (GET or POST) requests from the templates
is handled in order to respond to user request.
For instance, the code below shows the view catalogue view, created to
display a list of buyers of the ITSM Services of a provider company.

62
 6.2. SPMS DEVELOPMENT

Listing 2 View for listing all buyers of ITSM Services from a providing com-
pany.
@login_required
def view_catalogue(request):
user = request.user
group = Group.objects.get(name=’ProviderCompany’)
users = User.objects.filter(groups = group)
if user in users:

requests = InstantiationRequest.objects.filter(
provider_company = request.user.username,
)

consumers = []
for r in requests:
if r.consumer_company not in consumers:
consumers.append(r.consumer_company)

variables = RequestContext(request, {
’consumers’ : consumers
})

return render_to_response(
’viewCatalogue.html’,
variables
)
raise Http404

In this view we primarily check if the user requesting this functionality is

a provider company. If it is in fact a provider company then the system will
gather a list of all the companies that have requested services for purchase
and will return it to the viewCatalogue.html template. If is not a providing
company making the request, the system will deny the request and display a
404 error code page.

6.2.2.3 Django Templates (MVC Views)

The templates are html files (user interface) that allow the user to interact
with the system through a web browser.

63
 CHAPTER 6. DEVELOPMENT

Listing 3 Template for Editing the attributes of a Running ITSM Service.

{% extends "base.html" %}
{% block title %}Edit Service{% endblock %}
{% block head %}Fill the Service Information{% endblock %}
{% block extrahead %}
<script src="{{STATIC_URL}}js/fill_instance_info.js"></script>
{% endblock extrahead %}
{% block content %}
<div class="form">
<form method="post" action=".">
{% csrf_token %}
<div>
<select multiple="multiple" class="input-xxlarge" name="abstract_services">
{% for choice in choices%}
<option>{{choice}}</option>
{% endfor %}
</select>
</div>
<div class="fill-form">
</div>
</form>
</div>
{% endblock %}

The template lists all the services returned from its respective view in a
select within a html form.
Figure 6.6 shows the template interpreted in a web browser.

Figure 6.6: Screenshot of the interpreted fillITSMServices.html template

Bootstrap In order to save development time, ease development efforts and

still have a pretty good and fluid layout design of the web interface we used

64
 6.2. SPMS DEVELOPMENT

bootstrap13 2.3.2. This way organizing html elements and develop an applica-
tion with a good browsing experience was fast and clean.
Bootstrap is an open source front-end toolkit, providing HTML, CSS, and
JavaScript-based design templates, a variety of UI components and interactions
for building websites14 . Bootstrap has vast set of features, including:

1. Grid system; 4. Vast set of bundled icons;

2. Responsive design;
3. Default buttons, labels and 5. JavaScript-based design tem-
badges styles; plates;

JQuery Even though Django does not provide a JavaScript library to sim-
plify working with AJAX, choosing one and integrating it with Django is a
straightforward matter”[23].
JQuery is a lightweight, JavaScript library, takes a lot of common tasks
that require many lines of JavaScript code to accomplish, and wraps them
into methods that you can call with a single line of code. It also simplifies
a lot of the complicated things from JavaScript, like AJAX calls and DOM
manipulation15 . More specifically, “The jQuery library has a full suite of AJAX
capabilities. The functions and methods therein allow us to load data from
the server without a browser page refresh”16 .
We selected JQuery JavaScript library, since “JQuery provides three ad-
vantages over existing code browsing techniques. First, because JQuery can
inherently support multiple types of browsing, complicated searching tasks can
be performed all within the same tool, decreasing the disorientation associated
with switching tools to complete a single task. Second, because there is a rich
logic programming language that forms the basis of all queries, a wide vari-
ety of searches can be performed using only JQuery. Lastly, it is extensible.
Users can edit a configuration file to add their own queries to the JQuery
menus.”[36].
For instance, we used JQuery to help display the html form for editing an
ITSM Running service without a page refresh, displaying the current values of
the service attributes in the html form fields.
The following code shows how this was done.

13
http://getbootstrap.com/2.3.2/
14
http://www.cubrid.org/blog/dev-platform/overview-of-bootstrap-from-twitter/
15
http://www.w3schools.com/jquery/jquery\_intro.asp
16
http://api.jquery.com/category/ajax/

65
 CHAPTER 6. DEVELOPMENT

Listing 4 Script to get the form for editing a service through an AJAX request.
jQuery(document).ready(function() {
jQuery("select").change(function () {
var str = ’’;
var selected = jQuery("select option:selected:first");
str += selected.text();
var substr = str.split(’: ’);
var company = substr[0];
var abstract_service = substr[1];
abstract_service = abstract_service.replace(new RegExp(" ", "g"), "_");
var html_code = ’’;
jQuery.get("/getFillForm/"+company+"/"+abstract_service+"/",
function(html_form) {
html_code = html_form;
jQuery(".fill-form").html(html_code);
});
});
})

When a service is selected in the template (see Figure 6.6) the application
displays a form with the service attributes filled.
Figure 6.7 Shows the template after a service has been selected .

Figure 6.7: Screenshot of the editInstance.html template after an AJAX re-

quest

66
 6.2. SPMS DEVELOPMENT

6.2.3 Semantic Web Tools

As mentioned in 2.1.6, we resorted to semantic web and Linked Data prin-
ciples. Semantic web can help achieving integration, helping reducing the
number of services “living” in silos, e.g. services modelled in Linked-USDL[4].
Therefore, since we use Semantic Web based notations and specifications,
more specifically Linked-USDL (RDF), we need some way to store data ac-
cording to the way it is represented by such specification.
A “triple store is designed to store and retrieve identities that are con-
structed from triplex collections of strings (sequences of characters). These
triplex collections represent a subject-predicate-object relationship that more
or less corresponds to the definition put forth by the RDF standard.”[45]
Therefore we may have to recur to triple stores or to a triple store abstract
interface.
It should be noticed that despite the fact that Web Application Frameworks
provide database support, most do not provide, by default, interfaces for Triple
Stores management. The same happens with Django, therefore solutions to
address this issue were analysed.
Yergler[53] considers three solutions in his work:

• RDFLib; • pyrple; • Sparta.

However,W3C17 , points four libraries that are independent from other RDF
Libraries:

• RDFLib; • pyrple; • 4Suite • pySesame.

4RDF;

From the previous list, RDFLib is the “Largest, most diverse RDF handling
library”[53]. It is also the most documented and the most popular which means
that has been greatly tested. Consequently is the one chosen by us.

6.2.3.1 RDFLib
RDFLib allows us to add, update and delete triples18 to a triple store and
read data through SPARQL queries19 .
The following example shows how a triple is added to the store, in this case
through the set command, that replaces (or creates) the value of a publisher,
if the service could have two publishers we could add another with the add
command.
17
http://www.w3.org/wiki/SemanticWebTools#Python_Developers
18
https://rdflib.readthedocs.org/en/latest/using\_graphs.html
19
https://rdflib.readthedocs.org/en/latest/intro\_to\_sparql.html

67
 CHAPTER 6. DEVELOPMENT

Listing 5 Add or replace the publisher of a certain service in the Triple Store.
provider = user.username
service = itsm_service_name
uri_str = (provider+"__"+service).replace(" ", "_")
#ITSMService URI
itsm_service = URIRef(ontologies[’inteligentpop’][uri_str])
#The service has a publisher - the company who publishes it.
graph.set(
(itsm_service,
URIRef(ontologies[’inteligent’][’hasPublisher’]),
Literal(user.username))
)

For retrieving information we use the implementation of SPARQL 1.1

Query and SPARQL 1.1 Update languages, developed by the RDFLib.
The following example shows how we retrieve information from an ITSM
Service.

Listing 6 SPARQL query for retrieving information regarding an ITSM Ser-

vice.
SELECT ?a_name ?a_component_type ?a_itsm_class ?a_publisher ?a_descriprion WHERE {
?abstract_service rdf:type inteligent:ITSMService.
?abstract_service inteligent:hasName ?a_name.
?abstract_service inteligent:hasPublisher ?a_publisher.
?abstract_service inteligent:hasITSMClass ?a_itsm_class.
?abstract_service inteligent:hasComponentType ?a_component_type.
?abstract_service inteligent:hasDescription ?a_descriprion.
}

6.2.3.2 RDFLib-PostgreSQL

Instead of having all tripples in I/O memory we opt to configure a persis-

tence solution by using an API (RDFLib-PostgreSQL) that stored the triple
store in a DBMS, in this case a postgresql DBMS 20 .
This way all changes in the triple store is handled abstractly by this API,
without any changes, to the developer in terms of adding, updating, deleting
or reading from the graph store (triple store).
The following code shows how we configured the RDFLib API to use a
PostgreSQL DBMS through the RDFLib-PostgreSQL API.

20
http://www.postgresql.org

68
 6.2. SPMS DEVELOPMENT

Listing 7 Configuration of PostgreSQL DBMS.

from rdflib import plugin, store, Graph, URIRef
from ontologies import ontologies

plugin.register(
’PostgreSQL’, store.Store,
’rdflib_postgresql.PostgreSQL’, ’PostgreSQL’)
configString = "user=django dbname=Inteligent password=django host=localhost"
default_graph_uri = "http://genssiz.org/inteligent/"
pgstore = plugin.get(’PostgreSQL’, store.Store)(identifier="rdflibtest")
graph = Graph(store=pgstore,
identifier=URIRef(default_graph_uri))
rt = graph.open(configString, create=False)
if rt == store.NO_STORE:
graph.open(configString, create=True)
else:
assert rt == store.VALID_STORE, "The underlying store is corrupt"

6.2.3.3 Developed APIs

pybpmn In order to handle the parsing and retrieval of information present

in the bpmn files, where the service processes are described, we developed an
API named pybpmn. This API consists in a parser that retrieves information
of the Elements (Pools, Activities, Events, etc.) of a BPMN2.0 (serialized in
XML).
The ElementTree21 Python API was used to ease the XML parsing.

pywsdl In order to handle the parsing and retrieval of information present

in the wsdl files, where the technical operations of an ITSM service are de-
scribed, we developed an API named pywsdl. This API consists in a parser
that retrieves information of the operations, its signature, description, inputs
and outputs. The ElementTree Python API was also used to ease the XML
parsing.

6.2.3.4 Important Features

In order to interact with other applications, we define import and export

functionalities, e.g. we can import BPMN and WSDL files and export some
service attributes to Linked-USDL. This way this application promotes systems
interoperability instead of being a silo.

Import BPMN The SPMS can import process models, defined in other
applications, and through pybpmn extract relevant information of an ITSM
21
http://docs.python.org/2/library/xml.etree.elementtree.html

69
 CHAPTER 6. DEVELOPMENT

Service. Figure 6.8 Shows the BPMN information, regarding elements, after it
has been imported.

Figure 6.8: Screenshot of the template after the BPMN import

Import WSDL The SPMS can import interface information, defined in

other applications, and through pywsdl extract relevant information of an
ITSM Service. Figure 6.9 Shows the WSDL information, regarding elements,
after it has been imported.

Export Linked-USDL The SPMS also allows people to export services to

a platform-neutral language for describing services (Linked-USDL). As pre-
viously explained in 6.1, we recurred to the Linked-USDL Core, Pricing and
SLA vocabularies to define a service.
The code below shows a bit of the Linked-USDL (xml) code of an ITSM
service when exported.

70
 6.2. SPMS DEVELOPMENT

Figure 6.9: Screenshot of the template after the WSDL import

71
 7
Tests

7.1 Test Plan

In order to verify that the system performs the way it should, it is neces-
sary to test its features. Therefore, having in mind the previously identified
requirements, we present a test plan.

7.1.1 SAPO requirements Validation

The Incident Management and Problem Management interfaces, BPMN
and cross-functional flowchart diagrams, were validated by SAPO Partners,
iteratively, during all held meetings.

7.1.2 Functional Requirements Testing

For each defined functional requirement, we identified a set of tests to be
taken to verify the system’s validity. Since requirements F14, F15, F16 and
F17 are used by other requirements we do not present specific tests for such.
Ideally, we would present a test case for each requirement, however, due to
time restrictions, we present only three examples of test cases (requirements
F5, F10 and F11).
In light of the above, we list the tests considered by us:

TF1. Tests for functional requirement “Register Company”:

• Verify if the system displays error messages when the registration

fields are blank.
• Verify if the company has been successfully registered.
• Verify if the registered company has the correct type.

73
 CHAPTER 7. TESTS

TF2. Tests for functional requirement “Log Company In”:

• Check if the company can be authenticated with the right creden-

tials.
• Verify if the system denies access to a company logging with wrong
credentials, and displays the correspondent error message.
• Check if the system informs companies to register themselves, when
they try to authenticate without performing registration.
• Check if the system allows authentication with the blank fields and
with invalid data types.

TF3. Tests for functional requirement “Add ITSM Service Instance”:

• Test submission with blank fields (most combinations).

• Test if system issues warnings when filling fields with wrong data
types.
• Test if system correctly registers the new instance.
• Check if the system is able to successfully cancel the operation.

TF4. Tests for functional requirement “Allow ITSM Service Instantiation”:

• Check if the company that requested the instantiation appears in

the request list.
• Verify if the system allows the correct company to instantiate the
right service.

TF5. Tests for functional requirement “Add ITSM Service”:

• Check if the system correctly adds an ITSM Service.

• Verify if the system denies the addition of a service with the same
name with another already in it.
• Verify if the system issues a warning when trying to submit wrong
data types in the input fields.
• Validate if the system correctly adds the service to the database.
• Check if the system successfully cancels the operation, if requested.

Figure 7.1 presents in more detail the developed test case for this re-
quirement.

TF6. Tests for functional requirement “Import Workflow”:

74
 7.1. TEST PLAN

Figure 7.1: Functional requirement 5 test case

• Check if system correctly saves the reference for the workflow file.

TF7. Tests for functional requirement “Import Interfaces”:

• Check if the system correctly saves the reference for the interfaces
file.

TF8. Tests for functional requirement “Edit ITSM Service”:

• Check if the system correctly changes an ITSM Service.

• Check if the submitted files are stored correctly.
• Check if the system issues informative and error messages when
submitting changes.
• Validate if the system correctly changes the service in the database.
• Check if the system successfully cancels the operation, if requested.

75
 CHAPTER 7. TESTS

TF9. Tests for functional requirement “Edit ITSM Service Instance Proper-
ties”:

• Test submission with blank fields (most combinations).

• Test if system issues warnings when filling fields with wrong data
types.
• Test if the system correctly changes the targeted instance.
• Check if the system is able to successfully cancel the operation.

TF10. Tests for functional requirement “Search Service”:

• Check if the system warns the user when performing a blank search.
• Check if the system warns the user when the search returns an
empty search.
• Test most combinations of values.
• Check if results are correct for tested combinations of values.

Figure 7.2 presents in more detail the developed test case for this re-
quirement.

TF11. Tests for functional requirement “Browse Service”:

• Check if results are correct for each type of component.

Figure 7.3 presents in more detail the developed test case for this re-
quirement.

TF12. Tests for functional requirement “View Own Portfolio”:

• Check if attributes correspond to the presented service.

• Test the export functionality, in order to verify that the exported
file correctly describes the specific service.

TF13. Tests for functional requirement “View Consumer Company Cata-

logue”:

• Check if the listed services are indeed related to that consumer

company.
• Check if attributes correspond to the presented service.
• Check if the system only lists services that already have been in-
stantiated and edited.

76
 7.1. TEST PLAN

Figure 7.2: Functional requirement 10 test case

TF17. Tests for functional requirement “Export Service Instance”:

• Verify if the correct information is saved in the exported file.

TF18. Tests for functional requirement “Search ITSM Service Instance”:

• Check if the system warns the user when performing a blank search.
• Check if the system warns the user when the search returns an
empty search.
• Test most combinations of values.
• Check if results are correct for tested combinations of values.

TF19. Tests for functional requirement “Log Company Out”:

• Verify if the company has successfully logged out.

TF20. Tests for functional requirement “Display System Status”:

77
 CHAPTER 7. TESTS

Figure 7.3: Functional requirement 11 test case

• Verify if the system display information regarding the status of every

service related to that company.

TF21. Tests for functional requirement “Relate Interface operations With

Process Activities”:

• Verify if the system correctly stores informations about the relations

between process activities and interface operations of a service.

TF22. Tests for functional requirement “Provide Process Templates”:

• Verify if the system correctly maps and displays the activities to

the template selected.
• Verify if the system correctly stores the activities of such template.

TF23. Tests for functional requirement “Assign Prices to Process Elements”:

• Verify if the system correctly stores the price of each element.

78
 7.1. TEST PLAN

7.1.3 Non-Functional Requirements Testing

The tests for the non-functional requirements were extrapolated from the
metrics and descriptions presented in the previous chapter.
We only considered tests for requirements with “must”, “should” and “could”
priorities.

TU1. Tests for usability requirement “Indicate System Status”:

• Verify in every web page if the system informs users of what is

happening in due time.

TU2&3. Tests for usability requirement “Minimize Disambiguation” and “Fol-

low real-world conventions”:

• Ask people for their understanding of sentences present in the sys-

tem and compare it with the desired system meaning.

TU4. Tests for usability requirement “Allow Undo in web forms”:

• Check if all forms representing change in system status have a “can-

cel” button.

TU5. Tests for usability requirement “Same terms for identical operations”:

• Verify if similar actions are described by the system (e.g. buttons,

links, etc.) in the same way.

TU6. Tests for usability requirement “Present and Highlight errors”:

• When something goes wrong, verify if the system issues an high-

lighted error message.

TU7. Tests for usability requirement “Limit Options”:

• Check fields and verify if those that are restricted to some values
only display those same values.

TU8. Tests for usability requirement “Describe Input Fields”:

• Verify if every input field has a small description.

TU9. Tests for usability requirement “Provide Accelerators”:

• Check if the most important operations are easily and quickly reached.

TU10. Tests for usability requirement “Describe errors and fixes in plain lan-
guage”:

79
 CHAPTER 7. TESTS

• Check with people if they correctly understand the semantic mean-

ing of the error messages.

TU11. Tests for usability requirement “Provide Help Section”:

• Test the meaning of tips present in the help section, by inquiring

people.

TP2 Tests for performance requirement “10 seconds Maximum Response Time”:

• Check for every operation if the system’s response time is below 10

seconds.

7.2 Test Evaluation

The tests described above were performed by the developer, through unit
testing, in order to know if the functionalities of the SPMS are fit to use. The
results are present in Figure 7.4.
It should be noted that from the requirements presented in 3, the Must
requirements were one hundred percent fulfilled and around fifty-eight percent
(seven out of twelve) of the Should requirements were also fulfilled, unfortu-
nately none of the Could requirements were fulfilled. There is little impact
for not implementing some Should and Could, since the Must requirements
represent the core functions of SPMS.

80
 7.2. TEST EVALUATION

Figure 7.4: Test Results Overview.

81
 Conclusions
8
The main goals of this thesis, described in detail in section 1.4, were to de-
velop a set of ITIL conformant interfaces and a Service Portfolio Management
web application. This chapter is divided in two sections, the first one describes
what can be done, in the future, to improve what was built, the second one
presents a critical analysis to the undertaken work.

8.1 Future Work

In terms of ITIL interfaces development the work does not end here, since
we will, alongside with SAPO, work on other ITIL processes in order to design
its interfaces. In order to have managed, accurate and quality services[17], gen-
erated through these interfaces, the bridge with COBIT 1 should be considered,
analysed and performed.
In terms of the SPMS the missing requirements (should, could and won’t),
should be developed in order to make SPMS a more suitable and enjoyable
application. Another interesting features for SPMS, would be:

• Service specifications import functionality;

• Allow consumer companies to exchange Running Services Metadata be-

tween them;

• Enhance the searching functionality;

• Add RDFa2 to HTML;

1
http://www.isaca.org/COBIT/Pages/default.aspx
2
http://www.w3.org/TR/xhtml-rdfa-primer/

83
 CHAPTER 8. CONCLUSIONS

8.2 Critical Analysis

During the course of the thesis the initial chosen interfaces by SAPO
changed, and a reprioritization took place. Initially we agreed to the de-
velopment of three interfaces, Event Management, Incident Management and
Problem Management, as pointed in Appendix F. We still developed a prelim-
inary version of Event Management prior to the interfaces revisions, however
corporate world is very dynamic and business does not stop, therefore before
we and SAPO had a chance and time to meet for revisions, Event Management
was already being developed by SAPO.
For us, as well as SAPO, ITIL specific technical interfaces development
was an exploratory and innovative work. On top of that each and every ITIL
process is different, both in size as in content, which makes hard for us to
estimate the amount of time needed to perform the design of an interface based
on others. Given that, the amount of time that we considered for the design
of three interfaces was, in practical terms, spent designing two of them, and
took longer that expected which lead to a delay in the beginning of the SPMS
development. The related time delay risks strategies were put in practice and
a reschedule of the work was performed. It is important to state that all these
plan changes were discussed with SAPO partners.
The challenge of developing such work, as well as the inherent organiza-
tional knowledge gain was rewarding, since technical and personal skills were
acquired at a whole new level.
In the end, we were able to build and model the interfaces, agreed with
SAPO.
In relation to the SPMS development, we were able to develop all the high
priority requirements (must), we developed a fair share of the ones with second
higher priority (should ) and none of the ones with third higher priority (could ).
However we consider the outcome to be very satisfactory, since the project was
big and ambitious.
A lot of technical knowledge, specific to the tools and technologies used,
was gained during the challenge of building SPMS.

84
 Bibliography

[1] S. W. Ambler. The agile unified process (aup), 2012.

[2] A. D. Birrell and B. J. Nelson. Implementing remote procedure calls.

ACM Transactions on Computer Systems, 2(1):39–59, February 1984.

[3] J. Cardoso, A. Barros, N. May, and U. Kylau. Towards a unified service

description language for the internet of services: Requirements and first
developments. In Services Computing (SCC), 2010 IEEE International
Conference on, pages 602 –609, july 2010.

[4] J. Cardoso, C. Pedrinaci, T. Leidig, P. Rupino, and P. D. Leenheer. Open

semantic service networks. In International Symposium on Services Sci-
ence 2012 (ISSS 2012), 2012. This symposium was part of the Multi
Conference SABRE (Software, Agents and Services for Business, Research
and E-Sciences, Leipzig, 23rd-25th September 2012) Published in: Kyrill
Meyer, Nizar Abdelkafi (Eds.) Smart Services and Service Science: Pro-
ceedings of the 4th International Symposium on Services Science Leipzig
(Germany), September 25, 2012 (ISBN 978-3-941608-23-8).

[5] R. Chinnici, J. Moreau, A. Ryman, and S. Weerawarana. Web services

description language (wsdl) version 2.0 part 1: Core language. W3C
Recommendation, 26, 2007.

[6] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web

services description language (wsdl) 1.1, March 2001.

[7] O. Commerce. The Official Introduction to the ITIL Service Lifecycle.

ITIL Series. Stationery Office, 2007.

[8] B. Councill and G. T. Heineman. Component-based software engineering.

chapter Definition of a software component and its elements, pages 5–19.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001.

[9] A. Cruz, P. Ramalheira, and E. Troup. Service delivery broker. page 40.
v1.1 edition, January 2012.

[10] J. De Bruijn, C. Bussler, J. Domingue, D. Fensel, M. Hepp, M. Kifer,

B. König-Ries, J. Kopecky, R. Lara, E. Oren, et al. Web service modeling
ontology (wsmo). Interface, 5:1, 2006.

85
 BIBLIOGRAPHY

[11] D. de Champeaux, D. Lea, and P. Faure. Object-Oriented System Devel-

opment. 1993.

[12] S. Decker, S. Melnik, F. van Harmelen, D. Fensel, M. Klein, J. Broekstra,

M. Erdmann, and I. Horrocks. The semantic web: the roles of xml and
rdf. Internet Computing, IEEE, 4(5):63 –73, sep/oct 2000.

[13] S. Dudek, F. Uebernickel, and W. Brenner. Explicating technological and

organizational interfaces of modular it service components to support the
process of it service composition. pages 7–12, 2011.

[14] C. Economics. Itil benefits and barriers to success itil benefits and barriers
to success itil benefits and barriers to success. Technical report, Computer
Economics, Inc., February 2009.

[15] P. Eeles. Capturing architectural requirements. Technical report, IBM,

November 2005.

[16] R. England. Review of recent ITIL

R studies. page 15, November 2011.

[17] M. Fry. ITIL

R Lite - A road map to full or partial ITIL implementation.

TSO (The Stationery Office), 2010.

[18] R. W. Group. Resource description framework (rdf) -

http://www.w3.org/rdf/, February 2004.

[19] T. A. Group. What is ITIL ?,

R 2007.

[20] J. Heflin. W3c:web ontology language use cases and requirements., Febru-
ary 2004.

[21] I. Herman. Web ontology language (owl), 9 2007.

[22] M. Horridge. A practical guide to building owl ontologies using protégé 4

and co-ode tools edition 1.3, March 2011.

[23] A. Hourieh. Django 1.0 Website Development. Packt Publishing Limited,

2009.

[24] J. Huang. Should you be bi-lingual as an it outsourcing service provider?

2005.

[25] ISACA. Cobit 5 executive summary, 2012.

[26] ISO/IEC. International Standard ISO/IEC 9126.Information technology

— Software product evaluation — Quality characteristics and guidelines
for their use. ISO/IEC, 1991.

86
 BIBLIOGRAPHY

[27] D. Jordan, J. Evdemon, et al. Web services business process execution

language version 2.0. OASIS Standard, April 2007.

[28] V. Kashyap. Design and creation of ontologies for environmental informa-

tion retrieval. In Proc. of the 12th Workshop on Knowledge Acquisition,
Modeling and Management, 1999.

[29] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon, and C. Bar-

reto. Web services choreography description language version 1.0. W3C
Candidate Recommendation, November 2005.

[30] S. Kempter and A. Kempter. Itil implementation. retrieved from it process

maps, 2008.

[31] J. Koehler. The Process-Rule Continuum - Can BPMN SBVR Cope with
the Challenge?, 2011.

[32] J. Kuhn. Decrypting the moscow analysis. The workable, practical guide
to Do IT Yourself, 5.44, November 2009.

[33] H. Lausen and J. Farrell. Semantic annotations for wsdl and xml schema.
W3C recommendation, W3C, 2007.

[34] T. Leidig and C. Pedrinaci. Linked usdl.

[35] D. Martin, M. Burstein, J. Hobbs, et al. Owl-s: Semantic markup for web
services owl-s: Semantic markup for web services owl-s: Semantic markup
for web services. W3C Member Submission, November 2004.

[36] E. McCormick and K. D. Volder. Jquery: finding your way through

tangled code. OOPSLA’04, October 2004.

[37] J. Nielsen. Response times: The 3 important limits. Technical report,

Nielsen Norman Group, January 1993.

[38] J. Nielsen. 10 usability heuristics. Technical report, Nielsen Norman

Group, January 1995.

[39] G. B. C. Office and S. Office. ITIL Service Design. The Stationery Offic
Series. Bernan Assoc, 2011.

[40] S. Office. Itil Service Strategy. The Stationery Offic Series. Bernan Assoc,
2011.

[41] OMG. Business Process Model and Notation (BPMN) - Version 2.0,
January 2011.

87
 BIBLIOGRAPHY

[42] M. Papazoglou and J. Yang. Design methodology for web services and
business processes. 2444:175–233, 2002.

[43] R. Pereira and M. da Silva. Itil maturity model. In Information Systems

and Technologies (CISTI), 2010 5th Iberian Conference on, pages 1 –6,
june 2010.

[44] J. Robertson and S. Robertson. Volere requirements specification tem-

plate. Technical Report 16, Volere, 2012.

[45] J. Rusher. Triple store, 2003.

[46] N. Shadbolt, T. Berners-Lee, and W. Hall. The semantic web revisited.

IEEE Intelligent Systems, 21(3):96–101, May 2006.

[47] I. Sommerville. Software Engineering. International Computer Science

Series. Pearson Books, 2010.

[48] D. Spinellis. Choosing a programming language. Software, IEEE, 23(4):62

–63, july-aug. 2006.

[49] C. Szyperski, D. Gruntz, and S. Murer. Component software: beyond

object-oriented programming. Component software series. ACM Press,
2002.

[50] C. Videira and A. Silva. UML, Metodologias e Ferramentas CASE, vol-

ume 2. Edições Centro Atlântico, 2005.

[51] C. Videira and A. Silva. UML, Metodologias e Ferramentas CASE, vol-

ume 1. Edições Centro Atlântico, 2005.

[52] J. Wang. How to implement itil successfully? Master’s thesis,

JÖNKÖPING INTERNATIONAL BUSINESS SCHOOL, 2010.

[53] N. R. Yergler. Using rdf with python -

http://yergler.net/talks/pythonrdf/, 2005.

[54] S. Zhao and E. Chang. From database to semantic web ontology: an

overview. In Proceedings of the 2007 OTM Confederated international
conference on On the move to meaningful internet systems - Volume Part
II, OTM’07, pages 1205–1214, Berlin, Heidelberg, 2007. Springer-Verlag.

[55] T. Zimmermann. Business decision - why i use django and not ruby on
rails - http://www.screamingatmyscreen.com/2012/2/business-decision-
why-i-use-django-and-not-ruby-on-rails/, February 2012.

88
 Technological Analysis and
A
Considerations

A.1 Web Applications Frameworks

Web Application Frameworks (WAFs) are described by Sommerville[47] as
a “very important type of framework” and “usually incorporate one or more
specialized frameworks that support specific application features (...), most
support the following Features”:
1. “Security” - “include classes to help implement user authentication (lo-
gin) and access control to ensure that users can only access permitted
functionality in the system”;

2. “Dynamic Web Pages” - “Classes are provided to help you define web
page templates and to populate these dynamically with specific data
from the system database”;

3. “Database Support” - “(...)The framework may provide classes that pro-

vide an abstract interface to different databases”;

4. “Session Management” - “classes to create and manage sessions (a num-

ber of interactions with the system by a user) are usually part of a WAF”;

5. “User Interaction” - “Most web frameworks now provide AJAX support,

which allows more interactive web pages to be created.”;

A.2 Django VS Ruby On Rails

Choosing a web framework is not an easy task and given the fact that there
are no funds for available for the development of the SPMS the choice relies

89
 APPENDIX A. TECHNOLOGICAL ANALYSIS AND
CONSIDERATIONS
in open source solutions.
In light of the above, we considered the two more complete open source
web frameworks[55]:

1. Django;

2. Ruby On Rails (RoR);

In his comparative analysis between Django and RoR, Zimmermann, refers

some of the above Django advantages (and others) and some of RoR.
In relation to Django, he states that, taking into account, his experience:

1. “python libraries tend to be more powerful or mature.”;

2. With Django applications “you cannot produce something unmaintain-

able”;

3. “Thanks to Djangos default implementation you write your database as

Python class and query it using Python”;

4. Do not provide library or migrations;

5. Provides a way to “manage all the content”, saving time and in most
cases “there’s no need for anything else”.

6. “It is used by many people (...) regular people (...) there is nothing fancy
about it” and “people can learn Django in a short amount of time”;

Zimmermann states, relatively to RoR, that:

1. In RoR “You write one line of code and you do so much things you don’t
even know about.”;

2. When “something does not work you sometimes have a really hard time
to even find the place where it fails”;

3. In RoR “was the first project that did migrations right. They are way
ahead of their competitors”.

4. RoR as an easy deployment;

In light of the above comparison, we can consider that RoR is better than
Django in Deployment and in Data Base Migration.
However, in our particular case, we do not expect to deploy the applications
a lot of times, just for proof-of-concept or presentation reasons, we don’t see

90
 A.3. WHY PYTHON?

it as a big advantage. Regarding the DB Migration, we only use db for user

information management, as you can conclude in the following paragraph.
Therefore, and having into account the familiarity with Django we selected
it as the framework to perform the development of the service portfolio man-
agement system.

A.3 Why Python?

As Ayman Hourieh[23] states, “Python is a general purpose programming
language (...) is used for a wide variety of applications (...) is very suitable
for developing web applications. (...) the language’s object-oriented model
is especially suited for MVC style development.(...)Python’s runtime environ-
ment (...) is known to be fast and stable. Python supports a wide range of
web servers through modules, including the famous Apache.(...)Python is a
free software.”. It is important to also state that python is the most familiar
language to the author.

A.4 Django Features in detail

Django is an open source python web framework, has as main features[23]:

1. Tight integration between components - “provides a set of tightly

integrated components(...) developed by the Django team (...) [it’s]
components were designed for integration, reusability, and speed from
the start”;

2. Object-Relational Mapper - “the Object-Relational Mapper (ORM),

provides a bridge between the data model and the database engine. It
supports a large set of database systems, and switching from one engine
to another is a matter of changing a configuration file. This gives the de-
veloper great flexibility if a decision is made to change from one database
engine to another.”;

3. Clean URL design - “URL system in Django is very flexible and pow-
erful. It lets you define patterns for the URLs in your application and
define Python functions to handle each pattern. This enables developers
to create URLs that are both user and search engine friendly.”;

4. Automatic administration interface - “Django comes with an ad-

ministration interface that is ready to be used. This interface makes the

91
APPENDIX A. TECHNOLOGICAL ANALYSIS AND
CONSIDERATIONS
management of your application’s data a breeze. It is also highly flexible
and customizable.”;

5. Advanced development environment - “Django provides a very nice

development environment. It comes with a lightweight web server for de-
velopment and testing. When the debugging mode is enabled, Django
provides very thorough and detailed error messages with a lot of de-
bugging information. All of this makes isolating and fixing bugs very
easy.”;

6. Multilingual support - “supports multilingual web sites through its

built-in internationalization system. This can be very valuable for those
working on web sites with more than one language. ”;

7. Standard Features of a web framework - “The standard features

expected of a web framework are all available in Django. These include
the following:

• A template and text filtering engine with simple, but extensible

syntax
• A form generation and validation API
• An extensible authentication system
• A caching system for speeding up the performance of applications
• A feed framework for generating RSS feeds;

92
 Requirements Methodology and
B
Guidelines

B.1 Followed Methodology

In order to properly clarify this thesis requirements four methodologies for
requirements analysis were considered:

1. FURPS[15];

2. FURPS+[15];

3. ISO/IEC 9126[26];

4. Volere1 ;

Volere, more specifically, Volere Requirements Specification Template[44],

provides a “rock-solid template and guide to writing appropriate requirements
specifications”, and therefore “ has proved to be a valuable resource for or-
ganizations worldwide by saving significant time and money for their require-
ments activities.”[44]. However this template has an associated cost, and con-
sequently was not considered furtherly by us.
The other three address at different levels various classes of requirements.
Taking into account a global view such methodologies (FURPS, FURPS+
and ISO/IEC 9126), we can state that the most complete one as can observe
in Figure B.1 is FURPS+. Since we need to specify some requirements of
the “plus” categories, and since FURPS+ is more complete, it is the chosen
methodology for requirement analysis.
1
Volere - http://www.volere.co.uk

93
 APPENDIX B. REQUIREMENTS METHODOLOGY AND
GUIDELINES

Figure B.1: Comparison between requirements methodology.

B.2 Adopted Guidelines

In order to better explain each of the requirements, we present a “Natu-
ral Language Specification”[47], which is based on the following Sommerville
guidelines:

1. Express the requirement in a single sentence;

2. Distinguish between mandatory and desirable requirements. In this sense

we adopt a better, and more complete analysis, MoSCoW, of classify-
ing requirements, without leaving the prioritization principle behind this
guideline. Since MoSCoW “provides a simple way for users to prioritize
their service requirements”[32]. MoSCoW divides requirements into four
ascending categories:

• Must Have - “Key requirements without which the service has no

value.”;
• Should Have – “This is an important requirement that must be
delivered, but if time is short, could be delayed for a future delivery.
The service still has value without these features.”;
• Could Have – “This requirement would be useful to have if it does
not cost too much or take too long to develop, but it is not central
to the service.”;

94
 B.2. ADOPTED GUIDELINES

• Won’t Have/Would Like To Have Next Time – “This require-

ment is not needed now, but will be needed in the future, where it
may be upgraded to a MUST HAVE.”;

3. Use text highlighting (bold, italic, or color) to pick out key parts of the
requirement;

4. Avoid the use of jargon, abbreviations, and acronyms;

5. (Whenever possible) associate a rationale with each requirement, ex-

plaining why the requirement has been included;

95
 Functional Requirements Mockups and
C
Sequence Diagrams

In this appendix we present graphical mockups and sequence diagrams of

the most relevant functional requirements.
It should be noticed that some only have a mockup or the sequence dia-
grams and some others, have none. And some other functional requirements,
such as import workflow, import interfaces, filter catalogue fervice instances,
filter services by Searching criteria, filter services instance by category, ex-
port service instance and log company out are present in other requirements
mockups. Due to similarity, some mockups and sequence diagrams were not
developed, for instance, add ITSM service and edit ITSM service requirements.

97
 C.1 Requirement F1. Register Company

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
98

C.1.1 Graphical Mockup

Figure C.1: Register Company Graphical Mockup

 C.2 Requirement F2. Log Company In
C.2.1 Graphical Mockup

C.2.
REQUIREMENT F2. LOG COMPANY IN
99

Figure C.2: Log Company In Graphical Mockup

 C.3 Requirement F3. Add ITSM Service Instance

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
100

C.3.1 Graphical Mockup

Figure C.3: Add ITSM Service Instance Graphical Mockup

 C.3. REQUIREMENT F3. ADD ITSM SERVICE INSTANCE

C.3.2 Sequence Diagram

Figure C.4: Add ITSM Service Instance Sequence Diagram

101
 C.4 Requirement F5. Add ITSM Service

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
102

C.4.1 Graphical Mockup

Figure C.5: Add ITSM Service Graphical Mockup

 C.4. REQUIREMENT F5. ADD ITSM SERVICE

C.4.2 Sequence Diagram

Figure C.6: Add ITSM Service Sequence Diagram

103
 C.5 Requirement F9. Edit ITSM Service Instance Properties

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
104

C.5.1 Graphical Mockup

Figure C.7: Edit ITSM Service Instance Properties Graphical Mockup

 C.5. REQUIREMENT F9. EDIT ITSM SERVICE INSTANCE
PROPERTIES
C.5.2 Sequence Diagram

Figure C.8: Edit ITSM Service Instance Properties Sequence Diagram

105
 C.6 Requirement F10. Search Service

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
106

C.6.1 Graphical Mockup

Figure C.9: Search Service Graphical Mockup

 C.6. REQUIREMENT F10. SEARCH SERVICE

C.6.2 Sequence Diagram

Figure C.10: Search Service Sequence Diagram

107
 C.7 Requirement F11. Browse Service

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
108

C.7.1 Graphical Mockup

Figure C.11: Browse Service Graphical Mockup

 C.7. REQUIREMENT F11. BROWSE SERVICE

C.7.2 Sequence Diagram

Figure C.12: Browse Service Sequence Diagram

109
 C.8 Requirement F12. View Own Portfolio

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
110

C.8.1 Graphical Mockup

Figure C.13: View Own Portfolio Graphical Mockup

 C.8. REQUIREMENT F12. VIEW OWN PORTFOLIO

C.8.2 Sequence Diagram

Figure C.14: View Own Portfolio Sequence Diagram

111
 C.9 Requirement F13. View Consumer Company Catalogue

SEQUENCE DIAGRAMS
APPENDIX C. FUNCTIONAL REQUIREMENTS MOCKUPS AND
112

C.9.1 Graphical Mockup

Figure C.15: View Consumer Company Catalogue Graphical Mockup

 C.9. REQUIREMENT F13. VIEW CONSUMER COMPANY
CATALOGUE
C.9.2 Sequence Diagram

Figure C.16: View Consumer Company Catalogue Sequence Diagram

113
 SAPO Interfaces Diagrams
D
In this appendix we present graphical representation of the Incident Man-
agement (IM) interface and Problem Management (PM) interface diagrams.
Since some diagrams are too large we had to subdivide it in order to be pre-
sented here.

115
 D.1 Incident Management

APPENDIX D. SAPO INTERFACES DIAGRAMS

116

D.1.1 Business Process

Figure D.1: Part one of Incident Management Business Process

 D.1. INCIDENT MANAGEMENT
Figure D.2: Part two of Incident Management Business Process
117
 D.1.2 Cross-Functional Flowchart Diagrams

APPENDIX D. SAPO INTERFACES DIAGRAMS

118

Figure D.3: ITIL Incident Management Cross-Functional Flowchart Diagram for Incident Identification
 D.1. INCIDENT MANAGEMENT
Figure D.4: ITIL Incident Management Cross-Functional Flowchart Diagram for Is this really an Incident?
119
 APPENDIX D. SAPO INTERFACES DIAGRAMS
120

Figure D.5: ITIL Incident Management Cross-Functional Flowchart Diagram for Incident Categorization and Prioritization
 D.1. INCIDENT MANAGEMENT
Figure D.6: ITIL Incident Management Cross-Functional Flowchart Diagram for Incident Matching, Initial Diagnosis and
121

Escalation
 APPENDIX D. SAPO INTERFACES DIAGRAMS
122

Figure D.7: ITIL Incident Management Cross-Functional Flowchart Diagram for Incident Resolution, Recovery and Closure
 D.1. INCIDENT MANAGEMENT
Figure D.8: ITIL Incident Management Cross-Functional Flowchart Diagram for Search Incident
123
 APPENDIX D. SAPO INTERFACES DIAGRAMS
124

Figure D.9: ITIL Incident Management Cross-Functional Flowchart Diagram for Change Incident Status or Owner
 D.2 Problem Management
D.2.1 Business Process

D.2. PROBLEM MANAGEMENT

Figure D.10: Part one of Problem Management Business Process
125
 APPENDIX D. SAPO INTERFACES DIAGRAMS
126

Figure D.11: Part two of Problem Management Business Process

 D.2. PROBLEM MANAGEMENT
Figure D.12: Part three of Problem Management Business Process
127
 D.2.2 Cross-Functional Flowchart Diagrams

APPENDIX D. SAPO INTERFACES DIAGRAMS

128

Figure D.13: ITIL Problem Management Cross-Functional Flowchart Diagram for Problem Identification
 D.2. PROBLEM MANAGEMENT
129

Figure D.14: Part one of ITIL Problem Management Cross-Functional Flowchart Diagram for Problem Categorization and
Prioritization
 APPENDIX D. SAPO INTERFACES DIAGRAMS
130

Figure D.15: Part two of ITIL Problem Management Cross-Functional Flowchart Diagram for Problem Categorization and
Prioritization
 D.2. PROBLEM MANAGEMENT
Figure D.16: ITIL Problem Management Cross-Functional Flowchart Diagram for Problem Investigation and Diagnosis
131
 APPENDIX D. SAPO INTERFACES DIAGRAMS
132

Figure D.17: ITIL Problem Management Cross-Functional Flowchart Diagram for Workarounds and Known Errors
 D.2. PROBLEM MANAGEMENT
Figure D.18: ITIL Problem Management Cross-Functional Flowchart Diagram for Problem Identification
133
 APPENDIX D. SAPO INTERFACES DIAGRAMS
134

Figure D.19: ITIL Problem Management Cross-Functional Flowchart Diagram for Search Problem
 D.2. PROBLEM MANAGEMENT
135

Figure D.20: ITIL Problem Management Cross-Functional Flowchart Diagram for Change Problem Status or Owner
 APPENDIX D. SAPO INTERFACES DIAGRAMS
136

Figure D.21: ITIL Problem Management Cross-Functional Flowchart Diagram for Known Errors Management
 BPMN Ontology
E
In this appendix we present graphical representation of the BPMN Ontol-
ogy developed by us in order to semantically represent business processes and
its elements.

137
 APPENDIX E. BPMN ONTOLOGY
138

Figure E.1: BPMN Ontology graph

.
139
 Schedule
F
In this section we clarify the considered actions that we hope to take place
during the second semester.

F.0.3 First Semester Schedule

The following Gantt Chart represents the first semester work scheduling.
Figure F.1 Shows the preliminary schedule of work.

141
 APPENDIX F. SCHEDULE
142

Figure F.1: First Semester Work Schedule

 F.1. SECOND SEMESTER SCHEDULE

F.1 Second Semester Schedule

The following list enumerates the considered tasks for second semester, at
the end of the first semester:

1. Corrections proposed by jury - Perform changes pointed out by the

jury during the intermediate presentation;

2. Corrections of EM1 and IM2 Interfaces - Perform changes pointed

out by SAPO partners regarding the developed interfaces (Event Man-
agement and Incident Management);

3. Specification of the test plan - Create and document, in the report,

what will be the test plan;

4. Specify the detailed architecture - perform detailed architecture and

document it in thesis document;

5. Reading and analysis of ITIL Problem Management - Read and

analyze the Problem management practice and respective process flow
from the ITIL Service Operation publication;

6. Development of ITIL Problem Management Interfaces - Create

and specify the interfaces and workflow model (BPMN) for the Problem
Management ITIL practice;

7. Revision of technologies(Django, RDFLib and RDFLib-PostgreSQL)

- Study and review the functioning of programming technologies used to
perform the implementation of the SPMS;

8. SPMS3 implementation - Implement the SPMS application;

9. Test Plan Execution - Execute tests accordingly to the developed test

plan;

10. Thesis final report writing and revision - Write the final report,
this is a task to be performed throughout the semester;

11. Final presentation preparation - Make the presentation slides and

prepare for the final presentation;

Figure F.2 presents a Gantt chart for second semester work.

1
EM stands for Event Management
2
IM stands for Incident Management
3
SPMS stands for Service Portfolio Management System

143
 APPENDIX F. SCHEDULE
144

Figure F.2: Second Semester Schedule

The tasks regarding interface development took longer than was expected.