You are on page 1of 70

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

2005 Sivumäärä: 60 Osasto: Sähkö.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. kehitysprosessi . Tämän työkalun avulla oli tarkoitus voittaa olemassa olevia haasteita. Samanaikaisesti tekniikan kanssa verkon suunnittelu ja optimointi monimutkaistuvat.04. Verkkosuunnittelijoilla on selkeä tarve ajantasalla olevalle verkon suorituskyky.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. Työn tuloksena esitellään datamallinnuksen ja raportoinnin kehitysprosessit ja ratkaisumalli versiohallinnaksi. Verkkovalmistajat päivittävät verkkoelementtien ohjelmistoja ja operaattorit muuttavat verkon topologiaa paremmin käyttöastetta vastaavaksi. suorituskykymittaus. Tämän avulla selviää verkonsuorituskykymittauksissa käytettyjen mittareiden tausta.mittausjärjestelmälle. Tarvitaan määrämuotoisia keinoja ohjelmistopäivitysten tekemiseen samalla tavalla kerta toisensa jälkeen. Tämän diplomityön puitteissa on evaluoitu olemassa olevia kehitysprosesseja sekä versionhallintaa. Työ käsittelee matkapuhelinverkkoja yleisellä tasolla. joka käyttäisi hyväkseen uutta hallintatyökalua. sekä verkosta johtuvien järjestelmään kohdistuvien muutostarpeiden määrä. versiohallinta. matkapuhelinverkko. Tavoitteena oli suunnitella ja toteuttaa uusi konfiguraationhallinta- malli. Avainsanat: Muutokset. Uusien teknisten parannuksien myötä tulee sekä päivityksiä olemassa oleviin elementteihin. Verkkojen asiakaskohtaiset erot voivat myös olla suuria. Ohjelmistokehitysprosessit ja versionhallintamallit ovat olennainen osa ohjelmistojen konfiguraationhallintaa. että uusia verkkoelementtejä. Matkapuhelinverkot ovat jatkuvasti muutoksen kohteena. Tämän lisäksi analysoidaan uuden työkalun tuomia hyötyjä ongelmien ratkaisemiseksi.

Professor Antti Ylä-Jääski for his advices on structuring and writing this thesis. Finland I wish to present my gratitude to my supervisor. 2005 Juha Väisänen . I would also like to thank my instructor M. His comments helped a lot during the start up and finishing of the project. I thank my lovely wife for her support and patience during my studies. Many thanks for also other colleagues at Distocraft for the support during the project and making this thesis possible. Finland on April 18. In Espoo. Last but not least.Acknowledgements This Master’s Thesis has been done for Distocraft Ltd in Helsinki. His visions about the subject of the thesis have been valuable. Esa Nyman for the numerous advises during the process. Sc.

........................... 29 5 DEVELOPMENT OF NEW SOLUTION MODELS...........4 Third party software updates .1 SOFTWARE DEVELOPMENT .........................................2.................................... 11 2................. 13 2.......................3 Product updates................................................................................................................... 27 4...... 13 3 SOFTWARE DEVELOPMENT AND MANAGEMENT ........1............................................................................................................................................2......................................................................... 4 2....1 Universes........ 28 4...................................................................... 14 3....................... 12 2.............................. 20 3.........................................................................2 VERSION AND CHANGE MANAGEMENT ..... 31 5........................................4................3 STRUCTURE OF THE STUDY .......................................................................................................................... 24 4...............................2 NSS .......1 Network updates ....2 Process for customization ................. INTRODUCTION............................................................................................................................................................................ 24 4........................................1 NETWORK EVOLUTION..........1 BSS ...................................................................... 7 2................................................................. 14 3...2 PROBLEM SETTING ...................1......... 10 2................. 7 2....4 NETWORK PLANNING AND OPTIMIZATION ..... 3 2 NETWORK ........... 14 3.......................... 9 2............................................................................3 Packet Core Network .............1........2 MOBILE NETWORK ARCHITECTURE.................................2 SOFTWARE CONFIGURATION MANAGEMENT.........................................................2..... 2 1............................2 Reports .....................4 OSS ....................................1 EGPRS related measurement types ................................................................................................ 28 4.1 What changed with EDGE update? ............................1.......... 29 4.......................... 21 4 NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING.............2 Operator initiated updates ............. 29 4.....................1 Version management . 33 ...1 STARTING POINT OF THE ENVIRONMENT.........................3 NETWORK MEASUREMENTS ................................................................................................... 25 4.......... 30 5.......................2.2........2............ 1 1......................................................................................................................................2.........................................................................................1 GENERAL OVERVIEW ....................................................................................1 SCOPE DEFINITION . 2 1........................1 Key Performance Indicators and EDGE .........................3........................................3 DEVELOPMENT PROCESS FOR PRODUCT COMPONENTS ..................1....TABLE OF CONTENTS 1...............................2 CHALLENGES AND CRITERIA FOR SOLUTION MODELS ....................................................................1 Software product development process . 30 5.........................2........... 11 2........ 9 2........ 17 3.2......................................................... 4 2............................................

.................................................. 54 7................................................................................7...............................5............................................3 How EQM works? ........2.........................................5 Maintenance.2 Design phase ............7.1 Summary of the Versioning Model................................ 39 5........... 55 .............2 Design phase ........1 Sources for universe upgrade.......7..........2 User Friendliness of the EQM ................................ 35 5..........................................................5................. 39 5...1 Easiness of Installation ................................................................... 37 5.......................................................... 36 5...........5 Maintenance......................5............................1 What benefits came with the new tool.................................................................. 44 5.................4..... 53 7 CONCLUSION .............................6 LAUNCH OF A NEW MANAGEMENT TOOL ...........1 RECOMMENDATIONS FOR FUTURE STUDIES . 35 5..........3 Versioning of components ....................................................................................................4........ 42 5.. 51 6........... 41 5...6............. 38 5.........4 Integration phase and testing ................................... 46 6....................1...2 How is EQM launched? ....................................1 DID EQM MEET THE EXPECTATIONS SET FOR IT? ...... 39 5......................... 38 5..........2.................... 36 5.......................3 Development phase...............................................................3 Summary of the Development Processes.... 51 6...................................................................................................................4.......3......................................4.........1 Feasibility Study and Specification phase ...3...............................................3 Usability of features..........2............................. 34 5................ 46 6...............................4 DEVELOPMENT PROCESS FOR CUSTOMIZED COMPONENTS .............................................3.................................................1 Product development process ......... 52 6..................4...................................4 Summary of the EQM............ 49 6..................2 Customization process ....................................... 47 6.............................................................................................................4 Integration phase and testing ............ 51 6. 33 5......................................................................................1 Platform changes......................1..............................................3 SUITABILITY OF THE NEW VERSIONING MODEL ........................ 36 5............................................1.3......... 52 6.......2 NEW DEVELOPMENT PROCESS IN USE .......................3 Customer variation versioning................................6.............................................1.............. 45 6 ANALYSIS OF THE RESULTS ...........2 Network vendor initiated versioning ................................. 44 5.....7 CASE NOKIA EDGE UPDATE.....2 Sources for report upgrade.................. 43 5............6........................................5 GENERAL VERSIONING PRINCIPLES ............... 5.......................... 34 5..................... 37 5..................................................................................... 49 6............................. 46 6............................................ 34 5.............................. 37 5...................................5..3 Development phase................ 38 5...........................................................3........3............................1 Feasibility Study and Specification phase ..................................4 Bug fix versioning........

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

3 GMSK 0.LIST OF ABBREVIATIONS 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 .

As the product and customer base have grown. The variety of network element vendors is wide and all of them support call handling and maintenance differently.INTRODUCTION________________________________________________________ 1. This thesis describes the evaluation and implementation of the new software development process for the Distocraft DC5000 product. Introduction Software development is a rather new field of science and is therefore still evolving quite often. so models need to be adjusted to suit the project type at hand. New solutions need to be tested and improved all the time to be on the edge of the development. Mobile user rates have exploded to compete for the number one spot of the telecommunications channels. The main part of the ________________________________________________________________________ 1 . The growth in the users has developed needs for various new application areas that could not be even dreamed of a decade ago. There exists no ideal project. Therefore it is no surprise. that many companies constantly redesign their development process to be more efficient. All the process models and guide lines that are available are ideal visions of what could suit for an ideal project. New version management policies were also developed hand in hand with the development process renewal. From the early days of the mobile networks the pace has only become faster. As the mobile networks have evolved towards more complexity. Optimization of one element could not work similarly with another vendor’s same element. Distocraft loads performance and event data from the network and models it for the operator’s end users. is a developer of network performance management and quality assurance software. Distocraft Ltd. Distocraft has faced the pressure to adopt a formally accepted process model for development and version management. The mobile telecommunications is another rapidly changing field of technology. In many countries mobile users have already bypassed the user rate of fixed line telephone users. the challenges of network operators for designing efficient and cost benefit networks have become harder.

1 Scope definition The study concentrates on the end user side of the Distocraft DC5000 product. 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. ________________________________________________________________________ 2 . giving other parts of the product minor attention.2 Problem setting The objective of this thesis is to evaluate the software development process and version management process of the Distocraft DC5000 system. Other process models were evaluated but are introduced here only briefly.INTRODUCTION________________________________________________________ practical case was to evaluate the suitability of new management tool for the Distocraft DC5000 product component management. The same principle was used with the software configuration management with focus only on version management. 1. The use of the Enterprise Quality Manager (EQM) software tool to accomplish this task is evaluated and tested with a case project. 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. The new process model and the versioning principles were designed to be suitable whether or not the new management tool was used. 1. 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 solution models are introduced and the implementation description is given with a practical example. Finally. 1. After the background information the starting point for the thesis is summarized and criteria for the solution models are given. After these chapters the focus is turned to the network performance management systems and their challenges.INTRODUCTION________________________________________________________ Results of this thesis can be used in improving further the development process since it summarizes the factors generating changes in the system. The Distocraft DC5000 network performance management product is introduced deeper as the whole thesis is implemented for it. ________________________________________________________________________ 3 . It is also useful in the evaluation of the need for launching the EQM in a larger scale. Some research issues for the future are also given.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 solution models and their implementation are analyzed against the set criteria and user experience. the thesis is concluded with the summary of the main objectives and results. 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 that the second generation network elements are introduced more thoroughly and network element measurements are described. [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. Working with these measurements to ease network development and optimization process is explained briefly for the new EDGE measurements. although the success story of the SMS did not happen until many years later. The SMS (Short Message Service) was also introduced with the GSM version 1. This changed the partly analog NMT network to an all digital GSM network.NETWORK______________________________________________________________ 2 Network This chapter familiarizes reader to the ETSI GSM network by first summarizing the evolution of the network technologies. The first GSM data services were launched around 1994. 2.6 kbps.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. [Pen02][Gar99] ________________________________________________________________________ 4 . As for the whole thesis the main focus area is kept on the GPRS/EDGE technologies. data transfer capabilities were limited and had slow bit rates and terminals were big or even huge. when data transfer rates were very slow with maximum of 9.

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 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 . The huge interest towards GSM and rapidly growing usage developed needs for new service areas and better data rates. The GSM was specified for voice traffic only with restricted data transfer capabilities.

NETWORK______________________________________________________________ This HSCSD enabled circuit switched data transfer for theoretical maximum of 56 kbps. [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. theoretical data transfer maximum was increased to almost 170kbps although this is rarely achieved because of terminal and network restrictions. 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 . Circuit switched connection was not an optimal solution for data traffic because of its bursty nature. The General Packet Radio Service (GPRS) technology was developed to tackle these needs. Another driving force was the need to modify the network elements to cope with UMTS standards. It brought tremendous changes to the GSM network topology by introducing many new elements. which is an enhancement to the standard GSM radio interface technology. With the GPRS. Therefore a packet switched network like the one used in the Internet was needed. This led to the introduction of the Enhanced Data Rates for Global Evolution (EDGE).

The Mobile Service switching Centre (MSC) with its many ________________________________________________________________________ 7 . Before this some application developers and testers of the operators had used the network. To get the EGPRS to work.3 GMSK. it considerably changed the way packet based data is transferred. 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.NETWORK______________________________________________________________ theoretical only and the same network and mobile phone restrictions appear with the EDGE also. The growth of the 3G network usage will first be quite slow since the number of 3G mobile phones available is low. [Hal02] [Stu03][Seu03] 2. The biggest change was the new modulation technique 8-PSK implemented on the side of the former 0.1 What changed with EDGE update? The Enhanced Data Rates for Global Evolution (EDGE) was mainly a software update. With this new modulation technique theoretical maximum of the data rate was more than doubled. [Stu03][Pen02][Kos98] The first third generation (3G) network in Finland was opened for public use in October 2004. 2.1.2 Mobile Network architecture The 2G mobile network architecture can be divided into four different parts. However. The 3G and UMTS are out of the scope of this thesis so they are not described in detail. the Transceivers (TRX) in the BTS needed to be changed and some software updates had to be run for other elements and protocol stacks. No completely new elements were introduced with the EDGE. The Network Switching Sub-system is the main part of the circuit switched connections of the mobile network.

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

Every element has measurements called counters that are divided into categories depending on the interface and the usage entity. It is also used for collecting billing information from network elements. All of these measurements and their categories are network vendor specific and not standard. It also handles the unpacking of these PCU frames coming from the network. This collected information is the key for the whole performance and quality reporting. It also collects information from the network elements concerning their status and activity.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. BSC or SGSN. The PCU can be implemented on the side of the BTS. [Pen02][Hal92] 2.NETWORK______________________________________________________________ The packaging of the data is handled in the Packet Control Unit (PCU). MSC. This causes differences in the ways in which the same network actions are ________________________________________________________________________ 11 . Network elements can be managed and maintenance tasks can be run with the OMC.2.3 Network Measurements Many network elements like the BSC. The OMC is used to run software updates for network elements and to change their configuration parameters. The PCU transforms user data to the PCU frames before sending them. [Seu03][Stu03][Pen02] 2. It examines the traffic coming from the user and directs the GPRS packets to the SGSN element. Each element sends the information corresponding to it and its interfaces. SGSN and GGSN send their measurement data concerning transactions happening in the network and the element status information to the OSS. These categories are called measurement types.

for error blocks and retransmitted blocks. These measurement counters are updated only when there is data for them. These counters are updated for each channel coding scheme which were introduced with the EDGE. [Nok02] 2. 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. In most cases software updates for network elements bring new measurement counters or even new measurement types. Two of the measurement types were EGPRS related and they are next explained more clearly.NETWORK______________________________________________________________ measured and stored. Therefore linking the counters from different vendors is not always possible. These numbers change constantly with new software updates.3. [Nok02] ________________________________________________________________________ 12 . [Dis04] The number of the measurement types depends on the element.1 EGPRS related measurement types One of the new measurement types introduced with Nokia’s BSC version 10 was channel coding class. If the EGPRS has low usage in some areas. 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. 8 new measurement types were introduced. This new class contains counters for data blocks sent in downlink and uplink direction. 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. When Nokia released software version 10 for their BSC elements.

KPI formulas vary from one counter KPIs like “Number of Attempts” to complex formulas of “GPRS DL Data Rate”.NETWORK______________________________________________________________ 2. [Dis04][Nok02][Hal02] ________________________________________________________________________ 13 . The EDGE introduced categorization of 9 channel coding schemes compared to the 4 coding schemes of the GPRS technology.1 Key Performance Indicators and EDGE Key Performance Indicator (KPI) is an important counter or combination of multiple counters. All of these channel coding classes have different data rates and usage depending on the connection strength.4.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. The EDAP being dynamic in nature has difficulties of its own when implementing complex KPIs. Because these different coding schemes don’t have separate traffic counters in the Nokia’s implementation they are difficult to build as KPIs. Network planners need to get accurate information about the network status and traffic changes in the network. [Lai05] 2. To calculate the total EGPRS traffic. Measurement counters can be used to track traffic changes and find out causes for error situations. On the other hand if the usage percent is too high network quality drops because of network congestion and blocked calls. the sum of all coding schemes must be added to get the total sum.

[Vit95] The definition of the Software configuration management is one part of the whole software development process.1.1 Software development There are many general software development process models available which suit for different environments.2 summarizes the key points of the software configuration aspects with main focus on version management. 3. Section 3. This section goes through the process models behind the selected solutions for two different types of product component development projects.1 Software product development process In software product development reusability and duplicability are essential.1 introduces software development processes for use in different situations and section 3.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. 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. Making software into a product adds value into it in the customer’s perspective but also makes rules for the developing company. 3. You need to find ways to implement a general platform that can be used without modification as a ________________________________________________________________________ 14 . Software quality and maintainability are highly related to the configuration management process. The idea behind packing software implementations into products is to get more concrete appearance for the software with abstract nature.

[Sch02][Som96] Figure 5: Waterfall Model [Sch02] ________________________________________________________________________ 15 .1 Waterfall model Waterfall model is one of the most famous development process models. Therefore specifications for the product and needs of the customer have to be common.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ basis for as many solutions as possible. [Vit95] 3. A development process following waterfall model goes through phases as shown in figure 5.1. 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. The result of software implementation is not a product if it cannot be duplicated and installed for any customer without tailoring. It is highly used with governmental institutions especially by the Department of Defense in the USA.1.

________________________________________________________________________ 16 .1.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ 3.1. Product maintenance can also end in retirement when the product is no longer needed or is replaced with newer version. After the requirements are freezed the specification documentation is written.1. This documentation is the basis for the whole product and when it is accepted detailed project plan is written with a timetable and schedule. 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. In the maintenance phase the customer can find some errors that generate changes to previous phases. This can sometimes be named as a feasibility study or a pre specification step. The design phase produces the architecture and detailed design of the product. Requirements are summarized and agreed with the customer. After the implementation testing phase the product is handed to the customer for the acceptance testing.3 Analysis and critics on the waterfall model The waterfall model is a disciplined and a documentation driven model. [Sch02][Som96] 3. This is marked with a dotted line in figure 5 above. If the customer accepts the product it is transferred into maintenance phase. 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.1.2 Waterfall model phases Waterfall model as any other software life cycle model begins with collecting requirements from the customer. After verifying the architecture and design the implementation of the product can start.

It is also hard to predict the performance constraints before the system is almost ready for customer acceptance. These customer requirements are frequently unique and therefore cannot be duplicated for other customers. 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. Sometimes specifications including technical details are hard for customers to understand. With customization the customer can order the changes they want on top of the product. Implementation of all these customer requirements as new product variants would make product versioning messy and difficult to manage. [Sch02][Som96] ________________________________________________________________________ 17 . 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. 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. The nature of the customization process is entirely different and thence the same software life cycle model is not suitable.1.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ 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. [Sch02][Som96] 3. The usage of customized components is the best way to tackle this.2 Process for customization In many cases the standard product is not enough for the customer and tailored implementation is required.

Figure 6: Fountain Model [Sch02] ________________________________________________________________________ 18 .1. It is highly iterative in nature and uses parallelism between phases.2.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ 3.1 Fountain Model The Fountain model is one of the best known Object-oriented life cycle models. In general the model contains the same phases as the waterfall model. As illustrated in figure 6 the fountain model has iterations (marked by arrows) during every phase (marked by circles). The difference is in the iterative nature and the fact that different phases can overlap.

This comes up when different phases are run simultaneously and some modules might accidentally skip for example the design phase completely. test a bit) which refers to an undisciplined practice hackers use. The fountain model has been criticized for being too loose. The ability to do different phases simultaneously sometimes decreases the customer’s time needed for getting grasp of the product.1. There are still some features in it that are worth mentioning. [Jef01][XP00] ________________________________________________________________________ 19 . Therefore not as much relevant information about suitability of fountain model to different situations and environments is available.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 Fountain model developed in 1990 is still quite a new process model compared to the waterfall model introduced in 1970.2.3 Extreme programming Extreme programming is quite new approach to solve the disadvantages of other life cycle models. [Sch02][Som96] 3.1.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ 3.2. High level of iterative coding might also degenerate into the CABTAB (code a bit. 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. It is as its name gives hint an extreme way to do things.

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. [Jef01][XP00] 3. This is done by defining small releases. product ________________________________________________________________________ 20 . 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. The most important parts of the SCM are component recognition and management.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ 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 SCM is therefore much more than just version management of the source code. The code is constantly integrated to test it with other parts. 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.” [Koj04] [Whi91]. [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.

1. 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.2. Figure 8: Check-in / Check-out Model of Version Management [App98] ________________________________________________________________________ 21 .SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ architecture and structure. [Koj04] 3. product implementation and different teams or product families. 3.2. This paper concentrates on the version management aspect of the SCM leaving all other parts mainly out of scope. When the file is ready and tested. [Koj04] The main task of the SCM is to identify and manage changes coming from different sources with constant cycle.1 Check-in / Check-out model The check-in / Check-out model is the most common one of the version management models.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. the user checks in the copy back to the repository. 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.

In the merging procedure the newest version of the child branch is synchronized with the newest version of the parent branch. 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. Any conflicts in these two versions need to be solved to produce a new working revision.SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ The most basic model consists of only sequential version numbers.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.2. The ________________________________________________________________________ 22 . In more sophisticated versioning systems branching and merging is made possible. [App98] [Whi91] Figure 9: Branching and Merging in Version Control [App98] 3.1. 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 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. 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.

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 .SOFTWARE DEVELOPMENT AND MANAGEMENT__________________________ rise of the object orientation has given momentum for the evolvement of the other version management models.

[Dis04] ________________________________________________________________________ 24 .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. This layer contains also the DC5000 reporting GUI (Graphical User Interface) which is a web interface to visualize the reports. The main focus is on the end user side components and their change management as within the whole thesis. week and month. 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. These network elements can be part of a fixed. broadband or mobile network as can be seen on the figure 10. 4. Above the Network Data Modeling layer is the Network Data Visualization layer which contains reports that are used to visualize the data.1 General overview The DC5000 system collects various types of data like performance management (PM) and fault management (FM) from different network elements. Raw measurements from the elements are then aggregated to get busy hour values and total values for day. This data is stored in the database tables with the current network topology information in its own tables.

5G 3G 4G Figure 10: DC5000 Product Architecture [Dis04] 4. These conditions can either be fixed or prompted for the user input. ________________________________________________________________________ 25 . Universes hide the SQL structures behind objects and schemas. tables and database functions and Condition objects that are restrictions for the database query. 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. FM.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. Objects in universes can be divided into two parts Data objects that are the mappings of database structures like columns. SM Data Data Gateways Fixed/BB 2G 2. CM.1.NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____ Network Data Visualisation Network Data Modelling DC5000 Network Aggregated Platform data Data Raw data Management Network PM.

Examples of these KPIs are traffic and data rate formulas. Universes also contain Key Performance Indicators (KPIs) that are objects that hide the formulas of difficult measurements from the end users. A technology package covers all layers from the data sources up to the end user reporting. A single technology package of the DC5000 is a content specific vertical solution related to for example measurements of a certain network element.NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____ Reports / Universe Access Universe REF Reference Data Raw Data Aggregated RAW AGGR Data Figure 11: Network Data Modeling in DC5000 [Dis04] The universe contains the model of the database schema with tables. 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. [Des03] The DC5000 specific universes are part of a technology package. [Dis04] ________________________________________________________________________ 26 . Database connections using the ODBC are also specified in the universe. joins between them and contexts that specify which joins are applicable in one SQL select clause to the database.

2 Reports Reports are created with the Business Objects client and they use universes as their data source.1. Reports are built by picking up objects from the universe structure like measurement counters. 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.NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____ 4. 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. [Bus03] ________________________________________________________________________ 27 . KPIs and topology dimension objects.

NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____ 4.2 Version and change management Changes to system components can be initiated by various sources. 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.1 Network updates Mobile networks are under constant change. ________________________________________________________________________ 28 . Research and Development (R&D) team also designs new features for universes and reports based on the updated network vendor’s specifications. 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.2. Sometimes network vendors execute patches directly to elements or via the OSS that change the data format loaded from the element for example. 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. These changes can be more unpredictable but in most cases they affect only the data loading and the parser units of the system. which could mean new or changed measurement counters or sometimes even new measurement classes with counters. 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. There are also many sources between these two end points. All of these sources can affect versioning and change management differently. All these changes apply to the universe structure. 4. The most important ones of these sources are next examined more thoroughly. Sometimes vendors release a new version where the database structure is not compatible with the previous one.

2.2. ________________________________________________________________________ 29 . In other cases a linked customer universe must be created above the tech pack universe in order to have these requirements fulfilled. 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. You can’t use multiple BO installations on the same computer without problems. On the other hand the newer BO version might face problems when using reports created with an older BO build. 4. In many cases you cannot use reports that are created or modified with a newer BO with an older BO version. a new tech pack universe version could be created.4 Third party software updates Reports and Universes that are generated with Business Objects (BO) are highly version dependent. If the customer does universe development of his own. Therefore the BO version update will be a challenge for versioning. 4.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.NETWORK PERFORMANCE REPORTING SYSTEM AND ITS VERSIONING_____ 4. These changes could be new KPI objects or new conditions objects. 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.2. The Customer’s universe developers can then either make the new features to this customer universe or get a consultant to make them. If these new requirements are general and in line with the other product items. The R&D development process is highly iterative because it is hard to predict how one change affects other parts.2 Operator initiated updates Sometimes network operators want to have new features into the exiting universes.

With this new software tool also practical aspects are more easily explained and concrete results for the thesis could be given. After the base information new solution models for the development processes and version management are introduced. ________________________________________________________________________ 30 .2) were taken into account when designing these new models. Because the Business Objects software doesn’t allow multiple versions of a component with the same name.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 development version was renamed with a test prefix to avoid overwriting the final production version of the component. 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. The development environment consisted of one Business Objects repository where both the development and final versions were stored.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. 5. 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 challenging environment and boundary conditions introduced in previous chapters and set by the predefined criteria (see 5.

the errors found affected in many cases more than one report.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 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. ________________________________________________________________________ 31 . The environment described in 5.1 had many version management issues that needed to be considered. Another challenge about the development process was to evaluate the possibility to separate the standard product and the customer related customized components. 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. One of the most important challenges was to find a way to manage Business Objects components (universes and reports) more accurately and flexibly. Another issue that needed changes was the version management. 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.2 Challenges and Criteria for Solution Models The environment described above gave reasons for many changes. 5. Since all of the reports were implemented before any of them was acceptance tested. Both the CVS and Business Objects lacked the ability to analyze and compare the different versions of the components in an object level. 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. 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.

Criterion 4: Prices for different types of version updates should be easily available. The change manager has the same kind of interests as the CTO. And as last but not least. The following criteria were defined for the new configuration management processes with the Enterprise Quality Manager Tool in use. Criterion 6: The usage of the tool and component management should be simple. Developer aspects: Criterion 5: Versioning policy needs to be clear and easy to understand. ________________________________________________________________________ 32 . Criterion 9: Technology packages should be easily monitored and mastered. The solution models evaluated and defined in this thesis should be based on the Enterprise Quality Manager tool.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ The solution models should be considered from the point of view of different stakeholders. Criterion 7: New methods should not dramatically slow down the development cycle. For the customer product reliability and seamless update procedures are key issues. The CTO as being the head of the technical aspects needs to know technical issues concerning development and versioning. All existing reports should work. Sales and management teams are interested in keeping the product profitable and defining sales methods and prices for different types of updates and implementations. Technical aspects: Criterion 8: The new method should suit better than the existing one to the product management. 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. 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.

All this information is written into a technology package specification document with other information related to that specific technology package. 5. they are also added into the technology package specification document. Since the requirements in this case are coming from the network element vendors and not directly from the customers. This same product development model is used also with technology roll out reports and verification reports which are part of the general product. Also. in this phase proposals for new features coming from the customers and the R&D team are analyzed and if accepted. Therefore it seems that waterfall model suits quite well with the universe development process. 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. ________________________________________________________________________ 33 .DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ Criterion 10: There must be an easy way to restore the old versions of universes and reports 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. 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. the input for the specifications can be regarded as stable.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.

The actual coding is only a minor part of the universe implementation since the universes are created by the Business Objects Designer tool. This way it is necessary to ensure that all reports that worked with the old universe version also work with the new one. 5. ________________________________________________________________________ 34 . 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.2 Design phase The design of the universes is maintained as simple as possible.3. The coding basically includes inserting the SQL select clause for measurement and dimension objects and the SQL where clause for condition objects.3.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 5. 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.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.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 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.

the collective ownership of reports and onsite customer whenever possible. The XP methods in use are spikes. small releases. ________________________________________________________________________ 35 . These are analyzed and given a severity level. the implementation is module tested by the developer during the implementation and the system tested during the installation. 5. coding standard.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. According to this level some fixes are made instantly and some are made during the next upgrade to that package. 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. Sometimes bugs are found in a universe that is in the maintenance or some new development proposals are discovered.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. continuous integration. The use of prototyping to see if a report meets the customer requirements is often necessary. 5. 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. Integration testing is committed with a regression analysis where possible.3.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ Testing and verification are conducted during the whole process. Documents are verified and reviewed.

Some of the required reports are normally ready for design while some need further specification and some are rejected as being impossible to implement. reports are implemented with test data and then sent to the customer. In this phase the usage of spikes can be a useful way to get acceptance for the new design from the customer. When implementation in the customer premises is not possible due to long distances.4. they are specified and implemented into the linked customer universe on top of the tech pack universe. 5. Reports are developed in small releases to get them faster to the customer for acceptance and also to production. The sequence in which the reports are implemented is specified.1 Feasibility Study and Specification phase In the feasibility study phase of report development customer requirements are collected and analyzed. This enables the possibility of continuous feedback from the customer and better access to live network performance data.2 Design phase Reports are implemented on top of a template or a previous report whenever possible. Some of the reports are then ready for implementation while the feasibility study and specification phase is iterated for other reports.4. When complex reports are implemented where no template or previous report is available a new template is designed.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 5.4. If the customer needs specific items into the universe like KPIs or filters before some reports can be implemented. 5. This way the layout and report structure remain standard.3 Development phase The report development is handled as consulting in the customer site when the customer is located near by. Reports are customer ________________________________________________________________________ 36 .

4 Integration phase and testing Reports are rather independent modules that are only linked to one or more universes or other data sources. The ________________________________________________________________________ 37 . The report developer is responsible for the module testing report functionalities and details. Reports are published to repository when they are ready and they are managed and linked to different users and user groups from there. The launch of the new universe and report versioning and management tool set some boundaries for versioning policies. Universes and Reports while developed with different process models possess and share still the same versioning principles. 5.5 General Versioning principles This section describes general rules for the universe and report versioning in different situations. Report errors that are found during the maintenance phase are corrected individually according to the support contract. When the reports are ready from internal testing they are sent to the customer for acceptance testing.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ tailored products and need sometimes iterations to get all customer requirements implemented as desired. 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.5 Maintenance The maintenance phase of the reports is quite identical with the universe one. 5.4. 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. 5.4.

DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ Enterprise Quality Manager (EQM) general management tool developed by Noad Business Intelligence offers three stage versioning.5. ________________________________________________________________________ 38 . The Concurrent Versioning System (CVS) is also used as backup and a knowledge bank for different kinds of solution models. Reports inherit the first two version numbers from the universe version they are built on. 5. These specific customer needs are for example KPIs and specific filters. if the DC5000 release number and version number are identical the report is tested and works with the DC5000 release in use.5. 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.2 Network vendor initiated versioning The second versioning number reflects the network vendor’s release number. 5. This way. These modifications raise the third versioning number.5. 5. The iterative development of the reports also raises this third number. When new release update is implemented the second versioning number is raised. Rules for adopting these new versioning stages in different situations are explained.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.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.

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. The search for the new general management tool capable of conducting both process and versioning constraints were started.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 5. 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.6. 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.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 . 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. The most important ones are described here.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.1. 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.6. 5.

1. The timestamp and the username can be found in the user interface in case other users need the same components for modification. More repositories could be installed beside for development etc but management and report transfer between these environments is difficult. ________________________________________________________________________ 40 . The EQM needed also repository of its own to store the information of reports and universes and their details.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ customer premises. minor and revision) to cope with the changes. It also uses empty repositories called Transfer areas to move reports between the EQM and the Business objects repositories. 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. When the components are locked they are still available as read only copies. acceptance. With the EQM it is also easy to restore a previous version if the new one is found buggy. 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. [Noa04] 5.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. The configuration management process is based on a check in – check out model where the user locks the component for modification. production and testing that is optional). The EQM system expects that there are either three or four environments (development.6.

A database must be setup and new Business Objects repositories need to be installed with the correct user ________________________________________________________________________ 41 . With the EQM these transfers can be done and the power of the linked universes is available. [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.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 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. 5.6.2 How is EQM launched? The launch of the EQM needs many preparations for the environment.

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.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ accounts. The production chain will become standardized with the EQM since it almost forces users to follow the same flow model described in figure 14.6. When the infrastructure is ready the EQM software package can be extracted. User rights are given as environment basis. developers and testers are the common users of the EQM. Administrators.3 How EQM works? The basic idea is that all universes and reports should be under EQM management and published only through the EQM. [Noa04] 5. After the installation many configurations are needed to build the EQM repository and make the access to all transfer areas and BO repositories available. In order to accomplish this user rights in the Business Objects environment were limited to prevent publishing of components. 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. 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. 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. [Noa04] ________________________________________________________________________ 42 . The EQM contains user accounts and account management of its own. 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.

7 Case Nokia EDGE update With this case project the new process model and versioning tool are explained from the practical point of view.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ Figure 14: The EQM Work Flow [Noa04] 5. it was obvious that operators would like their network and network performance management tool to support this new technology as soon as possible. ________________________________________________________________________ 43 . When Nokia upgraded its BSC network element’s software version to cope with the EDGE technology.

All of these measurements were smoothly included into the former universe version since all the modifications were only additions in to the universe. 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. 5.1 Universe changes With the release 10 of Nokia’s BSC element. The customer specifications also included plenty of new KPIs to be added into the universe.7. ________________________________________________________________________ 44 .1. The R&D team designed also the structure for handling the new topology items introduced. In release number 10 there were two new EDGE related measurement types: 76 (dynamic Abis pool) and 79 (EGRPS coding scheme) with their counters.7.7. The Nokia’s database description specification presents the list of measurements available with this new version.1 Sources for universe upgrade The base source for the whole upgrade project came from the network vendor. Some of the KPIs had such complex formulas that the R&D needed to design new methods for the data management to handle them. 5. the customer started to specify modifications for old reports to handle the EGPRS and some completely new reports.2 Sources for report upgrade After the new universe version was developed and in the production. 8 new measurement types were added into the universe with their counters.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 5.

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.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. They were given the same updated second versioning number as the universe they were built on had. These reports were sent for customer acceptance before the implementation of the new reports was started. This modification raised the third versioning number since it had been initiated either by the R&D or customer. The old reports were modified to include the new EDGE counters and KPIs and then renamed to better describe the new contents. ________________________________________________________________________ 45 . When the report update project was initiated the universe needed the update for the topology and the new KPIs.2. When these new reports were ready they were also sent to the customer for acceptance.7. The report’s third versioning number was thereafter updated with every iteration cycle.DEVELOPMENT OF NEW SOLUTION MODELS_____________________________ 5. The new reports were then implemented using the old reports and report templates as basis so that the design remained standard.7. After the customer had tested the universe it was transferred to the production environment. 5. When the universe was ready the modifications in the report were started. Reports were modified as specified in the documentation. The developed universe was then checked in to the EQM and transferred to the acceptance environment for testing. The universe was checked out and modified.

The integrated version management and the separation of development and production environments were key aspects when selecting the EQM for further evaluation and installation. The EQM as being only an interface between the developer and the Business Objects environment has quite a lot to configure. The results of the evaluation with other user experiences are analyzed. The description of the new process models was also conducted. Fortunately. As it includes a lot of manual configuration it is error prone and ________________________________________________________________________ 46 . 6. 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.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 start up configuration. This installation process could be much easier and more automated. 6. this start up configuration needs to be done only once and the normal client installation is much simpler. The processes are analyzed separately against the requirements and criteria.1.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.1 Easiness of Installation The EQM software was easily unpacked and installed.

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. 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. Figure 15: All Commands Visible [EQM04] ________________________________________________________________________ 47 . the GUI can be used to visualize one or many environments simultaneously in the same window. there still might be errors left that are hard to find.6 is quite general in nature and therefore easily adopted.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. 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. The workflow model described in figure 14 of section 5.1. 6.ANALYSIS OF THE RESULTS_____________________________________________ while the EQM has its own error analyzer. 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. 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.

On the other hand. acceptance and production) while in some cases two or even one environment would be enough. This is partly due to the fractioning of the documents to the object level before storing them into the EQM repository. still setup and maintain the unnecessary environments. Another thing that slows the process down is the fact that the report needs to be published simultaneously into two places. Another weakness of the EQM is that it slows down the whole computer during the publishing. ________________________________________________________________________ 48 . The publishing process for documents is rather slow with the EQM. The EQM has also trouble with publishing and transferring reports in batches. This three level numbering could be the best for most cases but in some cases an additional fourth level could be justified. The EQM has also fixed version numbering. 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. acceptance and production environments is almost a necessity for customers with regular development of their own going on to avoid unwanted situations. 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. 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. [testing].ANALYSIS OF THE RESULTS_____________________________________________ The EQM forces to use three or four environments (development. the EQM and the BO repositories. the separation of the development. This enforces the customers that are not doing their own development. The publishing process is interrupted constantly and report categories are not easily changed.

It also gives a good upgrade for the report and universe management and quality control. Without the EQM the linked universes can’t be transferred safely between development and production environments. The EQM’s version history is also a fast way to get information about who has modified a document and when. As described in detail the installation has many manual configurations that need to be done.ANALYSIS OF THE RESULTS_____________________________________________ 6.1. were one of the main reasons for selecting the EQM.1. Linked universes which are a good way of separating product components from the customer specific objects. It is a good way of finding what has changed with every version modification. If an environment is divided into multiple domains this feature stops working ideally. 6. 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 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. which ________________________________________________________________________ 49 .3 Usability of features The EQM enables the usage of linked universes in the multi environment installation. The usage of linked universes is simple with the EQM and needs only minor modifications to the development process. Another beneficial feature is the difference analysis that can be run to compare universes and reports. 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.4 Summary of the EQM The EQM contains the very features that we were looking for.

The usage of multiple BO environments and additional EQM environments add a lot to the total maintenance work. Criterion 7 is also not even closely met. The process flow of the EQM looks better on the paper than when the tool itself is used. The usability and user friendliness had also many shortcomings. The developer aspects on the other hand are more concerned about the user friendliness. Are the benefits greater than the lack of usability and extra costs ________________________________________________________________________ 50 . Since the EQM is not a freeware. Overall the EQM is quite suitable for handling all the requirements it was planned to take care for. If the EQM is valued and compared to the criteria set in chapter 5. management and technical criteria since they are quite feature-based in the case of the EQM evaluation. The Usage is slower than expected and the need for configuration during the installation is quite high.ANALYSIS OF THE RESULTS_____________________________________________ contain a moderate chance for human errors. Therefore it could be considered passed with notification that it is not ideal in all cases where 4-stage numbering would be ideal. Criterion 5 is not so EQM-related since the EQM only gives boundaries for the process that specifies the used policy. some of which could easily be improved. it is important to consider the benefits and weaknesses also in business sense. The presence of the multiple quality control features on the other hand help to save time when modifications are made. The fact that the EQM slows down the computer and could even kill processes is a big weakness. 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 publishing process for one environment is about 5-10 times slower and the same factor is used for other environments. it clearly passes the customer. 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.

Testing is also done during all of the process phases to keep the quality high. The need was also evident since the customization projects ________________________________________________________________________ 51 . 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.2 Customization process The customization process encountered greater modifications than the product development process. Another good point about the waterfall model is the fact that the documentation is kept up to date. The models were developed to be as generic as possible while the EQM set some boundaries. 6. 6. So that even if the EQM would not become a success they could be used as a basis. The models are usable with or without the EQM.2.2. The specifications are written according to the network vendor’s database descriptions and therefore are stable.1 Product development process The product development was adopted on top of the waterfall model since the requirements and specifications were stable. In the cases where the customer uses only the product components the benefits are less evident and barely greater than weaknesses. 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. 6.2 New Development Process in Use The new processes were developed to increase the productivity and quality of reports and universes.ANALYSIS OF THE RESULTS_____________________________________________ 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. The universes and reports in the object level are relatively independent.

3 Summary of the Development Processes The process models seem to be appropriate for the situations they were designed. The previous model was not suitable for the situation where specifications kept changing so much.3 Suitability of the new Versioning Model The new version management model is tightly related to the EQM and the boundaries EQM sets. 6. 6. In the paper it seems fine and tackles the problems that we used to have. The new model has not been used so widely that any indications could be analyzed about its suitability in real projects. The customization process encountered much more modifications. The projects are also estimated to finish earlier than with the previous model because of these characters.ANALYSIS OF THE RESULTS_____________________________________________ encountered specification changes almost every time during the implementation and integration phases. 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 product development process has been used successfully for multiple projects. 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 new model handles the entities in smaller portions and uses prototyping to get the customer feedback earlier. The model is though rather easily modified for the case of other version ________________________________________________________________________ 52 .2. Testing can also be more easily accomplished when the data is complete and real. the development is faster and easier. Customers have also been quite positive about this new model and are looking forward on testing it.

the level of possible misunderstanding is actually lower. The version management policy became tolerably clear. This could be misleading and confusing at some level but no better solution could be found. The study identified and categorized quite well the sources for the changes that apply for reports and universes. It could be estimated that the generic model is fairly clear. 6.ANALYSIS OF THE RESULTS_____________________________________________ management tools in use. The study works as a good basis for further development of the version management. And because the EQM allows version description to be input. Therefore the only criterion that is tightly related to this model is criterion 5 and it could be considered to be passed. ________________________________________________________________________ 53 .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 restriction to categorize the versioning with three numbers led to the problem of reporting bug fixes and customization revisions with the same versioning digit.

The development processes for these components also needed to be reviewed and described to suit this new situation. The versioning policy was also defined to fit into the requirements the EQM set for it.CONCLUSION___________________________________________________________ 7 Conclusion Distocraft’s configuration management of reporting components was getting all the time harder as the customer base was growing. The version numbering was ________________________________________________________________________ 54 . 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. This study was required to analyze the suitability of the EQM general management tool to handle these configuration management issues. The need for a more product dedicated solution was under investigation. 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. It also set some boundaries and restrictions for the solution. The EQM analysis gave basis for defining new process models and versioning principles. The development processes were to be modified to cope with this new situation and usage of the EQM. The present state of the development processes and versioning was then analyzed to identify the benefits and weaknesses of them. 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 variety of mobile network elements that were modeled was also growing since they were dependent on the network vendor and the element version. 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. A set of criteria were defined for different stakeholders as requirements for the EQM and the new processes. Therefore sources for changes were getting harder to manage without proper tools.

The ________________________________________________________________________ 55 . The different versions can be compared on the object level and when changes are coming. The EQM scatters the components into factors before storing them into the repository. 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. This enables many good features for component configuration management. The features it supports worked fine and were evaluated to be fairly important when considering the future state of the products. the EQM can be used to track which components are using the objects that are to be modified. The EQM evaluation was productive.CONCLUSION___________________________________________________________ fixed with the EQM to three stages (major. It is clearly better than the former model but still some issues were left. The user friendliness on the other hand turned out to contain issues that were poorly done. minor and revision) compared to the two stages used with the CVS. The new development processes seemed to be fine. The product development process has been tested already by multiple projects with a positive response. Therefore it was hard to compare the benefits and weaknesses. 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. replacement of the EQM with other management tool should be considered. The new version management process added visibility and distinctness to the principles. It gave some good and some unexpected results. 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. 7. The customization process as being fresher has not been tested so widely but the first comments were quite favorable.1 Recommendations for future studies The EQM has some issues that should be estimated and if they are too great compared to benefits.

Therefore they should be consulted for the fixes for issues found in the user friendliness. ________________________________________________________________________ 56 .CONCLUSION___________________________________________________________ Noad Business Intelligence is helpful and eager to receive user response. 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.

Referred 3. ISBN 0-13-949124-4 [Hal92] Televiestintäjärjestelmät Seppo J.smu.pdf Eric Bird.01.2005 [Bir04] Cellular/PCS Network Architecture http://engr.7. Referred 03. 6ed. Halme Otatieto Oy.7. ISBN 951-672-325-X ________________________________________________________________________ 57 . Wilkes Prentice Hall PTR.cmcrossroads. Robert Orenstein.. 1992.html Brad Appleton. 2004 [Gar99] Principles and Applications of GSM Vijay K Gard.12. 2004.2004 [Bus03] Business Objects User’s Guide Business Objects 5. Ralph Cabrera.1.1 Noad Business Intelligence.1. Joseph E. 1999.REFERENCES___________________________________________________________ References [App98] Branching Patterns for Parallel Software Development http://www. Berczuk. 1998. 2004 [EQM04] Screen captures from Enterprise Quality Manager 3. 2003 [Des03] Designer’s Guide Business Objects 5.com/bradapp/acme/branching/branch-intro. Stephen P.edu/~ebird/Handouts/ EETS8306_Lecture5_NetworkArchitecture_2004_RevA. 2003 [Dis04] DC5000 Product Description Distocraft Oy.

soberit. GPRS. EDGE. 2004. Chet Hendrickson Addison-Wesley . 2003.tu-bs. ISBN 0-470-84468-X [Jef01] Extreme Programming Installed Ron Jeffries. UMTS and Beyond http://www.de/events/SummerSchool2002/kss-keller. ISBN 0470 84457 4 [Häm01] GPRS. Referred 23. Korhonen.2005 [Kor04] GSM+GPRS http://www.2004 [Jam03] The Wireless Mobile Internet.fi/opetus/423/lect2004/05_423gsm.1.12. architectures. 2001.11. Langattomasti tietoverkkoihin http://www.fi/T-86/T-86. GSM.klinkmann. Referred 23.ibr. Ltd 2002. Referred 4.2004 [Koj04] Software Configuration Management http://www.REFERENCES___________________________________________________________ [Hal02] GSM. 2001 ISBN 201-70842-6 [Kel02] Mobile Communication. Ann Anderson.pdf Timo O. 2002. Referred 1. Javier Romero and Juan Melero John Wiley & Sons. GPRS and EDGE Performance: Evolution towards 3G/UMTS Timo Halonen.cs.pdf Ralf Keller.pdf Kalle Hämäläinen.com/miscellaneous/SoneraKlinkmannSem/pdf2/So nera. 2004.hut.141/2004/SCM_ESI_Tero. protocols and services Abbas Jamalipour John Wiley & Sons Ltd.comlab.2004 ________________________________________________________________________ 58 .pdf Tero Kojo.hut.11.

3ed ISBN 0-07-138148-1 [Noa04] EQM Training Material Noad Business Intelligence. Schach McGraw – Hill Ltd. Mullen McGraw –Hill Ltd. 1992. ISBN 951-0-26564-0 [Sch02] Object Oriented and Classical Software Engineering Stephen R. ISBN 0-07-239559-1 ________________________________________________________________________ 59 .REFERENCES___________________________________________________________ [Kos98] GSM Service Evolution towards Universal Mobile Telecommunications syste Jussi Koski Helsinki University of Technology. 2002. 5ed. Marie-Bernadette Pautet Published by the authors. 2005 [Mou92] The GSM system for mobile communications Michel Mouly. 1998 [Lai05] Distocraft Telecom training Jussi Laimio. ISBN 2-9507190-0-7 [Mul02] Desktop Encyclopedia of Telecommunications Nathan J. 2004 [Nok02] NDW Database Description for BSC Measurements Nokia Networks Oy [Pen02] GPRS in Wireless Data Jyrki Penttinen Werner Söderström Oy 2002. Master’s Thesis. 2002.

2005 ________________________________________________________________________ 60 .REFERENCES___________________________________________________________ [Seu03] EDGE for Mobile Internet Emmanuel Seurre. 2000.Jean Pietri Artech House. referred 10. 2000. Patrick Savelli.1. 5ed. ISBN 951-672-305-5 [Whi91] Methods and Tools for Software Configuration Management David Whitgift John Wiley & Sons Ltd. ISBN 1-58053-597-6 [Som96] Software Engineering Ian Sommerville Addison-Wesley publisher Ltd. ISBN 0471929409 [XP00] Extreme Programming home pages http://www. Seppo Uusitupa Otatieto Oy. 2003. Master’s Thesis. 1991. 3ed. 1995 [Voi00] Tietoliikenne aapinen Kirsi Voipio. 2003. ISBN 0-470-84855-3 [Vit95] Ohjelmistotuotteiden tuotteistaminen Katriina Vitikainen Lappeenranta University of Technology. ISBN 0-201-42765-6 [Stu03] The GSM Evolution.extremeprogramming. Pierre. mobile data services Peter Stuckmann John Wiley & Sons Ltd. 1996.org Don Wells.