How to realize software evolution of existing BOSS via ZTE SEEM

How to realize software

evolution of existing BOSS via ZTE SEEM

Abstract

Due to long-term construction and accumulation for different purposes, telecom carriers normally have very complex IT environments, especially in BSS/OSS domains. Just like any other software projects, the telecom IT construction is a process always behind the market changes; therefore, ‘how to evolve or replace these legacy systems to support continuously changed market requests’ is a puzzle in telecom CIO/CTO’s mind. To answer this question, we need to know two methodologies (i.e., software maintenance, and software evolution). In this article,

Zhan Zhang

we would propose an approach, Software Evolution Enhanced Methodology (SEEM), which essentially is a methodology to evolve a legacy system with minimized pain and cost based on theory of software evolution. This methodology has been utilized in many previous projects successfully.

Introduction

Literature Review

addressed issues and presents a challenges analysis at the conceptual level.

Background

Addressed Issues and Solution Space

carriers from multiple aspects, such as a) enhance customer experience; b) reduce OPEX & CAPEX; c) shorten time to market; d) fit new business model; e) digest & apply cutting edge technologies. So every telecom carrier must have a evolvable Business and Operation Support System (BOSS) to satisfy these demands.

As common-sense, BOSS is mainly a very complicated and sophistic software system, and it usually has multiple components according to standardized specifications (e.g., eTOM, and NGOSS). All these components cannot be implemented and deployed at one time due to financial budget and man-power constraints. Since it takes a relevant long time to construct the whole BOSS and it is impossible to foreseen all changes at the beginning stage of BOSS construction, each CIO/CTO has to face a challenge, ‘how to evolve or replace these legacy systems to support continuously changed market requests’. This is a definitely frustrating thing. owing to ROI concerns, it is a dilemma to choice either renovate a legacy BOSS component or replace it with new one. However, no matter which

solution is chosen, the following major difficulties are inevitable in the process of upgrading BOSS, a) communicate with multiple software vendors; b) integrate with heterogeneous architectures; c) satisfy continuous market demands; d) expend life-cycle of existing BOSS components. So far we have clearly understand the background of the addressed issues. The purpose of this article is to find a practice methodology, by which a legacy BOSS component can be evolved to fit new requests with minimized pains and costs. In details, the major topics discussed in this article are described as below:

● What is the suitable methodology to realize BOSS component upgrading

● How the methodology to enable upgrading BOSS components in a relevant short time ● what are the necessary tools to support this methodology

This section introduces concepts of software maintenance and evolution, especially the latter, since our approach is built based on several methodologies of software evolution.

Software maintenance [1] is a set of activities of changing the system after it has been delivered. including :

● Corrective maintenance: repair of software

faults

● Adaptive maintenance: modification of

software due to changes in the operating environment (hardware, supporting software) ● Perfective maintenance: additions to and/or

modifications of system functionality due to organizational or business changes ● Preventive Maintenance: is defined as an

activity during which we attempt to prevent an unnecessary change in the future [2] The software maintenance is very important stage of the whole software life-cycle. At least the almost equaled costs are devoted in both software development and maintenance stages. the following Figure 1depicts the details.

Software Maintenance

Software Evolution

According to statistics shown in Figure 1, the major maintenance effort focuses on functionality addition and modification, and the effort on fault repair and software adaptation are much less then it.

Prof. Meir M. Lehman [3] with his colleagues have identified a set of behaviors in the evolution of proprietary software. These behaviors (or observations) are known as Lehman’s laws, and there are eight of them:

● Continuing Change: A program that is used

Figure 1: the expense & cost on development and maintenance stages

Figure 2: Distribution of maintenance effort

As time goes by, the maintenance becomes much more difficult due to:

● It is hard to remain team stability

● Staff skills are changed as main-trend technologies change

● Original software is aged and its structure increase costs and expenses

● Contractual responsibility of team reduces the limit the software capability and expendability

in a real-world environment necessarily must change or become progressively less useful in that environment.

● Increasing Complexity: As an evolving program

changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. ● Self Regulation: Program evolution is a

regulating process. System attributes such as size, time between releases and the number of reported errors is approximately invariant for each system release.

● Organizational stability: Over a program’s

lifetime, its rate development is approximately constant and independent of the resources devoted to system development.

● Conservation of Familiarity: Over the lifetime

of a system, the incremental change in each releases is approximately constant.

● Continuing Growth: The functionality offered

by systems has to continually increase to maintain user satisfaction.

● Declining Quality: The quality of systems

will appear to be declining unless they are adapted to changes in their operational environment. ● Feedback System: Evolution processes

incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Foundation of Approach

Identified research themes by Bennett and Rajlich [4], the researching aspects of software evolution

are: a) requirements; b) architecture; c) data; d) runtime management; e) service-oriented; f) language. The major solutions includes: a) Reverse and Re-Engineering; b) Incremental Change Techniques; c) Managerial Issues; d) Software Process; e) Model Evolution. Also there are two prevalent views:

● What and why: focuses on software evolution as a scientific discipline. It studies the nature of the software evolution phenomenon, and seeks to understand its driving factor, its impact, and so on.

● How: focuses on software evolution as an engineering discipline. It studies the more pragmatic aspects that aid the software developer or project manager in his day-to-day tasks.

The proposed approach is built based on several methodologies of software evolution (depicted in Figure 3).

Horseshoe Re-engineering model is a very popular model to realize software evolution. As shown in Figure 3, a legacy software system can be extracted to a high-level architecture model, which can be improved to a restructured model. Finally a new software system can be conducted from the restructured model. Agent-based wrapping model is another methods to renovate legacy software system via wrapping.

Figure 1: foundation of SEEM: Re -engineering & Wrapping

Proposal

Our approach is called Software Evolution Enhanced Methodology (SEEM), and it addresses BOSS domain. It defines the basic practices, process flow, and infrastructure. The following Figure 4 elaborates SEEM clearly.

In order to achieve the predefined goal, SEEM defines a process as shown at the bottom of the figure. This process is an series of internal activities: ● Stage A: this is the first stage of SEEM flow. it is to collect and extract the necessary information from a legacy BOSS component by observing external standards, new technology, and business request.

● Stage B: once collecting this information, it needs to do the impact analysis according to evaluation criteria, including priority, cost/ expense, and market trends.

● Stage C: this stage is called ‘Roadmap Generation’, and it defines the approach adopted in terms of the previous analysis, such as re-engineering, wrapping, and refactoring.

● Stage D: this stage is to re-build the model of the BOSS component. it mainly impacts the aspects of architecture, interface, interaction, and data structure; therefore, the legacy BOSS component can be encapsulated (e.g., transformation, synchronization, and replication) to realize upgrading.

As these internal activities are on-going, the changes of the BOSS component are on-going as well. the relationships are described in the figure. these changes are separated in multiple phases, and they are described as below: ● Probing: this phase is in charge of data collection, configuration, meta-model extraction, log analysis

● Implementation: it may use different strategies to realize implementation according to detailed requests, such as refactoring, wrapping, modeling, replacement, and tailing

● Simulation & Validation: all implementation result will be simulated and validated before commercial launch. The key activities in this stage includes preparing test-case, trying run, deploying environment, and organizing team

● Migration & Monitoring: all validated result will be migrated to commercially launched environment. it will change data, business logic, interface and interaction model

To support these activities and processes, SEEM is built based on a standard infrastructure, including: ● UML tool: Unified Model Language is adopted to model and describe the request, architecture, process flow etc

● CVS: Control Version System is adopted for version & release control

● ZSmart framework: ZSmart is a BOSS component collection provided by ZTE. It is organized as multi-level architecture. The bottom level is called ZSmart framework, an open-structure framework, to implement all non-business requests, e.g., logging, reporting, messaging, and so on

● Visualization tool: Since BOSS is too big to image, the visualization tool can help designer,

developer, tester easily identify the changes and issues

● Refactoring Tool: this is always implemented in popular development tool, e.g., Eclipse, and NetBeans

● Monitoring Tool: it helps us to quickly understand the changes occurring in the whole process The features of this approach are: a) End2End Capability; b) Multiple Tactics; c) Wrapper Supported; d) Extreme Programming tolerance; e) Staged Process; f) UML standardized; g) Meta-Model Driven; h) Simulation Embedded; i) Separated Internal/external activities; j) legacy tech compatible; k) eTOM Addressed; l) Unified Processed

Summary

This paper proposes a methodology called SEEM, by which we can upgrade legacy BOSS component with less pain and costs, since it is based on software evolution, software maintenance and Zsmart framework. Also some cutting-edge

technologies are adopted, and it has been proven in several projects. The major benefit of SEEM is: a) balancing maintenance and evolution; b) extend the life-cycle of legacy BOSS component; c) support heterogeneous environment.

reference

[1] ISO/IEC 14764:2006 Software Engineering -- Software Life Cycle Processes – Maintenance [2] Kajko, Mattsson 2001, IEEE standard 610.12-1990

[3] Meir M. Lehman, Programs, Life Cycles, and Laws of Software Evolution, Proceedings of the IEEE, Vol. 68, No. 9, September 1980

[4] Rajlich, V.T.; Bennett, K.H., A staged model for the software life cycle, Computer, Volume 33, Issue 7, Jul 2000 Page(s):66 - 71