1
NSE Software Maintenance Paradigm: Systematic,
Disciplined, and Quantifiable
Jay Xiong
NSEsoftware, LLC., USA
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
Top Related