1

NSE Software Maintenance Paradigm: Systematic,

Disciplined, and Quantifiable

Jay Xiong

NSEsoftware, LLC., USA

jay@nsesoftware.com

www.nsesoftware.com

Abstract

This paper introduces the NSE software maintenance paradigm established by complying with the

essential principles of complexity science. Software products need to be modified for meeting requirement changes, fixing bugs, improving

performance, and keeping it usable in a changed or changing environment. Unfortunately, with the old-

established software engineering paradigm based on linear thinking and reductionism, a linear model without an

automated facility for bi-directional traceability is used for the entire software development process, so that

software defects introduced into a software product in upstream easily propagate to downstream, and that

software maintenance is performed linearly, partially, locally, qualitatively, and blindly: for the implementation

of a requirement change, the maintainers do not know how many requirements, documents, and source modules

need to be modified; for the modification of a source module, the maintainers do not know how many

requirements and other source modules may be affected; after the code is modified the maintainers also do not

know what test cases are useful for regression testing. Blind and local software modification is time consuming,

costly, and risky. It is why today software maintenance takes 75% or more of the total effort and cost for a

software development. This paper introduces a new revolutionary solution offered by NSEsoftware with its

software development and maintenance platform, Panorama++, to completely solve the critical problems in

software maintenance. The offering includes a nonlinear process model based on complexity science, a new test

approach combining structural testing and functional testing together seamlessly, interactive and traceable

diagrams for code understanding and software visibility, automated facilities for bi-directional traceability, and

tools for defect prevention, intelligent test case selection and minimization, etc. Rough estimation shows that up

to 2/3 of the maintenance effort and cost can be cut.

Keywords: software maintenance, defect prevention, traceability, software testing, nonlinear thinking,

complexity science

1. The Existing Software Maintenance Engineering Paradigm Is Outdated

Software products need to be modified for meeting requirement changes, fixing bugs,

improving performance, and keeping it usable in a changed or changing environment.

But unfortunately, the old-established software maintenance engineering paradigm is outdated

because

(1) It is based on reductionism and the superposition principle that the whole of a

complex system is the sum of its components, so that almost all of the tasks and

activities in software maintenance engineering are performed partially and locally.

(2) The corresponding software development process models are linear ones with no

upstream movement at all – which require software engineers to do all things right at

all times without making any mistakes and wrong decisions, but that is impossible.

(3) With the linear process models, the defects introduced into a software product in

the upper phases easily propagate down to the maintenance phase to make the

2

maintenance tasks much harder to perform as shown in Fig. 1.

Fig. 1 NORMAL DEFECT ORIGIN/DISCOVERY GAPS (Capers Jones, SOFTWARE

QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART)[Jon02]

(4) The corresponding software development methodologies do not offer

“maintainable design” without support of various kinds of bidirectional traceabilities.

(5) It is not systematic – the old-established software maintenance engineering paradigm

does not offer systematic approaches for software maintenance: there is no systematic

software maintenance process model defined.

(6) It is not quantifiable – for instance, when a module is modified, there is no facilities

provided to get quantifiable data about how many requirements and how many modules

may be affected.

(7) It is not disciplined – there is no engineering approach and model defined to guide

maintainers to perform software maintenance step by step to prevent side-effects and

ensure the quality of the modified products.

(8) It is invisible – the maintenance engineering process and the results obtained are

invisible, making them hard to review and evaluate.

(9) It is blind – for instance, after the implementation of a requirement change or code

modification, it requires the maintainers to use all test cases to perform regression

testing blindly, no matter whether a test case is useful or useless to re-test the modified

software product.

(10) It is costly - as pointed out by Scott W. Ambler, “The Unified Process suffers from

several weaknesses. First, it is only a development process… it misses the concept of

maintenance and support…. It’s important to note that development is a small portion of

the overall software life cycle. The relative software investment that most organizations

make is allocating roughly 20% of the software budget for new development, and 80%

to maintenance and support efforts.” [Amb05]

(11) It makes a software product being maintained unstable day by day – as pointed

out by Frederick P. Brooks Jr.,“The fundamental problem with program maintenance is

that fixing a defect has a substantial (20-50 percent) chance of introducing another. …

All repairs tend to destroy the structure, to increase the entropy and disorder of the

system.” [Bro95-P120]

3

(12) It makes a software product developed by others much harder to maintain at the

customer site – today a software product is delivered with the program, the data used,

and the documents separated from the source code without bidirectional traceability and

intelligent agents (intelligent tools) to support testability, visibility, changeability,

conformity, reliability, and maintainability.

(13) It is easy to become a project killer or even a business killer - as pointed out by

Roger S. Pressman, “Over three decades ago, software maintenance was characterized

as an ‘iceberg’. We hope that what is immediately visible is all there is to it, but we

know that an enormous mass of potential problems and cost lies under the surface. In the

early 1970s ,the maintenance iceberg was big enough to sink an aircraft carrier. Today,

it could easily sink the entire navy!” [Pre05-P409]

2. Outline of the NSE Software Maintenance Paradigm

The revolutionary solution offered by NSE for software maintenance will be described in detail in

this paper later. Here is the outline of the solution:

（1） It is based on complexity science by complying with the essential principles of

complexity science (see Fig. 2), particularly the Nonlinearity principle and the Holism

principle that the whole of a complex system is greater than the sum of its components –

the characteristics and behaviors of the whole emerge from the interaction of its

components, so that with NSE almost all of the tasks and activities in software

maintenance engineering are performed holistically and globally.

Fig. 2 NSE software maintenance paradigm is established by complying with

the essential principles of complexity science through the innovated

paradigm-shift framework, FDS (Five-Dimension Synthesis Method)

（2）The corresponding software development process model is a nonlinear one with

two way iteration supported by automated and self-maintainable traceabilities to

prevent defects introduced into software products by the product developers and the

customers. The NSE Process Model includes the preprocess part and the main process

4

part supported by an automated and self-maintainable facility for bi-directional

traceability using Time Tags automatically inserted into both the test case description

part and the corresponding test coverage database for mapping test cases and the tested

source code, and some keywords to indicate the related document types such as

@WORD@, @HTML@, @PDF@, @BAT@, and @EXCEL@ written in the test case

description part followed by the file paths and the bookmarks to be used to open the

traced documents from the specified positions.

（3）With the nonlinear process models, most of the defects introduced into a software

product can be efficiently removed through defect propagation prevention mainly by

dynamic testing in the entire software development life cycle using the Transparent-box

testing method to combine functional testing and structural testing together seamlessly:

to each test case it not only checks whether the output (if any, can be none when the

method is applied in the requirement development phase and the design phase - having

an output is no longer a condition to use this software testing method dynamically) is the

same as what is expected, but also helps users to check whether the real execution path

covers the expected one specified in J-Flow, and automatically establishes bidirectional

traceability among the related documents, the test cases, and the source code to help the

developers remove inconsistency defects. NSE complies with W. Edwards Deming’s

product quality principle, “Cease dependence on inspection to achieve quality.

Eliminate the need for inspection on a mass basis by building quality into the product in

the first place.” [Dem82] Fig. 3 shows the difference in software quality assurance

between the old-established software development methodologies and the NSE software

development methodology.

Fig. 3 A comparison in quality assurance between the old-established QA paradigm

and the NSE QA paradigm

(4) The corresponding software development methodology offers “maintainable design”

supported by various kinds of bidirectional tracreabilities for defect prevention, defect

propagation prevention, and side-effect prevention in the implementation of requirement

changes and code modification – as pointed out by Frederick P. Brooks Jr., “Clearly,

methods of designing programs so as to eliminate or at least illuminate side effects can

have an immense payoff in maintenance costs.” [Bro95-P120]

5

(5) It is systematic – the NSE software maintenance engineering paradigm offers systematic

approaches for software maintenance: there is a systematic software maintenance

process model defined to guide users to perform software maintenance holistically and

globally (see section 3).

(6) It is quantifiable – for instance, when a module or even only one statement of the source

code is modified, the NSE software maintenance engineering paradigm can help users

get quantifiable data on exactly about how many requirements and other modules may

be affected. Fig. 4 shows that if a class member function ArraySorted::Swaps is

modified, seven related modules may also need to be modified.

Fig. 4 Quantifiable software maintenance example 1: when a class member function

ArraySorted::Swaps needs to be modified (for instance, the number of the parameters

should be changed), seven related modules may also need to be modified

Fig. 5 shows that correspondingly there are nine statements calling the class member

function ArraySorted::Swaps - they should be checked to prevent the possible

inconsistency defects.

Fig. 5 Quantifiable software maintenance example 2: when a class member function

ArraySorted::Swaps is modified, nine related statements calling it should be checked for

consistency.

6

Fig. 6 shows that if a global variable “vw” is modified, 37 modules need to check for

consistency.

Fig. 6 Quantifiable software maintenance example 3: if the variable “vw” is modified,

then 37 modules need to be checked for consistency.

(7) It is disciplined – there is a defined engineering approach and model to guide

maintainers to perform software maintenance step by step to prevent side-effects, ensure

the quality of the modified products, and perform regression testing efficiently.

(8) It is visible – with NSE the maintenance engineering process and the results obtained are

visible and easy to review and evaluate, because it is supported with a set of Assisted

Online Agents including software visualization tools to automatically generate huge

amount of graphical documents which are interactive and traceable – see Fig. 4 and Fig.

5 again.

(9) It is not blind – for instance, after the implementation of a requirement change or code

modification, it helps the maintainers efficiently select the useful test cases through

backward traceability and test case minimization for performing regression testing

efficiently.

(10) It is not costly – it is possible for the NSE software maintenance engineering paradigm

to help software organization to greatly reduce the cost and effort spent in software

maintenance because:

With NSE, quality assurance is performed in the entire lifecycle through

defect-prevention and defect propagation prevention using the Transparent-box

7

testing method dynamically, plus inspection using traceable documents and

traceable source code, so that the defects propagated into the maintenance

phase are greatly reduced.

The implementation of requirement changes and code modifications are

performed holistically and globally, rather than partially and locally.

The side-effects in the implementation of requirement changes and code

modification are prevented through various kinds of automated and self-

maintainable traceabilities.

Regression testing after software modification is performed efficiently through

backward traceability to select the corresponding test cases and test case

minimization to select the useful test cases to greatly reduce the required time,

resources, and cost.

(11) It makes a maintained software product stable – with NSE there is no big difference

between the product development process and the product maintenance process: in both

processes, requirement changes are welcome to support the customers’ market strategy,

and implemented holistically and globally with side-effect prevention through various

kinds of traceabilities.

(12) It makes a software product developed by others easy to maintain at the customer

site – even if a software product is maintained at the customer site rather than the

product development site, software maintenance engineering can be performed with

almost the same conditions as those at the product development site, because with NSE

the delivery of a software product includes not only the computer program, the data

used, and the documents traceable to and from the source code, but also the database

built through static and dynamic measurement of the program, and a set of Assisted

Online Agents to make the software adaptive and truly maintainable (see section paper4

to know how those Assisted Online Agents work together to support testability,

reliability, changeability, visibility, conformity, traceability, adaptability, and

maintainability).

(13) The NSE software maintenance engineering paradigm becomes a key to make it

possible for NSE to help software organization double their productivity and halve

their cost in their software product development – with the NSE, not only are most

defects removed in the development process through defect prevention and defect

propagation prevention, but new defects are also prevented in the maintenance process

through various kinds of traceabilities and dynamic testing using the Transparent-box

testing method - all software maintenance tasks are performed holistically and globally

with side-effect prevention, so that the effort and cost spent in the software maintenance

will be almost the same as that spent in the software development process – each one

takes about 25% of the original cost: about half of the total effort and total cost can be

saved as shown in Fig. 7.

8

Fig. 7 Estimated effort and cost spent in software development and software

maintenance

(14) It can be efficiently applied to the worst case where no documents exist at all – in

this case, the NSE software maintenance engineering paradigm will use the Assisted

Online Agents to automatically generate huge amount of various documents through

reverse engineering, then help users set bookmarks in the generated documents. After

users re-design the test cases with some simple rules and re-test the product, the NSE

software maintenance engineering paradigm will automatically establish various

automated and self-maintainable traceabilities to make the product adaptive and

maintainable.

3. Description of NSE Software Maintenance Engineering Paradigm

With NSE a software maintenance process model is defined as shown in Fig. 8.

9

Fig. 8 NSE Software Maintenance Process Model

As shown in Fig. 8, the major steps for performing software maintenance engineering are as

follows:

Step 1: Begin.

Step 2: Check the maintenance task type. If it is for the implementation of a new requirement, go to

step 3; otherwise go to step 4.

Step3: Perform the implementation of the requirement through the preprocess and the main process

regularly as what was performed in the software development process.

Step 4: Is a critical change of the requirement? If not, go to step 14.

Step 5: Perform solution design.

Step 6: Go through the solution review process.

Step 7: If the review result is not good enough, go to step 5.

Step 8: Perform risk analysis.

Step 9: If the risk analysis result is good enough, go to step 12.

Step 10: Give up? If not, go to step 5.

Step 11: End the process without changes.

Step 12: Is a critical change? If so, go to step 3.

Step 13: Find the modules to be modified through forward traceability (from requirement -> the

corresponding test cases -> the corresponding source code, see section paper4 for an application

example). Go to step 15.

Step 14: Is it not for changing the source modules? If so, go to step 17.

10

Step 15: Find the related requirements and documents through backward traceability from each module

to be modified.

Step 16: Make modifications carefully to satisfy all of the related requirements (often a module is

used for the implementation of more than one requirement) and update the related documents. If

necessary, add some new modules and perform unit testing (including memory leak measurement

and performance measurement) for the new modules. Go to step 18.

Step 17: Is it to change a global or static variable? If not, go to step 20 (end the process).

Step 18: Find the related modules through calling path analysis from each module/variable that is

modified, and modify them too if necessary.

Step 19: Find the related test cases through backward traceability and perform test case minimization,

then perform regression testing efficiently (including MC/DC test coverage analysis, memory leak

measurement, performance measurement, quality measurement, and runtime error location through

execution path tracing, see section paper4 for an example), and version comparison holistically.

Step 20: End the process.

4. Application

With NSE a software product will be delivered with the computer program, the data used, and the

documents traceable to and from the source code, plus the database built though static and dynamic

measurement of the program, and a set of Assisted Online Agents to support testability, visibility,

changeability, conformity, traceability, and maintainability.

The following figures show an example for maintaining a sample program, a calculator. These

graphical figures are provided by the Assisted Online Agents either in the product development site or

the customer site.

Fig. 9 shows one of the Assisted Online Agents, the interface agent - NSE-CLICK

Fig. 9 The NSE-CLICK interface

All other Assisted Online Agents are integrated together, and can be executed from the

interface.

Fig. 10 shows the document hierarchy description table using bookmarks to indicate the

relationship of the documents and the test cases with which we can find what test cases are used for

testing the requirement(s) to be changed – for instance, we want to change the ADDITION

requirement.

11

Fig. 10 From the requirement(s) to be changed to find the related test cases through the

document hierarchy description table

Fig. 11 shows how we can perform forward tracing from the corresponding test case(s) to

find what documents and the source code modules used for the implementation of the

requirement need to be modified - click on the test case (automatically shown in blue) in

the test case window, then the corresponding source code modules will be highlighted

(automatically shown in red) in the control flow window showing the entire product.

Fig. 11 Perform forward tracing from the test case(s) to find the related documents and the

program modules (automatically shown in red), and then check what module(s) needs to

be modified (updated)

12

Fig. 12 shows how we can perform backward tracing from the module(s) to be modified

to find how many documents and requirements are related (in this case, two requirements

are related, so that the modification must satisfy both).

Fig. 12 Perform backward tracing from the module(s) to be modified to find how many

documents and requirements are related (in this case, two requirements are related, so that

the modification must satisfy both)

Fig. 13 shows how we can trace a module to be modified from the call graph shown in J-

Chart notation to highlight all of the related modules which may also need to be modify

correspondingly.

Fig. 13 Tracing a module to be modified from the call graph to highlight all the related

modules which may need to be modified correspondingly

13

Fig. 14 shows how we can find all the related statements calling the module to be

modified for ensuring the consistency among them from the diagrammed source code and

shown in J-Diagram.

Fig. 14 Diagrammed source code shown with a facility used to trace a module to be

modified with all the related statements calling that module, for ensuring the consistency

Fig. 15 shows how to select the related test cases from a source code segment (a set of

statements with the same execution condition without a decision statement) modified for

efficient regression testing after code modification (in this example, only one test case is

selected – it means other test cases cannot be used to re-test that segment).

Fig. 15 Tracing a source code segment (automatically shown in blue) to select the related

test case(s) (automatically shown in red) for efficient regression testing.

14

Fig. 16 shows how to update the related documents after software modification through

backward traceability.

Fig. 16 Updating the related documents after software modification through backward

traceability

If a global or static variable is modified, all modules using that variable must be checked

to prevent inconsistency as shown in Fig. 17.

Fig. 17 Preventing inconsistent defect in variable modification

15

Usually less than 20% of the test cases are really useful for retesting a modified software

product. Fig. 18 shows the result of the test case efficiency analysis which will be the

basis for test case minimization.

Fig. 18 Sample result of test case efficiency analysis

Based on the result of the test case efficiency analysis, test case minimization can be

performed to get a minimized set of test cases (see Fig. 19) which can be used to obtain

the same test coverage results obtained by all test cases – usually a test which found a

defect will be included into the minimized set of test cases because its execution path will

be different from those test cases which have not found a defect.

Fig. 19 A result of test case minimization, to be used for efficient regression testing

16

To a software product with a Graphical User Interface (GUI), we can selectively play the

captured GUI operations back automatically through traceability as shown in Fig. 20.

Although there is only one file used to store the captured GUI operations for many test

cases, and only one batch file used to play the captured GUI operations back, using the

Time Tags we can selectively play the corresponding GUI operations back for each test

case separately.

Fig. 20 Selectively playing the captured GUI operations back automatically

After modification, the following testing should be performed to ensure the quality:

(a) MC/DC test coverage analysis to the modified modules

(b) Memory leak and memory usage violation check

(c) Performance analysis to see whether the modified modules may become performance

bottlenecks – if so, perform refactoring with the modified modules

(d) Quality measurement to make sure that the modified modules satisfy the required quality

standard

If new defects are found after the modification, perform runtime error type analysis, trace the

runtime error execution path, and locate the detailed error locations (sometime the error may be

introduced earlier but are found later).

Fig. 21 shows the execution path traced from a runtime error.

17

Fig. 21 A program execution path traced from a runtime error

When some new defects are found after software modification for a complex product, perform

holistic version comparison to locate the problems better as shown in Fig. 22.

Fig. 22 Holistic software version comparison for a complex product (here changed

modules are shown in red, un-changed modules in blue, deleted modules in brown, and

added modules in green)

18

5. The Major Features

As described in the NSE software maintenance process model and shown in the application

examples, the major features of NSE software maintenance engineering paradigm are briefly

summarized as follows:

(a) Based on complexity science

(b) Performed holistically and globally

(c) Side-effect prevention driven

(d) Supported by various traceabilities

(e) Visual in the entire software maintenance process

(f) Intelligent in the test case selection for regression testing through backward traceability

(g) Systematic, quantifiable, and disciplined

6. Conclusion

Today software maintenance takes 75% or more of the total effort and total cost in software

system development, because the existing software maintenance engineering paradigm is based on

reductionism and the superposition principle, so that almost all of the tasks and activities in software

maintenance engineering are performed partially and locally.

This paper presented the NSE software maintenance engineering paradigm based on complexity

science. With the NSE software maintenance engineering paradigm, almost all software maintenance

tasks/activities are performed holistically and globally with side-effect prevention in the

implementation of requirement changes and code modifications through various traceabilities.

Theoretical analysis and preliminary applications show that compared with the old-established

software maintenance engineering paradigm, it is possible for the NSE software maintenance

engineering paradigm to reduce about 2/3 of the total effort and total cost in software maintenance to

help software organizations double their productivity and halve their cost in their software product

development.

References

[Amb05] Ambler S W. A Manager’s Introduction to The Rational Unified Process (RUP), Ambysoft.

2005

[Bro95-P120] Brooks, Frederick P. Jr., “The Mythical Man-Month”, Addison Wesley, 1995, P120

[Dem82] Deming W E. Out of the Crisis. MIT Press, 1982.

[Jon02] Jones, Capers, SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE

ART, Six Lincoln Knoll Lane， Burlington, Massachusetts 01803 http://www.SPR.com July 23,

2002

[Pre05-P409] Pressman, Roger S., “Software Engineering: A Practitioner’s Approach”, McGraw-Hill,

2005, P409