About Us
Next Step

  • Featured White Paper

    Improving productivity and saving money with an Executive Assessment
    Download Now
Technical Resources
Online Assistance

 

Software Quality

Software Quality is a very important factor in deciding whether to retire or modernize a legacy software application. If the system was properly structured to meet its requirements, contained modularity in its design and was not tied to the architecture upon which it was implemented, then it is probably worth modernizing. Poorly designed software will be difficult to modernize and even more difficult to continue to maintain. Even quality software can be made inefficient by poor maintenance over its lifetime. Lost documentation or non-existent documentation is many times responsible for maintenance engineers misunderstanding how the internals of complex applications work. Modifying the wrong module or hard-coding variables that were designed to handle multiple uses short circuits the functionality and makes modernization more difficult. Analysis of the software and identifying key metrics that indicate software quality is an important first step.

What is Software Quality Assurance and why is it important to legacy modernization?

Quality Assurance is defined by Wikipedia as “the activity of providing evidence needed to establish quality in work, and that activities that require good quality are being performed effectively.” Software Quality Assurance or SQA is “a means of monitoring the software engineering processes and methods used to ensure quality.”¹ Software Quality Assurance usually requires a quality management system to be established so that audits of software quality can be measured against it. In legacy modernization, SQA is important to determine the environment or historical background of a given software system. A key factor in determining whether legacy software applications are viable in the future is assuring the quality of the existing system. This effort is usually part of the Assessment process and incorporates components of what the IT industry calls Software Assurance. With Software Quality Assurance, the functionality, integrity, modularity and reliability of software applications is measure with a series of metrics developed specifically for software applications. This is increasingly important for the functionality of the systems to be evaluated with industry accepted criteria to determine assessing software risks. Poor quality, as defined with a number of metrics is especially easy to detect early in the life cycle of most applications and indicates that there will be a high degree of risk later in the life cycle. For example, when assessing legacy applications, an inadequate design could be the result of poorly written requirements. This can cause performance problems well after the system is implemented, tested and accepted. In order to identify key facets of software quality and potential risks, the IT industry has developed several metrics that help define and classify the risks. Combining these metrics with others help produce key indicators of Software Quality and can be used to determine the feasibility of modernizing a software application. In order to take maximum advantage of these metrics, as much information as possible needs to be mined from the application’s development history during the Assessment process. Specifically, the Assessment process needs information of the three main stages of software development: requirements analysis, design and testing.


Risk Management

Perhaps the biggest issue with modernizing or replacing legacy software systems is Risk Management. Legacy Systems in many cases have been operating flawlessly for years in spite of their growing maintenance issues or perceived inadequacies of design or lack of integration with newer systems. The risk to replace (and the time) is often much too great for most managers to assume, so many choose to modernize. Even in modernization, there is a risk and that risk needs to be mitigated somehow. Risk management is a way to manage the risk by identifying areas of possible risk, prioritize and then track those risks. Modernization risk management is a combination of two processes: risk assessment and risk mitigation or control. Risk assessment includes the analysis, identification, and prioritization of the risks; risk mitigation includes tracking, resolution, and monitoring. The project risk management process can be summarized as identification of risks, ranking and prioritization of risks, resolution of those deemed significant, and monitoring risks throughout their applicable life.


 

Quality and Metrics

Since the risks associated with modernizing software are directly related to assuring the quality of software being modernized, areas which historically cause problems in software projects need to be identified. Once the most common problem areas are identified, a set of software metrics can be developed from the attributes defining each area that would be useful in the risk management process. The legacy software risk areas typically addressed in the Assessment process are:

 

• Accuracy – measurement of correctness.
• Reliability – proven ability to operate without errors.
• Integrity – measurement of security.
• Dependency – measuring architecture dependence.
• Maintainability – measuring the ease of change.
• Modularity – quantifying the design quality.
• Feasibility – time constraints or requirements.
• Reusability – measuring the application’s coupling.

 

In many cases these risk areas are difficult to quantify and require in depth information not usually present with legacy applications. In the limited cases where this information is available, the consultant should take full advantage of the perspective this additional information can provide. Those risks that can be assessed directly from the existing assets are attributes, while others, like feasibility, are assessed by a combination of attributes and metrics. Each legacy modernization project is different and the importance of some of these listed risks may be higher than others. For example, a set of risks associated with a language transformation might be completely different from a modernization project to integrate two identical software systems made redundant by a merger. The Risk of reusability would not be an issue in the first case, but would outweigh everything else in the second. For accounting functions where money is involved, accuracy and reliability are the biggest risks. Legacy Modernization risk management must have two requirements on the metrics used to measure risk: one - the metrics must be quantifiable or expressed as a number. The second requirement is that the metrics must provide a scale for a tangible indication of risk for modernization. These metrics need to be part of a larger overall measure of risk for a given software module and for the whole project.

The Ripple Effect and Change Impact Analysis

One of the biggest problems with legacy software applications is that they have evolved since their initial deployment and as they have matured, software maintenance has changed their functionality. The extent to which this has affected their design or original intended purpose varies according to the knowledge of the maintenance engineer. The problem is that changing the environment or select portions of applications can cause ripple effects throughout the software, making unintended impacts elsewhere. To minimize this effect, maintenance engineers need to use ripple effect metrics to understand how a change to one component can impact others. This process is called Change Impact Analysis or CIA. Making changes without analyzing their effects can de-stabilize reliable legacy software and lead to a maintenance nightmare. CIA can be used to reduce the amount of maintenance by enabling the maintenance engineer to better understand the code and work within the design parameters of the legacy architecture. CIA can be used for planning and implementing changes required by changes in business rules, acquisitions or changes in regulations by researching the effect of changes in a given software environment. This process usually requires access to software design documents or a full assessment of the application.

There are two types of change propagation involved in the ripple effect:

1. Intramodule propagation of changes - these are changes that propogate from one variable to another within a function

2. Intermodule propagation of changes - these are changes that propogate from one function to another.

In both of these cases, calculations of the ripple effects in an object oriented environment is dependent upon: 1. Polymorphism 2. Implicit parameters 3. Class Relationships

Minimizing the ripple effect can be achieved by adopting and adhering to a Software Quality Model or SQM.

Software Quality Model

An integral part of insuring the success of a legacy modernization project is not only to reduce risk, but to retain or improve the quality of a legacy software system. eCube Systems provides an analysis tool to assist software managers in modeling their software applications and determining a software quality model that quantifies quality for thei application and can therefore identify their needs for modernization. By measuring the metrics against a Software Quality Model, the resulting metrics can be used in the context of their future requirements. By insuring Software Quality, they can concentrate on modernizing the right components for extending the life of their application. Our experience indicates that the modernization project's software risks cannot be evaluated using only metrics and attributes; information on the requirements, architecture, software development team and development history of the software or the development process through the life cycle must also be evaluated. The better the quality of information on a legacy system, the better the Assessment can be. Questions of interest are of the nature:

• Can we identify the requirements for this legacy system?

• Is there a requirements or software design document for the system?

• What architecture dependencies exist in the current system?

• Is there a history of change or source control system used to track changes in the application?

• Are the former developers available to interview?

• Is there a problem tracking system in place or a history of problems for this application?

• What sections of the code are of the highest reliability and maintainability risk?

For more information on eCube’s Software Quality Assurance services or to arrange a confidential interview, contact ev-sales@ecubesystems.com.

¹ from www.wikipedia.org.

eCube's Software Modernization process called Enterprise Evolution enables companies to extend the value of existing applications and business logic by defending it from “software hardening” the growing inflexibility of legacy systems and enabling it to participate as an enterprise service provider.

Correspondingly, risk is the something every business executive has to deal with.  Whether a company decides to “stay put”, redevelop, or modernize, there is risk involved. eCube is committed to balancing the risk, with proven technology and software modernization methods that insure the value of IT efforts moving into the future.  Software modernization means that old applications can be maintained, renewed, evolved, transformed or harvested to speed new development in such a way as to assure the ability of IT to meet its commitments to the business and exceed expectation to reliability.

With NXTera 5.0 and NXTware EV, eCube Systems provides a systematic approach to Software Modernization and  makes legacy evolution the extension of technology equity. This process is based on the evolution of existing business logic and the integration/Implementation of contemporary platforms, such as .NET, J2EE, Web Services, HTTP/Servlets and XML.