Realizing the Software Evolution of Existing BOSS with ZTE SEEM

Background

New market demands have impacted telecom carriers in multiple ways; they have enhanced customer experience, reduced OPEX & CAPEX, shortened the time to market, created new business models, and digested and applied cutting edge technologies. Every telecom carrier must have an evolvable Business and Operation Support System (BOSS) to satisfy these demands.

BOSS is primarily a complicated and sophisticated software system, containing multiple components according to standardized specifications (e.g. eTOM and NGOSS). All these components cannot usually be implemented simultaneously due to budget constraints or manpower constraints. Since it takes a long time to construct the whole BOSS and it is impossible to foresee all changes in the initial stage of BOSS construction, each CIO/CTO faces the challenge of how to evolve or replace these legacy systems to support changing market requests. This is a frustrating thing.

Owing to ROI constraints, the decision to renovate a legacy BOSS component or replace it with new one poses a dilemma. However, regardless of which solution is chosen, the following difficulties are inevitable in the process of upgrading BOSS.

■    Communication with multiple software vendors

■    Integration with heterogeneous architectures

■    Satisfying continuous market demands

■    Expending the life-cycle of existing BOSS components

Addressed Issues and Solution Space

The background of these issues has, so far, been clearly understood. The purpose of this article, however, is to find a practical methodology by which a legacy BOSS component can evolve to fit new requests with minimal pain and cost. The main topics discussed in this article are:

■    What is a suitable methodology to realize BOSS component upgrading?

■    How can this methodology be applied to upgrade BOSS components in a reasonably short time?

■    What are the necessary tools to support this methodology?

According to our study, there are two theoretical foundations in software engineering that can be applied: software maintenance and software evolution. Each of these can support software upgrade, but their purposes are slightly different. The following section will briefly review the two methodologies theoretically.

Literature Review

This section introduces the concepts of software maintenance and evolution, especially the latter, since our approach adopts several methodologies of software evolution.

Software maintenance

Software maintenance is a set of activities which changes the system after it has been delivered. They involve:

■    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 or modifications of system functionality due to organizational or business changes 

■    Preventive maintenance: activities which  attempt to prevent unnecessary changes in the future

 Software maintenance is very important in the lifecycle of software. In fact, costs associated with software maintenance often equal those of software development. The main focus of maintenance is the addition and modification of functionality, whereas fault repair and software adaptation receive much less attention, as shown in Figure 1.

As time progresses, maintenance becomes much more difficult due to:

■    Staff turnover and the discontinuation of knowledge

■    Changes in staff skills as main-trend technologies change

■    The age of original software and the increased cost of maintaining its structure

■    Contractual responsibilities on a maintenance team, which may limit the software’s capability and the allocation of money for maintenance tasks

Software evolution

Prof. Meir M. Lehman et al. have identified a set of behaviors in the evolution of proprietary software. These behaviors (or observations) are known as Lehman’s laws, and they include:

■    Continuing change: Programs used in a real-world environment must necessarily change or become progressively less useful in that environment.

■    Increasing complexity: As a program evolves, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.

■    Self regulation: Program evolution is a self-regulating process. System attributes such as size, time between releases, and the number of reported errors is almost invariable for each system release.

■    Organizational stability: Over a program’s lifetime, its rate of 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 release is approximately constant.

■    Continuing growth: The functionality offered by systems must 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: Evolutionary processes incorporate multi-agent, multi-loop feedback systems and must be treated as feedback systems in order to achieve significant product improvement.

According to research themes identified by Bennett and Rajlich, aspects of software evolution currently being investigated include requirements, architecture, data, runtime management, service-orientation, and language. Solutions being offered involve reverse and re-engineering, incremental change techniques, managerial issues, software processes, and model evolution. There emerge two prevalent views:

■    What and why: This line of questioning focuses on software evolution as a scientific discipline. It studies the nature of software evolution phenomena, and seeks to understand the driving factors and impacts.

■    How: This line of questioning focuses on software evolution as an engineering discipline. It studies the more pragmatic aspects that aid the software developer or project manager in their day-to-day tasks.

Foundations of approach

The approach proposed here draws on several methodologies of software evolution (see Figure 2). The horseshoe re-engineering model is very popular in realizing software evolution. As shown in Figure 2, a legacy software system can be built into a high-level architecture model, which can then be improved to a restructured model. Finally a new software system can be developed from the restructured model. The agent-based wrapping model is another way of renovating a legacy software system.

Proposal

Our approach is called Software Evolution Enhanced Methodology (SEEM), and it addresses the BOSS domain. It defines the basic practice, process flow, and infrastructure, as shown in Figure 3.

In order to achieve its goal, SEEM defines a process as shown at the bottom of Figure 3. This process comprises a series of internal activities:

■    Stage A: This is the first stage of the SEEM flow. It involves collecting and extracting information from a legacy BOSS component by observing external standards, new technology, and business requests.

■    Stage B: Upon collecting this information, SEEM performs an impact analysis according to evaluation criteria—including priority, cost/expense, and market trends.

■    Stage C: This stage is called “Roadmap Generation”. It determines a suitable approach, such as re-engineering, wrapping, or refactoring, according to the previous analysis.

■    Stage D: This stage involves rebuilding the meta-model of the BOSS component. It primarily impacts architecture, interface, interaction, and data structure. Therefore, the legacy BOSS component can be encapsulated (e.g. transformation, synchronization, and replication) and upgraded.

As these internal activities are ongoing, changes to the BOSS components are ongoing as well. The relationships are described in Figure 3. These changes can be broken down into multiple phases, as described below:

■    Probing: Data collection, configuration, meta-model extraction, and log analysis is performed.

■    Implementation: Strategies such as refactoring, wrapping, re-modeling, replacement, and tailing, are employed to realize implementation according to detailed requests.

■    Simulation & Validation: All implementation results are simulated and validated before commercial launch. Key activities in this stage include preparing a test-case, performing a dry-run, deploying environment, and organizing a team.

■    Migration & Monitoring: All validated results are migrated to the commercial environment. Data, business logic, interface, and interaction models will be changed.

To support these activities and processes, SEEM is built on a standard infrastructure which includes:

■    A UML tool: Unified Model Language (UML) is used to model and describe the request, architecture, and process flow.

■    CVS: Control Version System (CVS) is used for version and release control.

■    A ZSmart framework: ZSmart is a collection of BOSS components provided by ZTE. It is organized as multi-level architecture. The bottom level is called ZSmart framework—an open-structure framework used to implement all non-business requests (e.g. logging, reporting, and messaging).

■    A visualization tool: Since BOSS is too large to image, the visualization tool can help designers, developers, and testers easily identify changes and issues.

■    A refactoring tool: This is always included as a popular development tool (e.g. Eclipse and NetBeans).

■    A monitoring tool: This aids in quickly understanding changes which are occurring in the whole process.

 This approach features end-to-end capability, multiple tactics, wrapper support, extreme programming tolerance, a staged process, UML standardization, simulation embedding, separate internal/external activities, legacy technology compatibility, eTOM addressed, unified processes, and it is meta-model driven. 

Summary

Using SEEM based software evolution, software maintenance, and a Zsmart framework, a legacy BOSS component can be upgraded with less cost and effort. The main advantage of SEEM is that it balances maintenance and evolution, extends the life-cycle of legacy BOSS component, and supports a heterogeneous environment.