A New Software Engineering Paradigm Based On Nonlinear ... · Web viewNSE (Nonlinear Software...
Transcript of A New Software Engineering Paradigm Based On Nonlinear ... · Web viewNSE (Nonlinear Software...
NSE (Nonlinear Software Engineering) :A New Revolutionary Paradigm For Software
Engineering
Jay Xiong1 2
1 International Software Automation, Inc. (being reformed now), USA
2 ISA Shanghai, Ltd., 471 Guiping Road, Building 4, floor 3, 200233, Shanghai, China
To whom correspondence should be addressed (E-mail): [email protected], [email protected]
Software has become an indispensable technology and a driving force for science, engineering, and
business. But unfortunately, the old established software engineering paradigm, based on linear thinking
and simplistic science, is incomplete, unreliable, and blind in responding to changes. This paper presents
a revolutionary software engineering paradigm, NSE (Nonlinear Software Engineering), based on
nonlinear thinking and complexity science. Methodology comparison and primary applications show that it
is possible for NSE (with its support platform offering automated tools and automated traceability for defect
prevention in the entire software lifecycle, particularly in software maintenance) to help software
organizations double their productivity, halve their costs, remove 99% to 99.99% of the defects in their
software products, and efficiently handle the issues of software complexity, invisibility, changeability, and
conformity.
An introduction. Today, computer software is
playing a very important role in the development of
all kinds of businesses in the world. It affects almost
all aspects of our lives and our everyday activities
(1). But unfortunately, there are many critical
problems existing with the old established software
engineering paradigm: low productivity and quality,
high cost and risk. The root cause comes from an
attempt to solve a non-linear problem with linear
processes. In fact, all people problems and issues are
non-linear because they exist in a dynamic rather than
a static environment (2). For solving these critical
problems efficiently, a new revolutionary software
engineering paradigm, NSE, based on nonlinear
thinking and complexity science is presented. NSE
paradigm consists of ten parts (fig. S0.3). The
essential difference between the old established
software engineering paradigm and NSE is how to
handle the relationship between the whole and its
parts of a software system. The former adheres to the
superposition principle of the whole is the sum of its
parts so that nearly all software development tasks
are done locally, such as the implementation of
requirement changes. The latter complies with the
Holism principle, that a software product is a
complex adaptive system having multiple interacting
agents (components), of which the overall behavior
and characters cannot be inferred simply from the
behavior of its individual agents, so that nearly all
software development tasks are done globally to
prevent defects in the entire software lifecycle. How
can a lifeless piece of software be “Adaptive”? With
NSE, a software product is redefined as and
delivered with a computer program and all
documents including the test cases plus the
database and AI tools supporting testability,
visibility, changeability, conformity, traceability,
and maintainability to make it adaptive (see fig.
S3.5).
NSE has been implemented. Some primary
applications show that NSE paradigm can make
revolutionary changes to almost all aspects in
software engineering.
The problems addressed. The old-established
software engineering paradigm itself has become an
obstacle rather than a driving force for software
development in the 21st century because:
(1) It is incomplete. As pointed out by Scott W.
Ambler, etc.: “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.” (3) Not
only does the Unified Process not support
software maintenance, but all other existing
methodologies and process models do not
support software maintenance either: there
has never been a defined process for software
maintenance! As described by Jaron Lanier,
“The problem with software is that we've never
learned how to control the side effects of
choices, which we call bugs.” (4)
(2) It is unreliable. As stated by Capers Jones,
“Major software projects have been troubling
business activities for more than 50 years. Of
any known business activity, software projects
have the highest probability of being cancelled
or delayed. Once delivered, these projects
display excessive error quantities and low levels
of reliability.” (5)
(3) It is blind in responding to requirement
changes. The implementation of requirement
changes is done locally with a linear waterfall
process model or a uni-directional iterative
model without facilities for automated
traceability. The fundamental problem with
program maintenance based on the old-
established software development paradigm is
that “fixing a defect has a substantial (20-50
percent) chance of introducing another.”(6) The
result is that, as Pressman points out, “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!”(7)
(4) The documents created with the old established
software paradigm are often inconsistent with
the source code after code modification, etc.
The establishment of the NSE paradigm for
software engineering. The NSE paradigm is
established through the use of a paradigm-shift
framework, the Five-Dimensional Structure Synthesis
Method (FDS) shown in Fig. 1. There are five axes
representing the five elements in FDS: People/Logic,
Environment, Phases, New Paradigm, and Principles
of Complexity Science (with extended principles
particularly used for software engineering). Using
FDS, it is required to comply with the principles of
complexity science, which will be the driving force
for a new industrial revolution in the 21st century
because various industries are becoming increasingly
aware that traditional approaches to design and
engineering are failing to keep up with the increasing
scale of today’s systems. (8) [Supporting Online
Material, SOM s0]
Fig. 1: A modified version of the Five-Dimensional
Structure Synthesis Method (FDS)
There are ten parts with NSE [see SOM S0]:
(A) The NSE Process Model (Fig.2) [SOM S1]
Highlights of the NSE Model:
1) solves critical problems facing with linear
models efficiently
2) Based on:
a. Nonlinear thinking and complexity science
b. Bidirectional multi-track traceability among all
artifacts in the lifecycle
c. Defect prevention and defect propagation
prevention – “An ounce of prevention is worth a
pound of cure!”
d. Real-time synchronization, parallelism,
communication, updates, etc.
3) Already commercially implemented!
Fig. 2: NSE Model. (A) The pre-process. (B) The
main process. (C) The facility for bi-directional
traceability which works through (a) test case
execution and “time tags” for data mapping between
test cases and the corresponding source code (b)
some keywords such as @word@ and @BAT@ for
automatically opening the corresponding documents
traced at a location specified by a bookmark.
(B) The NSE Software Development Methodology.
(Fig. 3) [SOM S2]
Highlights of the NSE Methodology:
a) defect-prevention and traceability driven
b) visual development in the entire lifecycle
c) hierarchical design and incremental integration
e) frequent delivery of working products
f) bi-directional iteration
Fig. 3: A graphical description of the NSE software
development methodology.
(C) The NSE Test System. (Fig.4) [SOM S3]
Fig. 4: Transparent-box software testing method
proposed and implemented by Jay Xiong
Highlights of NSE Test System:
a) combines functional & structure testing together
b) supports Modified Condition/Decision coverage
c) can be dynamically used in the entire lifecycle
d) combines unit and integration testing together
e) also supports embedded software testing
(D) The NSE Maintenance System (Fig. 5) [SOM
S4]
Highlights of the NSE Maintenance System:
a) offers systematic, disciplined, and quantifiable
approach for software maintenance
b) prevents side-effects in the implementation of
requirement changes or code modifications
c) makes it possible to reduce the cost and effort
spent in software maintenance from about 75% of
the total with the old established paradigm to about
25% of the total with NSE (similar to the effort and
cost spent in the development process).
Fig. 5: Defect prevention for requirement changes performed by the NSE support platform, Panorama++: (A)
Perform forward tracing for a requirement change (through the corresponding test cases) to determine what modules
should be modified. (B) Perform backward tracing to check related requirements of the modules to be modified for
preventing requirement conflicts (in this example, two requirements are related). (C) Check what other modules may
also need to be changed, with the modification. (D) After modification, check all related call statements for defect
prevention. (E) Efficient regression testing through related test case selection based on backward traceability. (F)
Perform backward tracing to find and modify inconsistent documents after code modification.
(5) NSE Support Graphics [SOM S5]Highlights of NSE Support Graphics:
a) offers traceable and interactive J-Chart, J-
Diagram, and J-Flow (defined by Jay Xiong)
b) makes the entire software development lifecycle
visible
(6) NSE Document System [SOM S6]
Highlights of the NSE Document System:
a) makes the documents and source code traceable to
each other
b) keeps the documents always consistent with the
corresponding source code
(7) NSE Quality Assurance System (Table 1) [SOM
S7]
Table 1: (A) Ranges of defect removal efficiency,
based on the analysis of 12000 projects. (9) (B)
Detailed comparison on defect removal efficiency.
Highlights of NSE Quality Assurance System:
a) based on defect prevention, defect propagation
prevention, inspection and review in the entire
lifecycle using traceable documents and source
code, deeper and broader software testing, and
quality measurement for entire software system
and any individual module.
b) possible to remove 99% to 99.99% of defects
(8) NSE Project Management System
NSE combines project management and
product development together seamlessly through bi-
directional traceability.
(9) NSE Support Technology
Many automated technologies have been
developed to support NSE, particularly for various
types of bi-directional traceability.
(10) NSE Support Tools and Platforms
Many automated tools have been developed to
support NSE. Those tools are integrated into the NSE
support platforms, Panorama++ and SilverBullet++.
Conclusion. This paper described the new NSE
software engineering paradigm based on nonlinear
thinking and complexity science through the use of a
paradigm-shift framework, FDS. With NSE, almost
all tasks are performed globally rather than locally.
Paradigm comparison and primary applications show
that it is possible for NSE to help software
organizations double their productivity and halve
their cost while removing 99% to 99.99% of the
defects in their software products.
References and Notes
1 Pressman, Roger S., “Software Engineering: A
Practitioner’s Approach.” McGraw-Hill, 2005,
P1.
2 Cityzone, “Process versus Non-Linear Thinking”,
November 24, 2006.
3 Scott Ambler, “A Manager’s Introduction to The
Rational Unified Process (RUP) ”, 2005.
4 Heiss, Janice J., “Coding from Scratch: A
Conversation with Virtual Reality Pioneer Jaron
Lanier, Part One”, (SDN), 2003.
5 Capers Jones, “Social and Technical Reasons
for Software Problems”, CROSSTALK, Jun
2006.
6 Brooks, Frederick P. Jr., “The Mythical Man-
Month”, Addison Wesley, 1995, P122.
7 Pressman, Roger S., “Software Engineering: A
Practitioner’s Approach”, McGraw-Hill, 2005.
8 Capers Jones, “SOFTWARE QUALITY IN 2002:
A SURVEY OF THE STATE OF THE ART”
http://www.SPR.com, July 23, 2002
9 Complexity Science Focus, “WHY IS
COMPLEXITY SCIENCE IMPORTANT NOW?”
www.complexity.ecs.soton.ac.uk/index.php?page=q2
10. I thank Professor Zheng Renjie from Tsinghua
University for his many suggestions. I also thank
my 40 colleagues for their contributions in the
implementation of NSE, particularly Mr.
Jonathan Xiong and Mr. Michael Zhao.
11 Materials and methods are available as supporting
material on Science Online.