Vaisanen MGMT

Master’s Thesis
HELSINKI UNIVERSITY OF TECHNOLOGY

Department of Electrical and Communications Engineering
Juha Väisänen
Configuration Management for Performance Reporting in

Telecommunication Networks
This master’s thesis has been submitted for official examination for the
degree of Master of Science in Telecommunication in Espoo, Finland on
April 22, 2005
Supervisor: Professor Antti Ylä-Jääski
Instructor: M. Sc. Esa Nyman

HELSINKI UNIVERSITY OF TECHNOLOGY Abstract of the Master’s Thesis
Author: Juha Väisänen
Name of the Thesis: Configuration Management for Performance Reporting in
Date: 18.04.2005 Number of Pages: 60
Department: Department of Electrical and Communications Engineering

Professorship: T-110 Telecommunication software
Supervisor: Professor Antti Ylä-Jääski

Instructor: M. Sc. Esa Nyman
Software configuration management is a core part of the whole software

development. There needs to be a formal way of doing software updates in a similar
way over and over again. Development processes and version management policies
are essential part of this.
Mobile networks are constantly under change. Network vendors update software
running on different network elements and operators change the topology settings of
the network. The number of the different types of network elements rises when new
technologies are launched or existing elements are upgraded. Simultaneously the
complexity of the network design and optimization functionalities is growing.
Therefore getting of up to date network data from a performance management system
is necessity for network designers.
The goal of the study project was to design and implement a new configuration
management process for telecommunication network performance management
system. A new management tool was evaluated to get analysis whether it handles the
identified challenges.
The paper gives basic knowledge about mobile networks and how the network
performance can be measured. This also gives a hint of the amount and structure of
changes occurring in the network. Generic models for development process and
versioning are summarized to get basis for the discovered solution model.
The solution defines new formally specified development process models and new
version management policy. The practical part of the solution goes through the setup
and usage of the new software quality management tool that helps to accomplish the
criteria set for the project.
Key words: change management, mobile network, performance management,

versioning, development process
TEKNILLINEN KORKEAKOULU Diplomityön tiivistelmä
Tekijä: Juha Väisänen
Työn nimi: Configuration Management for Performance Reporting in
Päivämäärä: 18.04.2005 Sivumäärä: 60
Osasto: Sähkö- ja Tietoliikennetekniikka

Professuuri: T-110 Tietoliikenneohjelmistot
Työn valvoja: Professori Antti Ylä-Jääski

Työn ohjaaja: DI Esa Nyman
Ohjelmistojen konfiguraationhallinta luo perustan koko ohjelmistokehitykselle.

Tarvitaan määrämuotoisia keinoja ohjelmistopäivitysten tekemiseen samalla tavalla
kerta toisensa jälkeen. Ohjelmistokehitysprosessit ja versionhallintamallit ovat
olennainen osa ohjelmistojen konfiguraationhallintaa.
Matkapuhelinverkot ovat jatkuvasti muutoksen kohteena. Verkkovalmistajat

päivittävät verkkoelementtien ohjelmistoja ja operaattorit muuttavat verkon
topologiaa paremmin käyttöastetta vastaavaksi. Uusien teknisten parannuksien myötä
tulee sekä päivityksiä olemassa oleviin elementteihin, että uusia verkkoelementtejä.
Verkkojen asiakaskohtaiset erot voivat myös olla suuria. Samanaikaisesti tekniikan
kanssa verkon suunnittelu ja optimointi monimutkaistuvat. Verkkosuunnittelijoilla
on selkeä tarve ajantasalla olevalle verkon suorituskyky- mittausjärjestelmälle.
Tämän diplomityön puitteissa on evaluoitu olemassa olevia kehitysprosesseja sekä

versionhallintaa. Tavoitteena oli suunnitella ja toteuttaa uusi konfiguraationhallinta-
malli, joka käyttäisi hyväkseen uutta hallintatyökalua. Tämän työkalun avulla oli
tarkoitus voittaa olemassa olevia haasteita.
Työ käsittelee matkapuhelinverkkoja yleisellä tasolla. Tämän avulla selviää

verkonsuorituskykymittauksissa käytettyjen mittareiden tausta, sekä verkosta
johtuvien järjestelmään kohdistuvien muutostarpeiden määrä.
Työn tuloksena esitellään datamallinnuksen ja raportoinnin kehitysprosessit ja

ratkaisumalli versiohallinnaksi. Tämän lisäksi analysoidaan uuden työkalun tuomia
hyötyjä ongelmien ratkaisemiseksi.
Avainsanat: Muutokset, matkapuhelinverkko, suorituskykymittaus, versiohallinta,

kehitysprosessi
Acknowledgements
This Master’s Thesis has been done for Distocraft Ltd in Helsinki, Finland
I wish to present my gratitude to my supervisor, Professor Antti Ylä-Jääski for his

advices on structuring and writing this thesis. His comments helped a lot during the start
up and finishing of the project.
I would also like to thank my instructor M. Sc. Esa Nyman for the numerous advises
during the process. His visions about the subject of the thesis have been valuable.
Many thanks for also other colleagues at Distocraft for the support during the project and
making this thesis possible.
Last but not least, I thank my lovely wife for her support and patience during my studies.
In Espoo, Finland on April 18, 2005
Juha Väisänen
TABLE OF CONTENTS
1. INTRODUCTION..................................................................................................... 1
1.1 SCOPE DEFINITION ............................................................................................... 2
1.2 PROBLEM SETTING ............................................................................................... 2
1.3 STRUCTURE OF THE STUDY .................................................................................. 3
2 NETWORK ............................................................................................................... 4
2.1 NETWORK EVOLUTION......................................................................................... 4
2.1.1 What changed with EDGE update? ............................................................ 7
2.2 MOBILE NETWORK ARCHITECTURE...................................................................... 7
2.2.1 BSS ............................................................................................................. 9
2.2.2 NSS ............................................................................................................. 9
2.2.3 Packet Core Network ................................................................................ 10
2.2.4 OSS ........................................................................................................... 11
2.3 NETWORK MEASUREMENTS ............................................................................... 11
2.3.1 EGPRS related measurement types .......................................................... 12
2.4 NETWORK PLANNING AND OPTIMIZATION .......................................................... 13
2.4.1 Key Performance Indicators and EDGE ................................................... 13
3 SOFTWARE DEVELOPMENT AND MANAGEMENT .................................. 14

3.1 SOFTWARE DEVELOPMENT ................................................................................. 14
3.1.1 Software product development process .................................................... 14
3.1.2 Process for customization ......................................................................... 17
3.2 SOFTWARE CONFIGURATION MANAGEMENT....................................................... 20
3.2.1 Version management ................................................................................ 21
4 NETWORK PERFORMANCE REPORTING SYSTEM AND ITS

VERSIONING................................................................................................................. 24
4.1 GENERAL OVERVIEW ......................................................................................... 24
4.1.1 Universes................................................................................................... 25
4.1.2 Reports ...................................................................................................... 27
4.2 VERSION AND CHANGE MANAGEMENT ............................................................... 28
4.2.1 Network updates ....................................................................................... 28
4.2.2 Operator initiated updates ......................................................................... 29
4.2.3 Product updates......................................................................................... 29
4.2.4 Third party software updates .................................................................... 29
5 DEVELOPMENT OF NEW SOLUTION MODELS.......................................... 30

5.1 STARTING POINT OF THE ENVIRONMENT............................................................ 30
5.2 CHALLENGES AND CRITERIA FOR SOLUTION MODELS ....................................... 31
5.3 DEVELOPMENT PROCESS FOR PRODUCT COMPONENTS ...................................... 33
5.3.1 Feasibility Study and Specification phase ................................................ 33
5.3.2 Design phase ............................................................................................. 34
5.3.3 Development phase................................................................................... 34
5.3.4 Integration phase and testing .................................................................... 34
5.3.5 Maintenance.............................................................................................. 35
5.4 DEVELOPMENT PROCESS FOR CUSTOMIZED COMPONENTS ................................ 35
5.4.1 Feasibility Study and Specification phase ................................................ 36
5.4.2 Design phase ............................................................................................. 36
5.4.3 Development phase................................................................................... 36
5.4.4 Integration phase and testing .................................................................... 37
5.4.5 Maintenance.............................................................................................. 37
5.5 GENERAL VERSIONING PRINCIPLES .................................................................... 37
5.5.1 Platform changes....................................................................................... 38
5.5.2 Network vendor initiated versioning ........................................................ 38
5.5.3 Customer variation versioning.................................................................. 38
5.5.4 Bug fix versioning..................................................................................... 39
5.6 LAUNCH OF A NEW MANAGEMENT TOOL ............................................................ 39
5.6.1 What benefits came with the new tool...................................................... 39
5.6.2 How is EQM launched? ............................................................................ 41
5.6.3 How EQM works? .................................................................................... 42
5.7 CASE NOKIA EDGE UPDATE.............................................................................. 43
5.7.1 Sources for universe upgrade.................................................................... 44
5.7.2 Sources for report upgrade........................................................................ 44
5.7.3 Versioning of components ........................................................................ 45
6 ANALYSIS OF THE RESULTS ........................................................................... 46

6.1 DID EQM MEET THE EXPECTATIONS SET FOR IT? ............................................. 46
6.1.1 Easiness of Installation ............................................................................. 46
6.1.2 User Friendliness of the EQM .................................................................. 47
6.1.3 Usability of features.................................................................................. 49
6.1.4 Summary of the EQM............................................................................... 49
6.2 NEW DEVELOPMENT PROCESS IN USE ............................................................... 51
6.2.1 Product development process ................................................................... 51
6.2.2 Customization process .............................................................................. 51
6.2.3 Summary of the Development Processes.................................................. 52
6.3 SUITABILITY OF THE NEW VERSIONING MODEL ................................................. 52
6.3.1 Summary of the Versioning Model........................................................... 53
7 CONCLUSION ....................................................................................................... 54
7.1 RECOMMENDATIONS FOR FUTURE STUDIES ........................................................ 55
LIST OF FIGURES
Figure 1: Second Generation GSM Evolution [Kel02]....................................................... 5

Figure 2: Topology of the GSM Phase 1 Network [Kor04] ............................................... 5
Figure 3: GPRS Network Architecture [Bir04] .................................................................. 6
Figure 4: 2G Mobile Network Architecture [Häm01] ........................................................ 8
Figure 5: Waterfall Model [Sch02]................................................................................... 15
Figure 6: Fountain Model [Sch02].................................................................................... 18
Figure 7: Extreme Programming Life Cycle [XP00]........................................................ 20
Figure 8: Check-in / Check-out Model of Version Management [App98]....................... 21
Figure 9: Branching and Merging in Version Control [App98] ....................................... 22
Figure 10: DC5000 Product Architecture [Dis04]............................................................ 25
Figure 11: Network Data Modeling in DC5000 [Dis04] .................................................. 26
Figure 12: Line Graph Report Example [Dis04] .............................................................. 27
Figure 13: The EQM User Interface [EQM04]................................................................. 41
Figure 14: The EQM Work Flow [Noa04] ....................................................................... 43
Figure 15: All Commands Visible [EQM04].................................................................... 47
LIST OF ABBREVIATIONS
0.3 GMSK 0.3 Gaussian Module Shift Keying

8-PSK Octant Pulse Shift Keying
AuC Authentication Centre
BG Border Gateway
BO Business Objects
BSS Base Station Subsystem
BSC Base Station Controller
BTS Base Transceiver Station
CS Circuit Switched
CVS Concurrent Versioning System
DNS Domain Name Server
EDAP Enhanced Dynamic A-bis Pool
EDGE Enhanced Data rates for GSM Evolution
EGPRS Enhanced GPRS
EIR Equipment Identity Register
EQM Enterprise Quality Manager
ETSI European Telecommunication Standards Institute
FM Fault Management
GGSN Gateway GPRS Support Node
GMSC Gateway MSC
GPRS General Packet Radio Service
GR GPRS Register
GSM Global System for Mobile communications
HLR Home Location Register
HSCSD High Speed Circuit Switched Data
KPI Key Performance Indicator
MS Mobile Station
MSC Mobile Switching Centre
NMT Nordic Mobile Telephone system
NSS Network Switching Subsystem
ODBC Open DataBase Connectivity
OSS Operations Subsystem
OMC Operations and Maintenance Centre
PCU Packet Control Unit
PM Performance Management
PS Packet Switched
PSTN Public Switched Telephone Network
SCM Software Configuration Management
SGSN Serving GPRS Support Node
SIM Subscriber Identity Module
SMS Short Message Service
SQA Software Quality Assurance
SQL Structured Query Language
TRX Transceiver
UMTS Universal Mobile Telecommunications System
XP Extreme Programming
INTRODUCTION________________________________________________________
1. Introduction
Software development is a rather new field of science and is therefore still evolving quite
often. All the process models and guide lines that are available are ideal visions of what
could suit for an ideal project. There exists no ideal project, so models need to be
adjusted to suit the project type at hand. Therefore it is no surprise, that many companies
constantly redesign their development process to be more efficient.
The mobile telecommunications is another rapidly changing field of technology. From

the early days of the mobile networks the pace has only become faster. Mobile user rates
have exploded to compete for the number one spot of the telecommunications channels.
In many countries mobile users have already bypassed the user rate of fixed line
telephone users. The growth in the users has developed needs for various new application
areas that could not be even dreamed of a decade ago.
As the mobile networks have evolved towards more complexity, the challenges of
network operators for designing efficient and cost benefit networks have become harder.
The variety of network element vendors is wide and all of them support call handling and
maintenance differently. Optimization of one element could not work similarly with
another vendor’s same element.
Distocraft Ltd. is a developer of network performance management and quality assurance

software. Distocraft loads performance and event data from the network and models it for
the operator’s end users. As the product and customer base have grown, Distocraft has
faced the pressure to adopt a formally accepted process model for development and
version management. New solutions need to be tested and improved all the time to be on
the edge of the development.
This thesis describes the evaluation and implementation of the new software development
process for the Distocraft DC5000 product. New version management policies were also
developed hand in hand with the development process renewal. The main part of the
________________________________________________________________________
1
INTRODUCTION________________________________________________________
practical case was to evaluate the suitability of new management tool for the Distocraft
DC5000 product component management. The new process model and the versioning
principles were designed to be suitable whether or not the new management tool was
used.
1.1 Scope definition
The study concentrates on the end user side of the Distocraft DC5000 product, giving
other parts of the product minor attention. As the selected case project concerned the
EDGE technology other network technologies especially newer ones like UMTS are out
of the scope of this paper and not described in detail.
The software development process is such wide a subject it is described within this thesis
only in such detail that generic models behind the solution models are selected and
evaluated deeper. Other process models were evaluated but are introduced here only
briefly. The same principle was used with the software configuration management with
focus only on version management.
1.2 Problem setting
The objective of this thesis is to evaluate the software development process and version
management process of the Distocraft DC5000 system. The goal of the study is to
generate a new development process model and version control policy for the Business
Objects components of the Distocraft DC5000 product. The use of the Enterprise Quality
Manager (EQM) software tool to accomplish this task is evaluated and tested with a case
project.
________________________________________________________________________
2
INTRODUCTION________________________________________________________
Results of this thesis can be used in improving further the development process since it
summarizes the factors generating changes in the system. It is also useful in the
evaluation of the need for launching the EQM in a larger scale.
1.3 Structure of the study
To get the understanding of the problem field the European second generation mobile
networks are first introduced with the main focus on the EDGE technology. The second
chapter focuses on the software development and configuration management issues and
describes the process models behind the solution models found as a result of this thesis.
After these chapters the focus is turned to the network performance management systems
and their challenges. The Distocraft DC5000 network performance management product
is introduced deeper as the whole thesis is implemented for it.
After the background information the starting point for the thesis is summarized and
criteria for the solution models are given. The solution models are introduced and the
implementation description is given with a practical example.
The solution models and their implementation are analyzed against the set criteria and
user experience. Finally, the thesis is concluded with the summary of the main objectives
and results. Some research issues for the future are also given.
________________________________________________________________________
3
NETWORK______________________________________________________________
2 Network
This chapter familiarizes reader to the ETSI GSM network by first summarizing the
evolution of the network technologies. After that the second generation network elements
are introduced more thoroughly and network element measurements are described.
Working with these measurements to ease network development and optimization
process is explained briefly for the new EDGE measurements. As for the whole thesis the
main focus area is kept on the GPRS/EDGE technologies.
2.1 Network Evolution
Mobile networks and terminals have gone through many changes since the time of the
first generation NMT (Nordic Mobile Telephone) networks when connections were
created with analog phones, data transfer capabilities were limited and had slow bit rates
and terminals were big or even huge. [Pen02]
The second generation mobile networks which in many cases are referred as GSM
networks (Global System for Mobile communications) were launched at the beginning of
the 1990’s. This changed the partly analog NMT network to an all digital GSM network.
The first GSM data services were launched around 1994, when data transfer rates were
very slow with maximum of 9,6 kbps. The SMS (Short Message Service) was also
introduced with the GSM version 1, although the success story of the SMS did not
happen until many years later. [Pen02][Gar99]
________________________________________________________________________
4
NETWORK______________________________________________________________
Figure 1: Second Generation GSM Evolution [Kel02]
The Usage of the mobile phones has exploded since the launch of the GSM. No one
expected the GSM to be so popular and widely used. The GSM was specified for voice
traffic only with restricted data transfer capabilities. The huge interest towards GSM and
rapidly growing usage developed needs for new service areas and better data rates. The
first data rate improvement of the GSM was around 1999 when HSCSD (High Speed
Circuit Switched [multislot] Data) was introduced for public use. [Voi00][Pen02]
Figure 2: Topology of the GSM Phase 1 Network [Kor04]
________________________________________________________________________
5
NETWORK______________________________________________________________
This HSCSD enabled circuit switched data transfer for theoretical maximum of 56 kbps.
Circuit switched connection was not an optimal solution for data traffic because of its
bursty nature. Therefore a packet switched network like the one used in the Internet was
needed. The General Packet Radio Service (GPRS) technology was developed to tackle
these needs. It brought tremendous changes to the GSM network topology by introducing
many new elements. With the GPRS, theoretical data transfer maximum was increased to
almost 170kbps although this is rarely achieved because of terminal and network
restrictions. [Jam03] [Hal02]
Figure 3: GPRS Network Architecture [Bir04]
Evolution of mobile services towards video conferencing and playing network games
introduced demand for faster data rates. Another driving force was the need to modify the
network elements to cope with UMTS standards. This led to the introduction of the
Enhanced Data Rates for Global Evolution (EDGE), which is an enhancement to the
standard GSM radio interface technology. The EDGE uses a new modulation technique
which enables data rates with a maximum of nearly 400 kbps. As with the GPRS this is
________________________________________________________________________
6
NETWORK______________________________________________________________
theoretical only and the same network and mobile phone restrictions appear with the
EDGE also. [Stu03][Pen02][Kos98]
The first third generation (3G) network in Finland was opened for public use in October
2004. Before this some application developers and testers of the operators had used the
network. The growth of the 3G network usage will first be quite slow since the number of
3G mobile phones available is low. The 3G and UMTS are out of the scope of this thesis
so they are not described in detail.
2.1.1 What changed with EDGE update?
The Enhanced Data Rates for Global Evolution (EDGE) was mainly a software update.
No completely new elements were introduced with the EDGE. However, it considerably
changed the way packet based data is transferred. The biggest change was the new
modulation technique 8-PSK implemented on the side of the former 0.3 GMSK. With this
new modulation technique theoretical maximum of the data rate was more than doubled.
To get the EGPRS to work, the Transceivers (TRX) in the BTS needed to be changed and
some software updates had to be run for other elements and protocol stacks. [Hal02]
[Stu03][Seu03]
2.2 Mobile Network architecture
The 2G mobile network architecture can be divided into four different parts. The radio
access network or Base Station Subsystem contains the Base Transceiver Stations (BTS)
and the Base Station Controllers (BSC) which are used to establish the radio interface
between the mobile phone and the network.
The Network Switching Sub-system is the main part of the circuit switched connections
of the mobile network. The Mobile Service switching Centre (MSC) with its many
________________________________________________________________________
7
NETWORK______________________________________________________________
register elements is essential for connection establishment, location tracking, handovers
and many other functions.
The Packet core network contains the main elements for the GPRS packet based
connections. It transfers data packets within the mobile network and gateways to Internet
locations.
The fourth part is the Operations Sub-System (OSS). The Operations and Maintenance
Centre (OMC) controls the network elements and handles their maintenance tasks. The
OMC also receives measurement data from other network elements concerning their state
and actions. [Hal92][Mou92][Gar99][Pen02]
Figure 4: 2G Mobile Network Architecture [Häm01]
________________________________________________________________________
8
NETWORK______________________________________________________________
2.2.1 BSS
The main objective of the BSS is to connect the MS with the NSS/GPRS packet core
network. The Mobile Station (MS) is connected to the BTS via radio interface.
Parameters of this interface are not stable because of the mobility. The MS can
simultaneously be inside the area of multiple cells covered with one or more BTSs. A cell
can have one or more Transceivers (TRX), which transfer data on a different frequency
than used on other TRXs in the same cell or the adjacent cell. The MS and the BTS
constantly send signaling information about the location and the signal strength even
when there are no incoming or outgoing calls.
The BSC is a controlling element for the BTSs connected directly to it. It analyzes the
radio resources available on different cells and makes decisions concerning handovers of
an MS to a cell with better signal strength or lower usage level. A BSC informs an MSC
about the location of the MS. A BSC can also ask an MSC to switch the control of an MS
to another BSC if a BSC handover is needed. A BSC allocates incoming calls depending
on the radio resources available in the different possible cells. [Mou92][Pen02]
2.2.2 NSS
The main element in the NSS is the MSC which is almost like the mobility enhanced
switching exchange of the Public Switched Telephone Network (PSTN). The main
responsibilities of the MSC are call switching, maintenance and termination. Other
functionalities are more mobility related like mobility management, including the
location management of the MS and aiding in handover procedures. The NSS also
contains various registers and the most important ones are introduced next.
The Home Location Register (HLR) contains subscriber information of mobile users. The
HLR holds the location information of the subscriber and changes the value every time
the mobile user changes location area. Also some more static subscriber information like
________________________________________________________________________
9
NETWORK______________________________________________________________
billing and roaming constraints are stored in the HLR. The Visitor Location Register
(VLR) is a register that holds the subscriber information when the mobile user is roaming
or otherwise not under its own MSC/HLR. The VLR is used to update location
information in the HLR and also to query static information from the HLR.
The Equipment Identity Register (EIR) is responsible for identifying the terminal
equipment trying to connect the network and prevent the usage of stolen or defective
mobile stations. It holds three lists of different equipment categories, white for valid,
black for barred and grey for mobile phones that are tracked.
The Authentication Center (AuC) provides user authentication and authorization. It holds
authentication and encryption parameters for users and plays an important role in
securing the network from illegal use. [Mul02][Hal92][Mou92]
2.2.3 Packet Core Network
The bases of the Packet Core Network or the GPRS backbone network are the Serving
GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). Other
important parts belonging to the GPRS network are the Packet Control Unit (PCU) and
the GPRS Register (GR) which is normally implemented as a subunit of the HLR.
The SGSN element handles authentication and encryption of the packet based connection
between the user and the SGSN. It keeps a track of the mobile station’s location area and
sends this location information with the possible billing information it collects to the
MSC registers.
The GGSN is a gateway between the GPRS backbone network and the Internet for
example. From external network’s point of view a GGSN element looks like a traditional
router with a sub network behind it. It also knows the SGSN element the mobile station is
connected to and can be used to collect billing information.
________________________________________________________________________
10
NETWORK______________________________________________________________
The packaging of the data is handled in the Packet Control Unit (PCU). It examines the
traffic coming from the user and directs the GPRS packets to the SGSN element. The
PCU transforms user data to the PCU frames before sending them. It also handles the
unpacking of these PCU frames coming from the network. The PCU can be implemented
on the side of the BTS, BSC or SGSN. [Seu03][Stu03][Pen02]
2.2.4 OSS
The OSS is a network part that is not standardized and therefore implementations differ
greatly between network element vendors except for the interfaces to other network
elements that are standardized. Network elements can be managed and maintenance tasks
can be run with the OMC. It is also used for collecting billing information from network
elements. The OMC is used to run software updates for network elements and to change
their configuration parameters. It also collects information from the network elements
concerning their status and activity. This collected information is the key for the whole
performance and quality reporting. [Pen02][Hal92]
2.3 Network Measurements
Many network elements like the BSC, MSC, SGSN and GGSN send their measurement
data concerning transactions happening in the network and the element status information
to the OSS. Each element sends the information corresponding to it and its interfaces.
Every element has measurements called counters that are divided into categories
depending on the interface and the usage entity. These categories are called measurement
types. All of these measurements and their categories are network vendor specific and not
standard. This causes differences in the ways in which the same network actions are
________________________________________________________________________
11
NETWORK______________________________________________________________
measured and stored. Therefore linking the counters from different vendors is not always
possible. [Dis04]
The number of the measurement types depends on the element. With Nokia’s SGSN
element measurements are categorized within about 10 different measurement types
compared to Nokia’s BSC where over 40 different categories exist. These numbers
change constantly with new software updates. In most cases software updates for network
elements bring new measurement counters or even new measurement types.
When Nokia released software version 10 for their BSC elements, 8 new measurement
types were introduced. Two of the measurement types were EGPRS related and they are
next explained more clearly. [Nok02]
2.3.1 EGPRS related measurement types
One of the new measurement types introduced with Nokia’s BSC version 10 was channel
coding class. This new class contains counters for data blocks sent in downlink and
uplink direction, for error blocks and retransmitted blocks. These counters are updated for
each channel coding scheme which were introduced with the EDGE. These measurement
counters are updated only when there is data for them. If the EGPRS has low usage in
some areas, some elements might not update these counters even once within a day.
The other new EGPRS measurement type holds counters for dynamic Abis interface
related actions. This dynamic Abis capacity is allocated for the EGPRS use only when
needed for data transfer. These counters measure actions when the EGPRS Dynamic Abis
Pool (EDAP) resources are used and when the usage has failed. [Nok02]
________________________________________________________________________
12
NETWORK______________________________________________________________
2.4 Network planning and optimization
The basic idea behind network planning and optimization is to manage the capacity of
network elements so that the network usage percent stays high. On the other hand if the
usage percent is too high network quality drops because of network congestion and
blocked calls.
Network planners need to get accurate information about the network status and traffic
changes in the network. Measurement counters can be used to track traffic changes and
find out causes for error situations. [Lai05]
2.4.1 Key Performance Indicators and EDGE
Key Performance Indicator (KPI) is an important counter or combination of multiple

counters. KPI formulas vary from one counter KPIs like “Number of Attempts” to
complex formulas of “GPRS DL Data Rate”.
The EDGE introduced categorization of 9 channel coding schemes compared to the 4

coding schemes of the GPRS technology. All of these channel coding classes have
different data rates and usage depending on the connection strength. To calculate the total
EGPRS traffic, the sum of all coding schemes must be added to get the total sum.
Because these different coding schemes don’t have separate traffic counters in the
Nokia’s implementation they are difficult to build as KPIs. The EDAP being dynamic in
nature has difficulties of its own when implementing complex KPIs.
[Dis04][Nok02][Hal02]
________________________________________________________________________
13
SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________
3 Software development and management
Software development process contains the rules by which the whole development
project is carried out from the beginning to the end. The idea behind packing software
implementations into products is to get more concrete appearance for the software with
abstract nature. Making software into a product adds value into it in the customer’s
perspective but also makes rules for the developing company. [Vit95]
The definition of the Software configuration management is one part of the whole
software development process. Software quality and maintainability are highly related to
the configuration management process. Version management is one part of the software
configuration management with various process models available.
Definition and usage of both software development and configuration management

processes are the keys for high quality software. Section 3.1 introduces software
development processes for use in different situations and section 3.2 summarizes the key
points of the software configuration aspects with main focus on version management.
3.1 Software development
There are many general software development process models available which suit for
different environments. This section goes through the process models behind the selected
solutions for two different types of product component development projects.
3.1.1 Software product development process
In software product development reusability and duplicability are essential. You need to
find ways to implement a general platform that can be used without modification as a
________________________________________________________________________
14
basis for as many solutions as possible. The result of software implementation is not a
product if it cannot be duplicated and installed for any customer without tailoring.
Therefore specifications for the product and needs of the customer have to be common.
[Vit95]
3.1.1.1 Waterfall model
Waterfall model is one of the most famous development process models. It is highly used
with governmental institutions especially by the Department of Defense in the USA. A
development process following waterfall model goes through phases as shown in figure
5. Each step has verification or testing phase in the end where it is decided whether it is
necessary to go back to the previous step or to flow forward into the next step. The need
to go back to previous phase might arise during the phase because some fault is
encountered in the output of the previous phase or the output has contradictory or
ambiguous components. [Sch02][Som96]
Figure 5: Waterfall Model [Sch02]
________________________________________________________________________
15
3.1.1.2 Waterfall model phases
Waterfall model as any other software life cycle model begins with collecting
requirements from the customer. Requirements are summarized and agreed with the
customer. This can sometimes be named as a feasibility study or a pre specification step.
After the requirements are freezed the specification documentation is written. This
documentation is the basis for the whole product and when it is accepted detailed project
plan is written with a timetable and schedule.
The design phase produces the architecture and detailed design of the product. After
verifying the architecture and design the implementation of the product can start. The
implementation phase can run in parallel with the integration phase if the product can be
split into modules with a low cohesion that can be implemented and integrated
independently.
After the implementation testing phase the product is handed to the customer for the
acceptance testing. If the customer accepts the product it is transferred into maintenance
phase. In the maintenance phase the customer can find some errors that generate changes
to previous phases. This is marked with a dotted line in figure 5 above. Product
maintenance can also end in retirement when the product is no longer needed or is
replaced with newer version. [Sch02][Som96]
3.1.1.3 Analysis and critics on the waterfall model
The waterfall model is a disciplined and a documentation driven model. Every phase
needs to be checked by the Software Quality Assurance (SQA) team in order to get
acceptance to proceed to the next phase. Testing is inherent for every phase in the
waterfall model and should be performed continuously along the whole process.
________________________________________________________________________
16
As the waterfall model is document driven everything from specifications to user
manuals are documented carefully and verified by the SQA at the end of each phase.
Precise overall documentation helps maintenance which is on average 67% of the whole
budget. In many cases the very key to success with the waterfall model has been the
document driven nature of it.
The Waterfall model has also received much criticism because of being too document
driven. If the specification is understood differently by the developer and customer the
result might not even be close to what the customer expected. Sometimes specifications
including technical details are hard for customers to understand.
It is also stated that problems are not found with this model before the system testing
phase and making modifications to specifications during later phases generates a
tremendous extra work and therefore specifications need to be stable when proceeding to
the design phase. It is also hard to predict the performance constraints before the system
is almost ready for customer acceptance. [Sch02][Som96]
3.1.2 Process for customization
In many cases the standard product is not enough for the customer and tailored
implementation is required. These customer requirements are frequently unique and
therefore cannot be duplicated for other customers. Implementation of all these customer
requirements as new product variants would make product versioning messy and difficult
to manage. The usage of customized components is the best way to tackle this. With
customization the customer can order the changes they want on top of the product. The
nature of the customization process is entirely different and thence the same software life
cycle model is not suitable. [Sch02][Som96]
________________________________________________________________________
17
3.1.2.1 Fountain Model
The Fountain model is one of the best known Object-oriented life cycle models. It is
highly iterative in nature and uses parallelism between phases. As illustrated in figure 6
the fountain model has iterations (marked by arrows) during every phase (marked by
circles). In general the model contains the same phases as the waterfall model. The
difference is in the iterative nature and the fact that different phases can overlap.
Figure 6: Fountain Model [Sch02]
________________________________________________________________________
18
3.1.2.2 Analysis and criticism of the Fountain model
The iterative nature of the model is very essential in cases when the environment and
specifications might often change. The ability to do different phases simultaneously
sometimes decreases the customer’s time needed for getting grasp of the product.
The Fountain model developed in 1990 is still quite a new process model compared to the
waterfall model introduced in 1970. Therefore not as much relevant information about
suitability of fountain model to different situations and environments is available.
The fountain model has been criticized for being too loose. This comes up when different
phases are run simultaneously and some modules might accidentally skip for example the
design phase completely.
High level of iterative coding might also degenerate into the CABTAB (code a bit, test a
bit) which refers to an undisciplined practice hackers use. [Sch02][Som96]
3.1.2.3 Extreme programming
Extreme programming is quite new approach to solve the disadvantages of other life
cycle models. It is as its name gives hint an extreme way to do things. Some of its ideas
are ideal but not easily adopted while some are quite common with only minor
modifications compared to some more traditional models. There are still some features in
it that are worth mentioning. [Jef01][XP00]
________________________________________________________________________
19
Figure 7: Extreme Programming Life Cycle [XP00]
In the planning and designing phases the customer only gives harsh use cases (User
stories) concerning what the product should do. The usage of spikes which are types of
prototypes to test and find out technical difficulties gives the customer an early grasp of
what to expect. The basic idea behind it is to keep the solution as simple as possible and
to make it possible to change the specifications along the way. This is done by defining
small releases. [Jef01][XP00]
During the implementation phase the customer should always be present to answer
questions. The implementation is done in pairs with the test cases written before the
actual code. The usage of coding standards is important while there is no owner for any
code. The code is constantly integrated to test it with other parts. [Jef01][XP00]
3.2 Software configuration management
“Software Configuration Management (SCM) consists of all activities that are needed to
manage all intermediate and final work products and relations between them in the
software development and maintenance process.” [Koj04] [Whi91].
The SCM is therefore much more than just version management of the source code. The
most important parts of the SCM are component recognition and management, product
________________________________________________________________________
20
architecture and structure, product implementation and different teams or product
families. [Koj04]
The main task of the SCM is to identify and manage changes coming from different
sources with constant cycle. This paper concentrates on the version management aspect
of the SCM leaving all other parts mainly out of scope.
3.2.1 Version management
Version management is a principle of managing changing files or components so that the

product configuration is available with status information of each of its components.
There are multiple different version management models each of which contains a
slightly different way of keeping record of the changes and about the change procedure
itself. [Koj04]
3.2.1.1 Check-in / Check-out model
The check-in / Check-out model is the most common one of the version management
models. The basic principle in it is that the user checks out a copy of a file from the
repository to the private workspace for editing. When the file is ready and tested, the user
checks in the copy back to the repository.
Figure 8: Check-in / Check-out Model of Version Management [App98]
________________________________________________________________________
21
The most basic model consists of only sequential version numbers. In this model the file
is locked when someone checks it out and no-one else can make changes to it before the
file is checked in again and the lock is released.
In more sophisticated versioning systems branching and merging is made possible.

Branching enables the parallel development of bug fixes and minor enhancements to old
version while someone else works with the new version of the same file. In the merging
procedure the newest version of the child branch is synchronized with the newest version
of the parent branch. Any conflicts in these two versions need to be solved to produce a
new working revision. [App98] [Whi91]
Figure 9: Branching and Merging in Version Control [App98]
3.2.1.2 Model analysis
The check-in / check-out model is very widely used and many software tools that use the
principles of the model are out in the market. The functionalities of various tools differ
greatly while some can only handle the basic sequential procedure another can produce
extra functionalities like version difference analysis on top of the branching and merging
abilities.
The check-in / check-out model is very suitable for situations where the files are mostly
independent and changes in one file don’t affect the functionality of the other files. The
________________________________________________________________________
22
rise of the object orientation has given momentum for the evolvement of the other version
management models. These newer models can handle versioning in the feature level like
the version set model or the module level like the composition model. [App98][Koj04]
________________________________________________________________________
23
NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____
4 Network Performance Reporting System and its

versioning
This chapter familiarizes the reader with the concept of network performance reporting
by introducing briefly the Distocraft DC5000 system. The main focus is on the end user
side components and their change management as within the whole thesis.
4.1 General overview
The DC5000 system collects various types of data like performance management (PM)
and fault management (FM) from different network elements. These network elements
can be part of a fixed, broadband or mobile network as can be seen on the figure 10. Raw
measurements from the elements are then aggregated to get busy hour values and total
values for day, week and month. This data is stored in the database tables with the current
network topology information in its own tables.
These tables are modeled in the Network Data Modeling layer with the Business Objects
Universes so that the end user doesn’t have to use the SQL to query database tables.
Above the Network Data Modeling layer is the Network Data Visualization layer which
contains reports that are used to visualize the data. This layer contains also the DC5000
reporting GUI (Graphical User Interface) which is a web interface to visualize the
reports. [Dis04]
________________________________________________________________________
24
Network
Data
Visualisation
Network
Data
Modelling
DC5000
Network Aggregated Platform
data
Data Raw data
Management
Network PM, CM, FM, SM Data

Data
Gateways Fixed/BB 2G 2.5G 3G 4G
Figure 10: DC5000 Product Architecture [Dis04]
4.1.1 Universes
Business Objects Universes are data models that help the end users to make queries to the
database without any prerequisites of the SQL. Universes hide the SQL structures behind
objects and schemas, so that the only thing the end user needs to do is to pick objects and
conditions that are wanted on the report’s query.
Objects in universes can be divided into two parts Data objects that are the mappings of
database structures like columns, tables and database functions and Condition objects that
are restrictions for the database query. These conditions can either be fixed or prompted
for the user input.
________________________________________________________________________
25
Reports /
Universe Access
Universe
REF
Reference
Data
Raw Data Aggregated

RAW AGGR Data
Figure 11: Network Data Modeling in DC5000 [Dis04]
The universe contains the model of the database schema with tables, joins between them
and contexts that specify which joins are applicable in one SQL select clause to the
database. Database connections using the ODBC are also specified in the universe.
[Des03]
The DC5000 specific universes are part of a technology package. A single technology
package of the DC5000 is a content specific vertical solution related to for example
measurements of a certain network element. A technology package covers all layers from
the data sources up to the end user reporting.
These technology package universes contain measurement and topology tables and
objects belonging to that network element plus common tables and objects like date
objects used in every universe. Universes also contain Key Performance Indicators
(KPIs) that are objects that hide the formulas of difficult measurements from the end
users. Examples of these KPIs are traffic and data rate formulas. [Dis04]
________________________________________________________________________
26
4.1.2 Reports
Reports are created with the Business Objects client and they use universes as their data
source. Reports are built by picking up objects from the universe structure like
measurement counters, KPIs and topology dimension objects. Default report is in a table
format but reports can also be generated in graph and cross tab format or as a mixture of
them.
Figure 12: Line Graph Report Example [Dis04]
Reports are end user friendly since the end user can easily create ad-hoc reports of his
own by only selecting objects from the object pool of the selected universe. With reports
end users get data from a database without any SQL knowledge. [Bus03]
________________________________________________________________________
27
4.2 Version and change management
Changes to system components can be initiated by various sources. All of these sources
can affect versioning and change management differently. Some of the changes are
initiated by the network and some on the opposite end of the chain by software updates to
the reporting platform in use. There are also many sources between these two end points.
The most important ones of these sources are next examined more thoroughly.
4.2.1 Network updates
Mobile networks are under constant change. Operators change network topology to suit
better the needs of the customers and adjust the capacity of existing elements. Network
vendors are also building new software versions and patches to existing versions, which
could mean new or changed measurement counters or sometimes even new measurement
classes with counters. Sometimes vendors release a new version where the database
structure is not compatible with the previous one.
All these changes apply to the universe structure. The modifications and removals of the
existing measurement counters are time critical since they might be used in reports and
can in the worst case prevent the report from refreshing and retrieving new data.
Operators inform of these changes and updates before they plan to execute them and
therefore they don’t come as a surprise and can be prepared for.
Sometimes network vendors execute patches directly to elements or via the OSS that
change the data format loaded from the element for example. These changes can be more
unpredictable but in most cases they affect only the data loading and the parser units of
the system. Research and Development (R&D) team also designs new features for
universes and reports based on the updated network vendor’s specifications.
________________________________________________________________________
28
4.2.2 Operator initiated updates
Sometimes network operators want to have new features into the exiting universes. These
changes could be new KPI objects or new conditions objects. If these new requirements
are general and in line with the other product items, a new tech pack universe version
could be created. In other cases a linked customer universe must be created above the
tech pack universe in order to have these requirements fulfilled. The Customer’s universe
developers can then either make the new features to this customer universe or get a
consultant to make them. If the customer does universe development of his own,
specifications should be available also for the R&D generating the new technology
package version so that overlap in names and functions could be avoided.
4.2.3 Product updates
The R&D constantly searches for new solutions for databases and universes to optimize
and lower query times and also to get universes to generate a better SQL for the reports.
The R&D development process is highly iterative because it is hard to predict how one
change affects other parts. Reports can contain almost an unlimited number of possible
SQL queries and therefore cohesion of two different problems is hard to come up without
testing with prototypes.
4.2.4 Third party software updates
Reports and Universes that are generated with Business Objects (BO) are highly version
dependent. In many cases you cannot use reports that are created or modified with a
newer BO with an older BO version. On the other hand the newer BO version might face
problems when using reports created with an older BO build. You can’t use multiple BO
installations on the same computer without problems. Therefore the BO version update
will be a challenge for versioning.
________________________________________________________________________
29
DEVELOPMENT OF NEW SOLUTION MODELS_____________________________
5 Development of New Solution Models
This chapter describes the starting point for the study and points out the challenges
needed to be solved. The list of criteria for new solutions is given. After the base
information new solution models for the development processes and version management
are introduced. The challenging environment and boundary conditions introduced in
previous chapters and set by the predefined criteria (see 5.2) were taken into account
when designing these new models.
The launch of a new software tool to assist development and versioning has been the base
for the development and set also some restrictions for the new models. With this new
software tool also practical aspects are more easily explained and concrete results for the
thesis could be given.
5.1 Starting Point of the Environment
Before the whole study process started the environment was optimized for a smaller scale
of development and the technology packages were somewhat customized to suit the
customer needs.
The growing customer base and visions of the general technology package universes with
customer objects implemented in a linked universe on top of the technology package
universe gave pace for the need of this study.
The development environment consisted of one Business Objects repository where both
the development and final versions were stored. Because the Business Objects software
doesn’t allow multiple versions of a component with the same name, the development
version was renamed with a test prefix to avoid overwriting the final production version
of the component.
________________________________________________________________________
30
The CVS repository was also used to store the production versions of the components
because the Business Objects tools are not able to restore a previous version from the
repository if necessary. Both the CVS and Business Objects lacked the ability to analyze
and compare the different versions of the components in an object level.
Universes were developed with customized objects for all customers because there was
no way to implement all of these customized objects in a general manner for all
customers. The usage of customer universes as linked universes on top of the standard
universe was not possible because the transfer of these linked universes between the
environments was not possible with a regular BO installation.
Reports were developed in huge packets where all of the reports needed to be accepted
before any of the reports were transferred to the end users. Since all of the reports were
implemented before any of them was acceptance tested, the errors found affected in many
cases more than one report.
5.2 Challenges and Criteria for Solution Models
The environment described above gave reasons for many changes. One of the most
important challenges was to find a way to manage Business Objects components
(universes and reports) more accurately and flexibly. Another challenge about the
development process was to evaluate the possibility to separate the standard product and
the customer related customized components.
Another issue that needed changes was the version management. All of the sources for
changes introduced in the previous chapter are important to consider and they play a very
crucial role in defining the general rules for versioning. The environment described in 5.1
had many version management issues that needed to be considered.
________________________________________________________________________
31
The solution models should be considered from the point of view of different
stakeholders. For the customer product reliability and seamless update procedures are key
issues. Sales and management teams are interested in keeping the product profitable and
defining sales methods and prices for different types of updates and implementations. The
CTO as being the head of the technical aspects needs to know technical issues concerning
development and versioning. The change manager has the same kind of interests as the
CTO. And as last but not least, the development team needs to know the exact rules and
processes which to follow in order to fulfill the requirements of the development and
change management processes.
The solution models evaluated and defined in this thesis should be based on the
Enterprise Quality Manager tool. The following criteria were defined for the new
configuration management processes with the Enterprise Quality Manager Tool in use.
Customer aspects:
Criterion 1: Updates should not cause long interrupts to the end users
Criterion 2: The quality level should not fall
Management aspects:
Criterion 3: Updates should not cause extra costs. All existing reports should work.
Criterion 4: Prices for different types of version updates should be easily available.
Developer aspects:
Criterion 5: Versioning policy needs to be clear and easy to understand.
Criterion 6: The usage of the tool and component management should be simple.
Criterion 7: New methods should not dramatically slow down the development cycle.
Technical aspects:
Criterion 8: The new method should suit better than the existing one to the product
management.
Criterion 9: Technology packages should be easily monitored and mastered.
________________________________________________________________________
32
Criterion 10: There must be an easy way to restore the old versions of universes and
reports
5.3 Development Process for Product Components
The universe development process reminds in many aspects the waterfall model
described in chapter 3. Specifications are quite stable since customers use the network
vendor specific universes. In most cases modifications into the universes are easily
adopted even in later phases. Customers that have seen one universe know what to expect
from another and on the other hand customers are usually familiar with the network
vendor specifications. Therefore it seems that waterfall model suits quite well with the
universe development process. This same product development model is used also with
technology roll out reports and verification reports which are part of the general product.
5.3.1 Feasibility Study and Specification phase
Before the development can begin the requirements need to be summarized and selected
and detailed specifications need to be written. Since the requirements in this case are
coming from the network element vendors and not directly from the customers, the input
for the specifications can be regarded as stable. The only thing that needs to be decided is
whether the vendor release is significant enough to be supported and what busy hours are
supported for different measurement types. All this information is written into a
technology package specification document with other information related to that specific
technology package.
Also, in this phase proposals for new features coming from the customers and the R&D
team are analyzed and if accepted, they are also added into the technology package
specification document.
________________________________________________________________________
33
5.3.2 Design phase
The design of the universes is maintained as simple as possible. Same general modules
are used with every new universe and universes are upgraded on top of the previous one
if the modifications are structurally minor. The design phase has real importance for
example when new network topology dimensions are implemented and when the R&D
has developed a new feature to increase the performance.
5.3.3 Development phase
Universe implementation is quite straight forward after the specifications and the design
documentations are written. A universe contains measurement types and counters as
specified in the specifications. The actual coding is only a minor part of the universe
implementation since the universes are created by the Business Objects Designer tool.
The coding basically includes inserting the SQL select clause for measurement and
dimension objects and the SQL where clause for condition objects. Minor modifications
to specification documentation during the implementation phase are not a problem since
the objects are not tightly coupled and in most cases a change in one object doesn’t have
an impact on the other objects.
5.3.4 Integration phase and testing
When implementing a new technology package universe the integration is easily done
because the only need is to place the universe into the repository with the correct database
connection. The upgrading of a previous universe version is a bit more challenging
integration since there are reports using the previous universe version which will start
using this new universe after it is placed into the repository with the same name. This
way it is necessary to ensure that all reports that worked with the old universe version
also work with the new one.
________________________________________________________________________
34
Testing and verification are conducted during the whole process. Documents are verified
and reviewed, the implementation is module tested by the developer during the
implementation and the system tested during the installation. Integration testing is
committed with a regression analysis where possible.
5.3.5 Maintenance
When a universe proceeds to the maintenance phase operators usually already have a hint
when they are expecting to launch a new vendor release for that technology package.
Sometimes bugs are found in a universe that is in the maintenance or some new
development proposals are discovered. These are analyzed and given a severity level.
According to this level some fixes are made instantly and some are made during the next
upgrade to that package.
5.4 Development Process for Customized Components
The highly structural waterfall model used with universes and other product components
doesn’t suit well with the development of customized reports. Reports are developed
according to customer requirements and in many cases customer expectations of the
required report can exceed the limits of the reporting tool in use. The use of prototyping
to see if a report meets the customer requirements is often necessary. The report
development process follows quite well the fountain model introduced in chapter 3 but
since it is done as consulting with changing and challenging environment some of the
principles of extreme programming (XP) are used whenever possible. The XP methods in
use are spikes, small releases, continuous integration, coding standard, the collective
ownership of reports and onsite customer whenever possible.
________________________________________________________________________
35
5.4.1 Feasibility Study and Specification phase
In the feasibility study phase of report development customer requirements are collected
and analyzed. Some of the required reports are normally ready for design while some
need further specification and some are rejected as being impossible to implement. The
sequence in which the reports are implemented is specified. Some of the reports are then
ready for implementation while the feasibility study and specification phase is iterated for
other reports.
If the customer needs specific items into the universe like KPIs or filters before some
reports can be implemented, they are specified and implemented into the linked customer
universe on top of the tech pack universe.
5.4.2 Design phase
Reports are implemented on top of a template or a previous report whenever possible.

This way the layout and report structure remain standard. When complex reports are
implemented where no template or previous report is available a new template is
designed. In this phase the usage of spikes can be a useful way to get acceptance for the
new design from the customer.
5.4.3 Development phase
The report development is handled as consulting in the customer site when the customer
is located near by. This enables the possibility of continuous feedback from the customer
and better access to live network performance data. When implementation in the
customer premises is not possible due to long distances, reports are implemented with test
data and then sent to the customer. Reports are developed in small releases to get them
faster to the customer for acceptance and also to production. Reports are customer
________________________________________________________________________
36
tailored products and need sometimes iterations to get all customer requirements
implemented as desired.
5.4.4 Integration phase and testing
Reports are rather independent modules that are only linked to one or more universes or
other data sources. Reports are published to repository when they are ready and they are
managed and linked to different users and user groups from there.
The report developer is responsible for the module testing report functionalities and
details. Because the developer can become blind for some errors reports are also system
tested in a higher level by someone else from the developing organization. When the
reports are ready from internal testing they are sent to the customer for acceptance
testing.
5.4.5 Maintenance
The maintenance phase of the reports is quite identical with the universe one. Reports are
quite often modified after the technology package universe has been upgraded since some
of the content might be changed or some new material is wanted in the report. Report
errors that are found during the maintenance phase are corrected individually according
to the support contract.
5.5 General Versioning principles
This section describes general rules for the universe and report versioning in different
situations. Universes and Reports while developed with different process models possess
and share still the same versioning principles. The launch of the new universe and report
versioning and management tool set some boundaries for versioning policies. The
________________________________________________________________________
37
Enterprise Quality Manager (EQM) general management tool developed by Noad
Business Intelligence offers three stage versioning. Rules for adopting these new
versioning stages in different situations are explained. The Concurrent Versioning System
(CVS) is also used as backup and a knowledge bank for different kinds of solution
models.
5.5.1 Platform changes
The first versioning number stands for the version number of the DC5000 system and is
updated as the release number of the DC5000 changes. This way, if the DC5000 release
number and version number are identical the report is tested and works with the DC5000
release in use.
5.5.2 Network vendor initiated versioning
The second versioning number reflects the network vendor’s release number. The
numbers are not necessarily the same and the versioning number starts from the first
implemented network element release being zero despite of its release number. When
new release update is implemented the second versioning number is raised.
5.5.3 Customer variation versioning
Because different customers have different needs and possibly different network element
versions with a variety of measurement types we need different versions of the same
network vendor version. These specific customer needs are for example KPIs and specific
filters. These modifications raise the third versioning number. The iterative development
of the reports also raises this third number. Reports inherit the first two version numbers
from the universe version they are built on.
________________________________________________________________________
38
5.5.4 Bug fix versioning
Because the EQM uses only three layers in version numbering we need to use the third
number also for bug fixes. This is not an ideal situation but something that needs to be
accepted before the linked universes are widely used to hold all the customer specific
objects.
5.6 Launch of a new management tool
When the requirements of the new development process and version control model were
evolving it became obvious that all of the requirements couldn’t be handled with the tools
used. The search for the new general management tool capable of conducting both
process and versioning constraints were started. The Enterprise Quality Manager (EQM)
software tool was selected because it had all the needed features to handle the
requirements plus some extra quality control tools. Another reason for selecting the EQM
was that it’s tightly coupled to the Business Objects environment we were using for
reporting and universe development.
5.6.1 What benefits came with the new tool
The launch of the EQM system generated some changes to the existing environment as
well as brought a bunch of new features to help the development and management
processes. The most important ones are described here.
5.6.1.1 Environment changes
In a common Business Objects installation there is only one repository for reports and
universes functioning in the most cases as the production environment if located in the
________________________________________________________________________
39
customer premises. More repositories could be installed beside for development etc but
management and report transfer between these environments is difficult.
The EQM system expects that there are either three or four environments (development,
acceptance, production and testing that is optional). With the EQM the contents of these
repositories are easily seen with one user interface and reports and universes can be
transferred simply by the drag and drop method.
This addition of repositories brought a little more work for the user account maintenance
but simplified the acceptance process since the reports and universes were no longer
renamed as test components for testing to prevent overwriting the production objects.
The EQM needed also repository of its own to store the information of reports and
universes and their details. It also uses empty repositories called Transfer areas to move
reports between the EQM and the Business objects repositories. [Noa04]
5.6.1.2 Features
The EQM has a Graphical User Interface (GUI) which enables a smooth way of seeing
what universes and reports are in different environments and what their version history is.
The EQM version numbering consists of three stages (major, minor and revision) to cope
with the changes. The configuration management process is based on a check in – check
out model where the user locks the component for modification. The timestamp and the
username can be found in the user interface in case other users need the same components
for modification. When the components are locked they are still available as read only
copies. With the EQM it is also easy to restore a previous version if the new one is found
buggy.
________________________________________________________________________
40
Figure 13: The EQM User Interface [EQM04]
The EQM system uses the Business Objects data models to split the universes and reports
to the smallest pieces available and to store the information available into the EQM’s
own repository. This detailed information can be used for quality assurance to see what
modifications have been made to a report or a universe compared to a previous version or
to see which reports are affected if some universe objects have been modified. [Noa04]
Linked universes are a Business Objects feature that enables to split the universe into the
product and the customer parts. Although it is a Business Objects feature the transfer
between multiple environments is not supported and problems occur in many cases. With
the EQM these transfers can be done and the power of the linked universes is available.
5.6.2 How is EQM launched?
The launch of the EQM needs many preparations for the environment. A database must
be setup and new Business Objects repositories need to be installed with the correct user
________________________________________________________________________
41
accounts. When the infrastructure is ready the EQM software package can be extracted.
After the installation many configurations are needed to build the EQM repository and
make the access to all transfer areas and BO repositories available.
Then all existing universes and reports need to be imported into the EQM system to get
them under version management and general EQM object management. Because the
EQM fragments the universes and reports it takes a lot longer to import them than it takes
when only Business Objects is used. Another wearisome task is that all the production
reports need to be transferred through the whole EQM chain from development to the
production environment and possibly via both acceptance and testing environments.
[Noa04]
5.6.3 How EQM works?
The basic idea is that all universes and reports should be under EQM management and
published only through the EQM. This way EQM’s change management tools will give
the correct results about object coupling for example and the version management history
is accurate and up to date. In order to accomplish this user rights in the Business Objects
environment were limited to prevent publishing of components.
The EQM contains user accounts and account management of its own. User rights are
given as environment basis. Administrators, developers and testers are the common users
of the EQM. From the end users point of view the EQM is transparent since they don’t
use the EQM to access the components but the Business Objects or web portal like the
DC5000.
The production chain will become standardized with the EQM since it almost forces users
to follow the same flow model described in figure 14. [Noa04]
________________________________________________________________________
42
Figure 14: The EQM Work Flow [Noa04]
5.7 Case Nokia EDGE update
With this case project the new process model and versioning tool are explained from the
practical point of view. When Nokia upgraded its BSC network element’s software
version to cope with the EDGE technology, it was obvious that operators would like their
network and network performance management tool to support this new technology as
soon as possible.
________________________________________________________________________
43
5.7.1 Sources for universe upgrade
The base source for the whole upgrade project came from the network vendor. The
Nokia’s database description specification presents the list of measurements available
with this new version.
The R&D team designed also the structure for handling the new topology items
introduced.
5.7.1.1 Universe changes
With the release 10 of Nokia’s BSC element, 8 new measurement types were added into
the universe with their counters. These counters were given the basis for the SQL
handling and description from the specifications. Additional topology tables were also
added and joined with the measurement tables.
In release number 10 there were two new EDGE related measurement types: 76 (dynamic
Abis pool) and 79 (EGRPS coding scheme) with their counters. All of these
measurements were smoothly included into the former universe version since all the
modifications were only additions in to the universe.
5.7.2 Sources for report upgrade
After the new universe version was developed and in the production, the customer started
to specify modifications for old reports to handle the EGPRS and some completely new
reports. The customer specifications also included plenty of new KPIs to be added into
the universe. Some of the KPIs had such complex formulas that the R&D needed to
design new methods for the data management to handle them.
________________________________________________________________________
44
5.7.2.1 Report changes
Before the changes in the report could be implemented the universe needed to be updated
to include the new KPIs and other changes from the specifications. When the universe
was ready the modifications in the report were started. The old reports were modified to
include the new EDGE counters and KPIs and then renamed to better describe the new
contents. These reports were sent for customer acceptance before the implementation of
the new reports was started.
The new reports were then implemented using the old reports and report templates as
basis so that the design remained standard. When these new reports were ready they were
also sent to the customer for acceptance.
5.7.3 Versioning of components
When the universe upgrade was implemented for the Nokia’s BSC technology package
the universe’s second versioning digit was heightened by one as the modification was
structural and initiated by the network vendor. The developed universe was then checked
in to the EQM and transferred to the acceptance environment for testing. After the
customer had tested the universe it was transferred to the production environment.
When the report update project was initiated the universe needed the update for the
topology and the new KPIs. The universe was checked out and modified. This
modification raised the third versioning number since it had been initiated either by the
R&D or customer.
Reports were modified as specified in the documentation. They were given the same
updated second versioning number as the universe they were built on had. The report’s
third versioning number was thereafter updated with every iteration cycle.
________________________________________________________________________
45
ANALYSIS OF THE RESULTS_____________________________________________
6 Analysis of the Results
This chapter analyzes how well the objectives and criteria set in the previous chapters
were met. The Enterprise Quality Manager tool was evaluated and launched according to
the objective of the thesis. The results of the evaluation with other user experiences are
analyzed. The description of the new process models was also conducted. The processes
are analyzed separately against the requirements and criteria.
6.1 Did EQM Meet the Expectations Set for it?
High expectations were set for the EQM since it was a truly Business Objects related tool
and said to be capable of handling many of the challenges we faced with installations
where only Business Objects was in use. The integrated version management and the
separation of development and production environments were key aspects when selecting
the EQM for further evaluation and installation.
6.1.1 Easiness of Installation
The EQM software was easily unpacked and installed. The start up configuration, setting
up all the repositories and transfer areas as well as the connections for them was more
troublesome and needed much more manual configuration than the ordinary BO
installation. Fortunately, this start up configuration needs to be done only once and the
normal client installation is much simpler.
The EQM as being only an interface between the developer and the Business Objects
environment has quite a lot to configure. This installation process could be much easier
and more automated. As it includes a lot of manual configuration it is error prone and
________________________________________________________________________
46
while the EQM has its own error analyzer, there still might be errors left that are hard to
find.
6.1.2 User Friendliness of the EQM
As the EQM is a Windows-based software tool it has similar “look and feel” interface as
many other Windows based tools which helps users to get familiar with it. EQM has so
many dimensions that some users have found it difficult to use while other praise it as
very good way of visualizing and managing everything.
In the EQM, the GUI can be used to visualize one or many environments simultaneously
in the same window; this brings easiness to managing the multiple environments. The
transfer of documents between environments is also much easier with the EQM than with
only the BO in use.
The workflow model described in figure 14 of section 5.6 is quite general in nature and
therefore easily adopted. The EQM forces users to follow this model which ensures that
the process is used by everyone. While the EQM forces to use this workflow it doesn’t
hide the illegal commands for different states. Therefore users not very familiar with the
workflow try to use commands that are not possible due to the state like using transfer for
a report that is with ready status. The end user is prompted for en error message while it
would be much more user friendly to hide the commands that are not available.
Figure 15: All Commands Visible [EQM04]
________________________________________________________________________
47
The EQM forces to use three or four environments (development, [testing], acceptance
and production) while in some cases two or even one environment would be enough. This
enforces the customers that are not doing their own development, still setup and maintain
the unnecessary environments. On the other hand, the separation of the development,
acceptance and production environments is almost a necessity for customers with regular
development of their own going on to avoid unwanted situations.
The EQM has also fixed version numbering. This three level numbering could be the best
for most cases but in some cases an additional fourth level could be justified. As the new
versioning model was described in chapter 5 the usage of a third versioning number for
both the customer specific versioning and the bug fixes became evident even though it is
not an ideal situation.
The publishing process for documents is rather slow with the EQM. This is partly due to
the fractioning of the documents to the object level before storing them into the EQM
repository. Another thing that slows the process down is the fact that the report needs to
be published simultaneously into two places, the EQM and the BO repositories. The
difference in publishing time for one environment between EQM and BO is great since
the publishing with only BO is almost 5-10 times faster.
The EQM has also trouble with publishing and transferring reports in batches. The
publishing process is interrupted constantly and report categories are not easily changed.
Another weakness of the EQM is that it slows down the whole computer during the
publishing. Many applications like Microsoft Word and Business Objects cannot be used
when the EQM is active and sometimes the EQM even kills active Business Objects
sessions while doing document transfer between environments.
________________________________________________________________________
48
6.1.3 Usability of features
The EQM enables the usage of linked universes in the multi environment installation.
Without the EQM the linked universes can’t be transferred safely between development
and production environments. Linked universes which are a good way of separating
product components from the customer specific objects, were one of the main reasons for
selecting the EQM. The usage of linked universes is simple with the EQM and needs only
minor modifications to the development process.
As the EQM stores both universes and reports with object accuracy it is possible to get
detailed information about documents with the multiple analyze features of the EQM.
One of the most useful of these features is the Object impact analysis. It is a good way to
find the relation of universe objects and reports when certain universe objects need
modification. If an environment is divided into multiple domains this feature stops
working ideally.
Another beneficial feature is the difference analysis that can be run to compare universes
and reports. It is a good way of finding what has changed with every version
modification. The EQM’s version history is also a fast way to get information about who
has modified a document and when.
6.1.4 Summary of the EQM
The EQM contains the very features that we were looking for. It also gives a good
upgrade for the report and universe management and quality control. The version
management it offers is not ideal in all cases but simply better than the previous situation.
The usability and installation of the EQM could need a little improvement. As described
in detail the installation has many manual configurations that need to be done, which
________________________________________________________________________
49
contain a moderate chance for human errors. The usability and user friendliness had also
many shortcomings, some of which could easily be improved.
If the EQM is valued and compared to the criteria set in chapter 5, it clearly passes the
customer, management and technical criteria since they are quite feature-based in the case
of the EQM evaluation. The developer aspects on the other hand are more concerned
about the user friendliness. Criterion 5 is not so EQM-related since the EQM only gives
boundaries for the process that specifies the used policy. Therefore it could be considered
passed with notification that it is not ideal in all cases where 4-stage numbering would be
ideal.
Criterion 6 is not passed since developers and the EQM administrators that have tested
the system have given almost only negative responses about the usability and easiness.
The process flow of the EQM looks better on the paper than when the tool itself is used.
The fact that the EQM slows down the computer and could even kill processes is a big
weakness.
Criterion 7 is also not even closely met. The publishing process for one environment is
about 5-10 times slower and the same factor is used for other environments. Therefore
publishing reports into the production environment could take about 30 (40 if also testing
environment is used) times longer with the EQM than with one repository Business
Objects installation.
Overall the EQM is quite suitable for handling all the requirements it was planned to take
care for. The Usage is slower than expected and the need for configuration during the
installation is quite high. The usage of multiple BO environments and additional EQM
environments add a lot to the total maintenance work. The presence of the multiple
quality control features on the other hand help to save time when modifications are made.
Since the EQM is not a freeware, it is important to consider the benefits and weaknesses
also in business sense. Are the benefits greater than the lack of usability and extra costs
________________________________________________________________________
50
that it creates? The EQM could be a somewhat reasonable choice when the customer has
development of his own in addition to our product components. In the cases where the
customer uses only the product components the benefits are less evident and barely
greater than weaknesses.
6.2 New Development Process in Use
The new processes were developed to increase the productivity and quality of reports and
universes. The models were developed to be as generic as possible while the EQM set
some boundaries. The models are usable with or without the EQM. So that even if the
EQM would not become a success they could be used as a basis.
6.2.1 Product development process
The product development was adopted on top of the waterfall model since the
requirements and specifications were stable. The requirement for product development is
our own interest to support all the network vendor’s releases customers could be using or
willing to install. The specifications are written according to the network vendor’s
database descriptions and therefore are stable.
The universes and reports in the object level are relatively independent. Because of that it
is not troublesome to change something in the specifications and in the product even in
the late phases of the development process. Another good point about the waterfall model
is the fact that the documentation is kept up to date. Testing is also done during all of the
process phases to keep the quality high.
6.2.2 Customization process
The customization process encountered greater modifications than the product

development process. The need was also evident since the customization projects
________________________________________________________________________
51
encountered specification changes almost every time during the implementation and
integration phases. The previous model was not suitable for the situation where
specifications kept changing so much.
The new model handles the entities in smaller portions and uses prototyping to get the
customer feedback earlier. The projects are also estimated to finish earlier than with the
previous model because of these characters. Because the development is carried out
whenever possible in the customer premises or by using a VPN connection to get to the
live network data, the development is faster and easier. Testing can also be more easily
accomplished when the data is complete and real.
6.2.3 Summary of the Development Processes
The process models seem to be appropriate for the situations they were designed. The
product development process has been used successfully for multiple projects. The
requirements for this study didn’t set any distinguishing criteria for the product
development process. Partly this was due to the fact that the process was working well
before the study and the main purpose was to document the process.
The customization process encountered much more modifications. The new model has
not been used so widely that any indications could be analyzed about its suitability in real
projects. In the paper it seems fine and tackles the problems that we used to have.
Customers have also been quite positive about this new model and are looking forward
on testing it.
6.3 Suitability of the new Versioning Model
The new version management model is tightly related to the EQM and the boundaries
EQM sets. The model is though rather easily modified for the case of other version
________________________________________________________________________
52
management tools in use. The study identified and categorized quite well the sources for
the changes that apply for reports and universes. The study works as a good basis for
further development of the version management.
6.3.1 Summary of the Versioning Model
The basic requirement was to identify and describe the needs for version management
and to generate a model that could be tested with the EQM launch. The version
management policy became tolerably clear. The restriction to categorize the versioning
with three numbers led to the problem of reporting bug fixes and customization revisions
with the same versioning digit. This could be misleading and confusing at some level but
no better solution could be found. Therefore the only criterion that is tightly related to
this model is criterion 5 and it could be considered to be passed. It could be estimated that
the generic model is fairly clear. And because the EQM allows version description to be
input, the level of possible misunderstanding is actually lower.
________________________________________________________________________
53
CONCLUSION___________________________________________________________
7 Conclusion
Distocraft’s configuration management of reporting components was getting all the time
harder as the customer base was growing. The variety of mobile network elements that
were modeled was also growing since they were dependent on the network vendor and
the element version. Therefore sources for changes were getting harder to manage
without proper tools. The need for a more product dedicated solution was under
investigation. The development processes for these components also needed to be
reviewed and described to suit this new situation.
This study was required to analyze the suitability of the EQM general management tool
to handle these configuration management issues. The development processes were to be
modified to cope with this new situation and usage of the EQM. The versioning policy
was also defined to fit into the requirements the EQM set for it. A set of criteria were
defined for different stakeholders as requirements for the EQM and the new processes.
The basis for the solution set was the evaluation and testing of the EQM tool both
internally and with the customers. This gave a good insight of how capable the tool was
and how the opinions of separate stakeholders differed. The EQM analysis gave basis for
defining new process models and versioning principles. It also set some boundaries and
restrictions for the solution. The present state of the development processes and
versioning was then analyzed to identify the benefits and weaknesses of them.
The present state of the product component development was found to be in good shape
and it was modified only slightly to better take in to account the benefits EQM allowed.
The customization process was then developed to be more of a consulting type of action
conducted in the customer premises or at least with a connection to the customer’s
network data. The versioning of components was modified greatly when the usage of the
CVS was replaced with the version management the EQM offered. The EQM offered a
more comprehensive and detailed way of storing versions. The version numbering was
________________________________________________________________________
54
CONCLUSION___________________________________________________________
fixed with the EQM to three stages (major, minor and revision) compared to the two
stages used with the CVS.
The EQM scatters the components into factors before storing them into the repository.
This enables many good features for component configuration management. The different
versions can be compared on the object level and when changes are coming, the EQM
can be used to track which components are using the objects that are to be modified. The
overall manageability of components was greatly enhanced with the EQM’s GUI that
could be used to see the contents of all environments concurrently.
The EQM evaluation was productive. It gave some good and some unexpected results.
The features it supports worked fine and were evaluated to be fairly important when
considering the future state of the products. The user friendliness on the other hand turned
out to contain issues that were poorly done. This led to the fact that the EQM was praised
by the management of both internally and by the customer and criticized by the
developers. At least some of the issues that concerned the user friendliness could be fixed
in the future versions of the EQM but some decisions needed to be made by current
knowledge. Therefore it was hard to compare the benefits and weaknesses.
The new development processes seemed to be fine. The product development process has
been tested already by multiple projects with a positive response. The customization
process as being fresher has not been tested so widely but the first comments were quite
favorable. The new version management process added visibility and distinctness to the
principles. It is clearly better than the former model but still some issues were left.
7.1 Recommendations for future studies
The EQM has some issues that should be estimated and if they are too great compared to
benefits, replacement of the EQM with other management tool should be considered. The
________________________________________________________________________
55
CONCLUSION___________________________________________________________
Noad Business Intelligence is helpful and eager to receive user response. Therefore they
should be consulted for the fixes for issues found in the user friendliness.
The use of the EQM as part of the product needs to be appraised since some of the
customers might not be willing to invest in it if they feel that they don’t get enough value
for their money.
________________________________________________________________________
56
REFERENCES___________________________________________________________
References
[App98] Branching Patterns for Parallel Software Development

http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
Brad Appleton, Stephen P. Berczuk, Ralph Cabrera, Robert Orenstein,
1998, Referred 03.01.2005
[Bir04] Cellular/PCS Network Architecture

http://engr.smu.edu/~ebird/Handouts/
EETS8306_Lecture5_NetworkArchitecture_2004_RevA.pdf
Eric Bird, 2004, Referred 3.12.2004
[Bus03] Business Objects User’s Guide

Business Objects 5.1.7, 2003
[Des03] Designer’s Guide

Business Objects 5.1.7, 2003
[Dis04] DC5000 Product Description

Distocraft Oy, 2004
[EQM04] Screen captures from Enterprise Quality Manager 3.1

Noad Business Intelligence, 2004
[Gar99] Principles and Applications of GSM

Vijay K Gard., Joseph E. Wilkes
Prentice Hall PTR, 1999, ISBN 0-13-949124-4
[Hal92] Televiestintäjärjestelmät
Seppo J. Halme
Otatieto Oy, 1992, 6ed, ISBN 951-672-325-X
________________________________________________________________________
57
REFERENCES___________________________________________________________
[Hal02] GSM, GPRS and EDGE Performance: Evolution towards 3G/UMTS

Timo Halonen, Javier Romero and Juan Melero
John Wiley & Sons, Ltd 2002, ISBN 0470 84457 4
[Häm01] GPRS, Langattomasti tietoverkkoihin

http://www.klinkmann.com/miscellaneous/SoneraKlinkmannSem/pdf2/So
nera.pdf
Kalle Hämäläinen, 2001, Referred 23.11.2004
[Jam03] The Wireless Mobile Internet, architectures, protocols and services

Abbas Jamalipour
John Wiley & Sons Ltd, 2003, ISBN 0-470-84468-X
[Jef01] Extreme Programming Installed

Ron Jeffries, Ann Anderson, Chet Hendrickson
Addison-Wesley , 2001 ISBN 201-70842-6
[Kel02] Mobile Communication, GSM, GPRS, EDGE, UMTS and Beyond

http://www.ibr.cs.tu-bs.de/events/SummerSchool2002/kss-keller.pdf
Ralf Keller, 2002, Referred 23.11.2004
[Koj04] Software Configuration Management

http://www.soberit.hut.fi/T-86/T-86.141/2004/SCM_ESI_Tero.pdf
Tero Kojo, 2004, Referred 4.1.2005
[Kor04] GSM+GPRS
http://www.comlab.hut.fi/opetus/423/lect2004/05_423gsm.pdf
Timo O. Korhonen, 2004, Referred 1.12.2004
________________________________________________________________________
58
REFERENCES___________________________________________________________
[Kos98] GSM Service Evolution towards Universal Mobile Telecommunications
syste
Jussi Koski
Helsinki University of Technology, Master’s Thesis, 1998
[Lai05] Distocraft Telecom training

Jussi Laimio, 2005
[Mou92] The GSM system for mobile communications

Michel Mouly, Marie-Bernadette Pautet
Published by the authors, 1992, ISBN 2-9507190-0-7
[Mul02] Desktop Encyclopedia of Telecommunications

Nathan J. Mullen
McGraw –Hill Ltd, 2002, 3ed ISBN 0-07-138148-1
[Noa04] EQM Training Material

Noad Business Intelligence, 2004
[Nok02] NDW Database Description for BSC Measurements

Nokia Networks Oy
[Pen02] GPRS in Wireless Data

Jyrki Penttinen
Werner Söderström Oy 2002, ISBN 951-0-26564-0
[Sch02] Object Oriented and Classical Software Engineering

Stephen R. Schach
McGraw – Hill Ltd, 2002, 5ed, ISBN 0-07-239559-1
________________________________________________________________________
59
REFERENCES___________________________________________________________
[Seu03] EDGE for Mobile Internet
Emmanuel Seurre, Patrick Savelli, Pierre- Jean Pietri
Artech House, 2003, ISBN 1-58053-597-6
[Som96] Software Engineering

Ian Sommerville
Addison-Wesley publisher Ltd, 1996, 5ed, ISBN 0-201-42765-6
[Stu03] The GSM Evolution, mobile data services

Peter Stuckmann
John Wiley & Sons Ltd, 2003, ISBN 0-470-84855-3
[Vit95] Ohjelmistotuotteiden tuotteistaminen

Katriina Vitikainen
Lappeenranta University of Technology, Master’s Thesis, 1995
[Voi00] Tietoliikenne aapinen

Kirsi Voipio, Seppo Uusitupa
Otatieto Oy, 2000, 3ed, ISBN 951-672-305-5
[Whi91] Methods and Tools for Software Configuration Management

David Whitgift
John Wiley & Sons Ltd, 1991, ISBN 0471929409
[XP00] Extreme Programming home pages

http://www.extremeprogramming.org
Don Wells, 2000, referred 10.1.2005
________________________________________________________________________
60

Vaisanen MGMT

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Vaisanen MGMT

Diunggah oleh

Hak Cipta:

Format Tersedia

Master’s Thesis

HELSINKI UNIVERSITY OF TECHNOLOGY

Configuration Management for Performance Reporting in

Supervisor: Professor Antti Ylä-Jääski

Instructor: M. Sc. Esa Nyman

Date: 18.04.2005 Number of Pages: 60

Department: Department of Electrical and Communications Engineering

Supervisor: Professor Antti Ylä-Jääski

Software configuration management is a core part of the whole software

Key words: change management, mobile network, performance management,

Päivämäärä: 18.04.2005 Sivumäärä: 60

Osasto: Sähkö- ja Tietoliikennetekniikka

Työn valvoja: Professori Antti Ylä-Jääski

Ohjelmistojen konfiguraationhallinta luo perustan koko ohjelmistokehitykselle.

Matkapuhelinverkot ovat jatkuvasti muutoksen kohteena. Verkkovalmistajat

Tämän diplomityön puitteissa on evaluoitu olemassa olevia kehitysprosesseja sekä

Työ käsittelee matkapuhelinverkkoja yleisellä tasolla. Tämän avulla selviää

Työn tuloksena esitellään datamallinnuksen ja raportoinnin kehitysprosessit ja

Avainsanat: Muutokset, matkapuhelinverkko, suorituskykymittaus, versiohallinta,

I wish to present my gratitude to my supervisor, Professor Antti Ylä-Jääski for his

In Espoo, Finland on April 18, 2005

3 SOFTWARE DEVELOPMENT AND MANAGEMENT .................................. 14

4 NETWORK PERFORMANCE REPORTING SYSTEM AND ITS

5 DEVELOPMENT OF NEW SOLUTION MODELS.......................................... 30

6 ANALYSIS OF THE RESULTS ........................................................................... 46

Figure 1: Second Generation GSM Evolution [Kel02]....................................................... 5

0.3 GMSK 0.3 Gaussian Module Shift Keying

The mobile telecommunications is another rapidly changing field of technology. From

Distocraft Ltd. is a developer of network performance management and quality assurance

1.1 Scope definition

1.2 Problem setting

1.3 Structure of the study

2.1 Network Evolution

Figure 1: Second Generation GSM Evolution [Kel02]

Figure 2: Topology of the GSM Phase 1 Network [Kor04]

Figure 3: GPRS Network Architecture [Bir04]

2.1.1 What changed with EDGE update?

2.2 Mobile Network architecture

Figure 4: 2G Mobile Network Architecture [Häm01]

2.2.3 Packet Core Network

2.3 Network Measurements

2.3.1 EGPRS related measurement types

2.4 Network planning and optimization

2.4.1 Key Performance Indicators and EDGE

Key Performance Indicator (KPI) is an important counter or combination of multiple

The EDGE introduced categorization of 9 channel coding schemes compared to the 4

3 Software development and management

Definition and usage of both software development and configuration management

3.1 Software development

3.1.1 Software product development process

3.1.1.1 Waterfall model

Figure 5: Waterfall Model [Sch02]

3.1.1.2 Waterfall model phases

3.1.1.3 Analysis and critics on the waterfall model

3.1.2 Process for customization

3.1.2.1 Fountain Model

Figure 6: Fountain Model [Sch02]

3.1.2.2 Analysis and criticism of the Fountain model

3.1.2.3 Extreme programming

Figure 7: Extreme Programming Life Cycle [XP00]

3.2 Software configuration management

3.2.1 Version management