Symptomatic Analysis for Software Maintenance

advertisement
Symptomatic
Analysis for Software
Maintenance
A technology designed for
SERC
Symptomatic
Analysis for
Software
Maintenance
GOAL
Development of a diagnostic and prognostic
system for software that collects data from
various types of sources and applies special
analytical techniques to analyze the data in
real-time to diagnose problems, discern
impending faults, and identify maintenance
procedures.
Most Complex Living Organism
Maintenance (heath management): checkups
and diagnosing illness
Most Complex Product Built by
Humans
Maintenance: (no health management) fixes
and updates
Today’s Software Maintenance
Realities
• Cost of maintenance is very high.
• A system not designed for maintenance cannot have
maintainability retrofitted later.
• Many different opinions of maintainability.
• Each organization develops their own definition and
concentrates on efforts to develop mature production
processes.
• Process maturity is not enough to guarantee the
quality of a specific software product.
– Process evaluation should always be accompanied by
product evaluation.
– PRODUCT CERTIFICATION IS ALMOST NON-EXISTENT !
What can be observed (learned) from
health maintenance?
• Continuous
• Relies on a large number of facts obtained
• Reaches an accurate conclusion depending on
the timing and the sequence of the symptoms
• Case history remains an important tool to
determine the nature of an illness
Future with Symptomatic
Analysis for Software Maintenance
• A holistic infrastructure approach ( similar to
Health Management)
• Continuously measures and evaluates software
products through intelligent, automated
diagnostic and prognostic programs
• Provides feedback to process and product
improvement by imparting practitioners with an
understanding of the condition of their software
today and an assurance of its operational state
tomorrow.
The Foundations for the
Symptomatic Analysis Process
Based on the design metrics research of
18+ years through the SERC
Design metric analysis
Module Signatures
Time-slices
Clones
Error (change) analysis
The design metrics have been
computed on
o
o
o
o
o
o
o
o
Raytheon defense systems
CSC’s STANFINS project
systems from the US Army Research Lab
Magnavox’s AFATDS project
Harris’ ROCC project
three Northrop Grumman projects
PBX system from Telcordia Technologies
telecommunications systems from Motorola
Results:
The design metrics typically identify 90% of
the fault-prone modules.
Module Signature
Algorithmic classification
No incomplete or inconsistent data
A single metric can provide
insight into product or process.
However, in isolation
this is seldom useful.
Tougher questions usually
need more information.
Module Signatures Example
(De, Di, V(G), LOC)
Then the module signature is a 4-tuple,
perhaps
(1,1,0,1)
or equivalently, 13, since
11012 = 1310
Module Signatures
• 2 studies
• 98.5% accuracy in identifying changeprone modules
• False negative were only at ½ percent!
• Classes with “more” changes have
more “1s” in the signature
• Signatures have the potential to predict
the likely number of changes for a given
module
Time (Phase) Based Analysis
• Time-slice transformations on design metrics
• Before & After
Timeslices
Clone Research
• Clone evolution is a novel field
• Current approaches are limited to detecting
only small specialized set of patterns in a
clone’s evolution and generally lack scalability
• Empirical research suggests that some clones
require higher attention than others
• Our newest discoveries
Symptomatic Analysis Architecture
Examples of Merging
and Extracting Data
Module Signature
1011001
Module Signature
0110000
Module Name
Module-1
Module-2
Module-3
Time Signature Clone
.0.0.9.9.9
NO
.0.0.0.64.64
NO
.0.0.0.89.d
NO
COs
4
1
3
Module Name
Module-4
Module-5
Time Signature Clone
.0.0.44.44.44
yes 2022
.0.0.0.50.50
yes 2022
COs
3
1
Potential Benefits
A holistic infrastructure approach, as applied
through the framework, will allow intelligent,
automated diagnostic and prognostic
programs to provide practitioners with an
understanding of the condition of their
software today and an assurance of its
operational state tomorrow.
Questions?
Download