Master’s Thesis - TKK - · PDF file · 2006-02-142.2.1 BSS ... Topology of...

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

Telecommunication Networks

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

Telecommunication Networks

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


Raw data

Aggregateddata

2G 3G 4G2.5GFixed/BB 2G 3G 4G2.5GFixed/BB

NetworkData

Management

PM, CM, FM, SM Data

NetworkData

Modelling

Network Data

Gateways

NetworkData

Visualisation

DC5000Platform

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


RAWRAW AGGRAGGRRaw Data Aggregated

Data

Universe

Reports /Universe Access

REFREF

ReferenceData

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

Master’s Thesis - TKK - · PDF file · 2006-02-142.2.1 BSS ... Topology of...

Documents

Transcript of Master’s Thesis - TKK - · PDF file · 2006-02-142.2.1 BSS ... Topology of...