• Databorough


  •   
  • FileName: Complexity-Metrics-and-Difference-Analysis-White-Paper.pdf [preview-online]
    • Abstract: DataboroughComplexity Metrics and Difference Analysisfor better Application ManagementSteve KilnerWHITE PAPER Table of ContentsExecutive Summary...................................................................................................................................1

Download the ebook

Databorough
Complexity Metrics and Difference Analysis
for better Application Management
Steve Kilner
WHITE PAPER
Table of Contents
Executive Summary...................................................................................................................................1
Concepts.....................................................................................................................................................2
The Science Behind Software Maintenance..........................................................................................2
Why Audit and Metric Capabilities are Critical for Managing Legacy Applications..........................5
Overview....................................................................................................................................................8
Aspects of Quality in Software Maintenance........................................................................................8
Translating Quality Into Measurable Items.........................................................................................10
How Measurable Items Become Actionable.......................................................................................13
Uses of Historical and Time Series Information.................................................................................14
Version Comparison............................................................................................................................15
Testability............................................................................................................................................18
Use Cases for Metrics Reporting and Difference Analysis......................................................................21
Find the Most Complex Code in My System......................................................................................21
Reducing Size of Application and Maintenance Workload by Removing unnecessary Code..........23
Improving Project Management through Better Information..............................................................24
Cleaning Up your System to Recompile in its Entirety.....................................................................26
Targeting Top 1% of Code that makes your JOB Difficult.................................................................27
Finding Programs most likely to Produce Defects when Modified....................................................28
Identifying Unseen Risk in your Application......................................................................................29
Monitoring Changes in Program Complexity to preserve System Value & Extend its life................30
Analyzing Metrics Time Series Data for Changes in System Complexity.........................................31
Analyzing Differences in Source Code and System Objects in different Versions............................33
Complexity Metrics & Difference Analysis for better Application Management
Executive Summar y
The most chal le ngi ng task in IT pro gra mming is ma int ai nin g an d en hanci ng e xisting
appl icati ons. Th is in fact re presen ts the ma jori t y of wor ldwid e progr ammi ng
budgets.
Unl ike new soft war e d evelo pment, ma int en ance work is sig nifica ntl y i mp acted by
char acteristics of th e software bei ng modi fie d. Modif yin g e xistin g code can be
except ionall y diff icult and pro ne to cost overr uns, d el a ys a nd def ects.
This paper discusses h ow you can improve you r ma int en ance results b y gai ni ng
quantifi able, measur abl e insig hts into your existi ng a ppl icati on. Yo u can get
significant i nfor mat io n for these kinds of qu estio ns:
• How diff icult wi ll it b e to mo dif y this pro gra m?
• This pro gra m is ver y compl ex to mo dif y, shoul d we look for a n a lter native desi gn?
• How diff icult wi ll it b e to test t his pro gra m if we mod if y it?
• W here are ther e risks th at my pro gra mmers are not seein g?
• Do my pro gra mmers’ estimates lin e u p wit h th e comple xit y of th e progr ams?
• Is this progr am to o comple x t o give to a j uni or pr ogr ammer?
• The syst em is becomin g mor e an d mor e compl icate d, wh at ’s th e best a pproach to
simplif yin g it? W here d o we start ?
Many Syst em i app licati ons exce ed a mill ion lin es of cod e. Over th e span o f their
li fet ime the s ystems beco me more a nd more comple x, serio usl y, and adversel y,
i mpacti ng IT soft wa re proj ects and busi ness obj ectives.
This paper discusses h ow to me asure th at comple xit y so yo u can act o n it to lower
your costs, incre ase yo ur thro ug hpu t a nd impr ove yo ur qu ali t y.
“You can not m anag e what you do not mea sure.”
- Bil l He wl ett, Hewlett- Packar d
1
Complexity Metrics & Difference Analysis for better Application Management
5 Concepts
The Science Behind Software Maintenance
The ISO So ftware Qual it y Mo de l d efi ned in 19 96 un der 912 6 a nd up dat ed in 2005
under 250 0n d efi nes the mea ns to measur e the qua lit y of a soft war e app licat ion
wit h six mai n qua lit y char acteristics:
• Functio nal it y
• Rel iabil it y
• Usabi lit y
• Eff icienc y
• Maintai na bil it y
• Port ab ilit y
Of part icular i mp orta nce to ma na gers of le gac y a ppl icatio ns is th at secti on call ed
“Maintai na bil it y” which can be bro ad l y d efi ned as th e abi lit y to make chang es f or
i mprovi ng functi on alit y, improving p erfor ma nce, meet in g compli ance requ ire ments
or fi xi ng d efects. The Mod el de fin es f our character istics tha t describe i n mor e
detail how mai ntai na ble a software syste m is:
• Maintai na bil it y
• An al yza bil it y – the a bil it y to locat e and scope feat ures or fau lts wit hin the
cod e
• Cha ng ea bil it y – t he effor t re quir ed to make cha ng es to the software
• Sta bil it y – the likel iho od tha t cha nges to th e soft war e wi ll resu lt in d efects
• Testab ilit y – th e effort req uire d t o test chang es to the software
Independe ntl y of pro ject specifics, these character istics of th e software work in
concert wit h pro grammers’ skills and their tools to d eter min e ho w wel l the IT
or ganizati on perf orms its ro le of sup port in g a nd enh ancin g app licati ons.
2
Complexity Metrics & Difference Analysis for better Application Management
The primary factors in th e success or fai lure of software mai nte nance t asks ar e the
pr ogrammers ’ skills, to ols a nd the trai ts of t he software bei ng maint ain ed.
Th e Huma n Fa ctor - “It is h arder to rea d a pro gra m th an wri te it.”
This fami liar- soun din g ad age also soun ds suspicio usly like fo lk wisdo m, b ut in fact
there is serious science be hin d it . For ne arl y 2 0 ye ars th e IEEE Int ern ati onal
Conference o n Pro gram Compre he nsion has b ee n meet ing to research and discuss
the challeng es of mai nta ini ng software ap plicat io ns.
Two of the key topics in this sub ject ar ea are:
• The ment al processes peo pl e use to und erstan d soft war e
• The char acteristics of soft wa re that make it easy or di fficul t to un dersta nd
The ISO So ftware Qual it y Mo de l d escrib ed ab ove a ddresses the second of those
points by sta tin g th at crit ical asp ects of soft war e q ual it y are its a nal yz abilit y,
changeabilit y, stabi lit y a nd testab ilit y. W hile all of these characteristics ult imatel y
i nvolve ment al processes of p eople, th e y also lea d to th e h ope th at t he y th at can
be measure d in t hemse lves an d th us, fit int o a qu ali t y ma nag ement pro gra m, which
i n turn sho uld lea d to incre ased pro ductivit y, pr ogra mmin g thro ug hpu t and higher
qual it y.
How then, can on e measure an al yz abi lit y? Ther e is n o d ou bt th at ther e ar e certain
pr ograms th at, upo n a lit tle examina tio n, lea d o ne to quickl y say, “This is ver y
complicat ed. I d o n ot wa nt to main tai n t his pro gra m!”
An experie nced pr ogra mmer ma y lo ok a t a pro gram and come to th at conclusion in
l ess than 60 seco nds.
How does a pro grammer q uickly assess t he ana ly za b il ity of a pr ogram?
That progra mmer is making a quick jud gment o n ho w much effor t is re quir ed to
buil d menta l mo dels of contr ol fl ow and data flo w sufficie ntl y comp let e and
3
Complexity Metrics & Difference Analysis for better Application Management
accurat e to make software chan ges wit h a n a ppro pri ate de gree of confi dence .
W hat did the pro grammer l ook at to make that ju dgmen t?
The Soft war e Factor - Over th e past fo ur decad es a number o f formulas and
models have be en d evelo pe d that atte mpt t o me asure th e compl exit y o f software by
anal yz ing the source cod e. If these measur ements are successful th en it t he y wi ll
give us a go od und erstan din g of a ll those mai nta in abi lit y char acteristics.
W hat do these compl exity models measur e?
Essenti all y the y me asure th e thi ngs tha t are use d in th e me nta l processes and
tasks of a pro gra mmer who is tr yi ng to und erstan d a pro gra m:
• Build a ment al mo del of the contro l fl ow o f th e pr ogr am; i.e, th e seq uence of
events a nd the ir con diti on ing .
• Build a ment al mo del of the dat a fl ow o f th e pr ogr am; i.e. , wha t d ata goes in,
how it’s transfor med , a nd wh at goes out.
• Map re al worl d actio ns t o actions observe d in th e code; e.g., “this is wher e we
give a discou nt to fre qu ent custo mers”.
• Engag e in “ feat ure locat ion ”, wher eb y th e pr ogr ammer is tryin g to fi nd the
code that impl eme nts fe atur es tha t ar e rel evant to the mo dif icatio n task.
• Crea te and test out code mo dificat io n h ypo th eses ; i.e., “desi gn” and “impact
anal ysis”.
• Util ize “ b eacons ” t o d o al l o f th e a bove; i.e. , scan cod e a nd comments for
keywords that signi f y releva nce; e .g., a subr out in e n ame d W RITExxx pr obabl y
out puts some d ata .
• Util ize “ chunkin g” to gr adu all y ag gre gat e un dersta ndi ng of small p ieces of
code int o lar ge an d l arger pi eces.
Some of these processes ar e more me asura ble tha n others:
Control Flow – the actual contr ol flow o f a pro gram is de ter min ed b y the control
operations such as IF, DO, ELSE, etc., as wel l as t he seque nce of state me nts. If
we can measure the n umb er an d comp le xit y of contro l flo w state me nts, plus the
over all nu mb er of state men ts we can gai n some i nsigh t in to ho w cha lle ng ing the
task is to lear n a give n pr ogr am for t he purp ose of modif yin g it.
Data Flow – th e d ata flo w of a pro gra m is d eter mi ned b y fil es th at ar e i npu t, fi el ds
that are transfor me d and files th at are o utp ut. If we can measure t he nu mb er and
complexit y of such fi elds we can gai n some i nsight int o how cha lle ngi ng the task is
to learn a g iven progr am for the pur pose of mod if yi ng it.
Map real world a ctions , featur e locat ion and b eac ons – yo u ma y wo nd er how an
earth these thi ngs could be measure d, bu t in fact th ere are some in dicat ors we can
use. Researchers have sho wn man y ti mes th at we ll place d, we ll writ ten comments
and infor mative l y n amed pr ogra m tokens can gre atl y improve pr ogram
comprehensi on.
4
Complexity Metrics & Difference Analysis for better Application Management
Chun king – Code that is wel l or gan ized and structure d i nto loose l y coupl ed,
cohesive, visua ll y distinct bl ocks is easi er to me nta ll y aggr eg ate a nd comprehend
than pil es of spagh ett i code .
Dat abor ou gh ’s X-Au dit to ol pr ovides metrics for many of these char acteristics as
this paper describes i n d eta il.
Why Audit and Metric Capabilities are Critical for Managing Legacy Applications
Consider thes e tw o fa cts:
• 75% of wo rld wi de IT progr ammi ng bu dg ets are de dicat ed to mai nta ini ng an
enhanci ng existi ng software ap plica tio ns (Forrester Grou p)
• 40- 60% of mai nte na nce pr ogra mmers’ ti me is spent simp l y tr yi ng to understand
the code the y are worki ng on (Softwar e En gin eeri ng Book o f Kn owle dge)
If you put those two facts to get her yo u come to the concl usion t hat th e singl e most
expensive task in al l of IT progr ammi ng is progr ammers tr yin g to un dersta nd code.
What are the impa cts on IT and busin es ses of thi s m ainten anc e chall eng e?
Costs are high: it is more exp ensive to d eliver a given amou nt of fu nctional it y
to the busin ess if it must b e p art of a n e xisti ng app licati on tha n if it is a new
applicat ion
Expen se s di verted to th e old rather than the new : the bu lk of IT
programmi ng bu dge ts go to mai nta ini ng existing ap plica tio ns rath er t han
devel op ing ne w ap plicat io ns that coul d more quickl y provi de competitive
advantag es
Busine ss opp ortuniti es mi sse d: ne w b usiness o pp ortu niti es are missed or
del aye d beca use IT canno t respo nd qu ickl y or cost-effectivel y e no ugh to
enhance existin g s ystems to supp ort ne w busin ess o ppor tuniti es
Operation al and fin anci al ris ks: cha ngi ng h ig hl y compl ex, e xisti ng s ystems
can i ntro duce prod uctio n d efects tha t p ose o pera tio nal or fin ancia l risks
Threat of non- comp lian ce: the busin ess risks n ot me eti ng re gul ator y
require me nts in a ti me l y ma nn er if syste ms cann ot be enh ance d q uickl y e nough
Why is it diffi cult to under stand ex istin g cod e?
At a ver y b asic leve l ther e are t wo t hin gs i nvolved, the pr ogra mmer an d the code.
Programmers ma y b e und er-e qui pp ed, f or wh atever reason, to do th e jo b, an d that
makes it d ifficu lt for th em. Or, th e code is in fact ver y complicat ed, and somewhat
defi ant of human compr ehe nsio n.
5
Complexity Metrics & Difference Analysis for better Application Management
What can be done to im prove ma inten anc e v alue del iver y?
In his book e xa min in g over 12, 00 0 soft war e pr ojects a nd their critical success and
failur e factors, Ap pli ed Soft war e Measur eme nt: Glob al Anal ys is of Productivit y and
Qualit y, lo ng- time software metrics g uru Ca pers Jones provid es some insightful
numbers fro m h is an al ysis of maint en ance prod uctivit y an d q ua lit y.
The fol lowi ng ta bl e shows factors tha t positive l y i mpact main ten ance pr od uctivit y,
and factors th at n eg ativel y i mp act ma int en ance prod uctivit y.
Positive Factors Impact% Negative Factors Impact%
Staff are maintenance specialists +35 Error-prone code -50
High staff application experience +34 Embedded variables, data -45
Table driven variables +33 Low staff experience -40
Low complexity code +32 High complexity code -30
Static analysis tools +30 No static analysis tools -28
Code Re-factoring tools +29 Manual change control -27
Complexity analysis tools +20 No defect tracking tools -22
Automated change control +18 No quality measurements -18
Quality measurements +16 Management inexperience -15
Formal code inspections +15 No code inspections -15
Regression test libraries +15 No annual training -10
Like many such ana l ysis, some of the g ood and bad f actors ar e just the flip side of
each ot her, bu t h ere is wh at sta nds o ut a nd shoul d be hee de d b y th e t hou ght ful IT
manager :
The domi nan t factors that af fect maint ena nce pro ductivity, costs an d qu ality, both
good and bad, are rel ate d t o th e compl exity an d q ua lity of the code , an d th e tools
avai lable to de al wit h t hem .
Here is an oth er vie w of that tab le hig hl igh tin g th e releva nt fact ors, an d the
solutions tha t Dat abor ou gh del ivers to directl y a ddr ess th ose fact ors.
Positive Factors Impact% Negative Factors Impact%
Maintenance specialists +35 Error-prone code (X-Audit) -50
High staff experience +34 Embedded variables (X-Analysis) -45
Table driven variables (X-Analysis) +33 Low staff experience -40
Low complexity code (X-Audit) +32 High complexity code (X-Audit) -30
Static analysis tools (X-Analysis) +30 No static analysis tools (X-Analysis) -28
Code Re-factoring tools (X-Redo) +29 Manual change control -27
Complexity analysis tools (X-Audit) +20 No defect tracking tools -22
Automated change control +18 No quality measurements -18
Quality measurements +16 Management inexperience -15
Formal code inspections +15 No code inspections -15
Regression test libraries +15 No annual training -10
6
Complexity Metrics & Difference Analysis for better Application Management
How can yo u st art ac hie ving thes e ki nds of gai ns in produ ctivit y an d qu ality?
Ver y simpl y, you ne ed bet ter inf orma tio n f or mana ge me nt a nd bet ter infor ma tion for
pr ogrammin g.
Dat abor ou gh sup pli es t wo essent ial tools to i mprove prod uctivit y a nd q ual it y for
maintenance o per atio ns that d irectl y addr ess th e above stat istics as fo un d in over
12,000 software proj ects:
X-An al ysi s – An ap plicat ion cross ref ere nce an d stat ic an al ysis to ol tha t e nables
managers, s ystems ana l ysts and pr ogr ammers to rap idl y a nd thor ou ghl y research
existing app licati ons i n sup port of app licati on en ha nceme nt, de bug gi ng and
documenta tio n t asks.
X-Aud it – Th e f ocus of th is pa per - is a source cod e a nd obj ect a nal ys is system
that provid es metr ics, aler ts a nd ti me series comp ariso ns of t he state of
your applicat ion to en abl e yo u to focus atte nti on o n the areas of yo ur s ystem
most in ne ed of correcti on, improve men t or att enti on.
W ith t his inf ormati on avail abl e yo u can beg in to a nswer some tru l y import ant
questions:
• How can I fin d th e most comple x cod e i n my app licati ons?
• Can I red uce the size of my ap plicat ions, a nd th ere b y th e ma int ena nce workload,
by removin g unn ecessar y code ?
• How can I i mpr oving my pro ject ma na ge men t, estimati ng, sched uli ng, b udgeti ng,
testi ng, etc., thro ugh th e use of t his inf ormati on ?
• How can I clean up my a ppl icati ons so th e y wi ll recompil e i n th eir ent iret y?
• Is ther e a wa y to t arge t th e to p 1% o f my cod e th at makes our jo b t he most
difficu lt?
See the sectio ns on Po pul ar Use Cases for more e xa mpl es a nd d etailed
i nfor mat ion .
7
Complexity Metrics & Difference Analysis for better Application Management
Overview
Aspects of Quality in Software Maintenance
As the ear li er section , Th e Scie nce Be hin d soft war e Ma in te nance , describ es, the
ISO Sof tware Qual it y Mo del bre aks down software qu alit y into six characteristics,
one of which we are most concern ed wi th as ma na gers of le gac y syste ms (sh own
here broken do wn fur ther) :
• Functio nal it y
• Rel iabil it y
• Usabi lit y
• Eff icienc y
• Maintai na bil it y
• Anal yz ab ilit y – th e a bil it y to locat e a nd scope fe atur es or fa ults wit hin
the code
• Chan ge abi lit y – the eff ort requ ire d to make chan ges to th e soft war e
• Stab ilit y – th e l ikeli hoo d t hat chang es to the software will results in
def ects
• Testa bil it y – the eff ort re quir ed to test chan ges to th e soft war e
• Port ab ilit y
In this pap er we are specifical l y concerne d wit h soft war e mai nte nance an d h ow we
can obt ai n usef ul qua lit y i nfor mat ion b y a nal yz ing source cod e a nd oth er s ystem
i nfor mat ion . And even more specif icall y, we ar e concerne d wi th h ow we can
quantif y th at infor ma tio n b y castin g it int o a frame wo rk of metrics .
But let ’s first l ook in an oth er directi on and th ink ab out an oth er set of ISO
standar ds, those tha t p erta in to Sof tware Ma int en ance. ISO 14 764 , Soft wa re Lif e
Cycle Processes f or Ma in te nance d escri bes four cate gori es of ma int enance
activit ies:
• Corrective – fi x d efects
• Adaptive – modi f y the software to keep it usef ul i.e. en ha nceme nts
• Perfective – i mpr ove eit her th e perf ormance or main tai na bil it y of the
software
• Prevent ive –pr ee mpt ivel y de tect or correct la ten t d efects in the software
Var ious stu dies have sho wn th at upwar ds of 80% of tota l activit y is a da ptive, in
ot her wor ds, e nh ancements to th e syst em. T here is some times a vie w th at most of
the work is corrective, but it has a lso be en shown that ma n y tasks pr esent ed by
users as b ug fixes are in fact re quests for chan ges in fu nction al it y. Many
maintenance or ga nizati ons do n ot ful l y d isting uish b etwee n corrective an d ad apt ive
activit ies an d ofte n swi tch staff free l y bet we en th ese t yp es of tasks.
8
Complexity Metrics & Difference Analysis for better Application Management
Key Princi pal: All Software Quality Decl ine s Over Time
However the work is categ orized an d man ag ed, over ti me, th e q ual it y of the
soft war e go es d own. In f act, unl ess actio ns ar e taken to correct it, it is completely
unavoi dable tha t th e q ua lit y of the soft war e g oes do wn over time:
• If the soft war e is mai nta ine d wit ho ut f ull reg ard to mai nta ina bil it y it wi ll
necessaril y b ecome more compl ex, an d t hus its main tai na bil it y qu ali t y wi ll decli ne,
or
• If the soft war e is not mai nta in ed it wil l n ecessari l y beco me less useful to the
evolving user org anizat io n, a nd thus its functi ona lit y q ual it y will di mi nish
The evol utio n of soft war e syste ms over time has bee n studi ed b y a nu mber of
researchers and aca de mics. Prof essor Meir L eh man of Imp eri al Coll eg e London
i dentifi ed a n umber of observati ons of ho w soft war e evolves over time in what is
of ten call ed The Eig ht L aws Of Softwar e Evolu tio n. For th e IT mana ger wi th a big
picture of t he forces at work i n soft war e mai nte nance it is wor th havin g some
awar eness of th ese forces:
1. Con tin ui ng chang e – software must be conti nua ll y a dap ted or it wil l become
l ess a nd less satisf actor y
2. Incre asing compl exi t y – as software is chan ge d it beco mes increasi ngl y
comple x unl ess work is d one to mit iga te the comp lexit y
3. Rel ati onshi p to or gan izati on – th e software e xists wit hi n a framework of
peop le, ma na ge men t, ru les a nd goa ls wh ich crea te a s ystem of checks and
bala nces wh ich sha pe software evol utio n
4. Invar ian t work rat e – over t he life time o f a syste m the amoun t of work
perfor me d on it is esse nti all y the same as ext erna l factors be yon d anyone’s
contr ol drive the evolut io n
9
Complexity Metrics & Difference Analysis for better Application Management
5. Conservat io n of fa mil iari t y – d evelo pers an d users of t he soft war e must
main tai n master y of its conte nt in order to use an d evolve it; e xcessive growt h
reduces master y an d acts as a brake
6. Con tin ui ng gro wt h – seemin gl y simil ar to the first l aw, this observat io n states
that ad dit io nal gr owth is also drive n b y the resource constra ints th at restricted
the or igi na l scope of t he syste m
7. Declini ng q ua lit y – the q ua lit y of the software wil l decli ne u nless steps are
take n to keep it in accord with op erat ion al chan ges
8. Fee db ack syste m – th e evolut io n in fu nctio nal it y a nd comple xit y of soft war e is
governe d b y a multi- lo op, mu ltil evel, mu lti part y fe ed back syste m
Why is this importa nt, or how is it usefu l?
The j ob of most IT ma na gers is t yp ical l y to g et it do ne faster, be tter, cheaper.
(“pick two,” as the sa yi ng g oes) Often u nstate d is t he furt her d irective to
cont inual l y impr ove i n th ose measur ements. Not just to da y, but ne xt ye ar, a nd the
year after.
But implicit in al l of th e a bove is that much of what you do today wi ll slo w you
down tomorrow. Unless, tha t is, yo u take action on th e i mpl icit a dvice of the second
l aw and do work to maint ai n yo ur syste m’s mai nta ina bil it y.
And i ndeed, ma n y IT orga nizat ions wit h a lo ng view of the lif e of th eir software and
its responsiven ess to busi ness ne eds take pro active steps to
m aintai n m aintai nabi lit y
and
m anag e to maint aina bilit y
But how is th at p ossib le? How d o you un dert ake a pro gram of ma int aining
maintai nabil it y an d man agi ng to mai nta in abi lit y?
For that, we retur n to th e wisdo m of Bi ll Hewl ett:
“You cannot man age what yo u do not m eas ure.”
10 Translating Quality Into Measurable Items
Again, this pa per concerns itself wit h wh at asp ects of q ual it y that can b e me asured
by anal yz in g source code and ot her syste m i nfor mat ion . W hat asp ects of q ual it y
cannot be me asured this wa y? We canno t, for e xampl e, measur e h ow wel l the
s ystem functio na lit y me ets b usiness nee ds, since we h ave no wa y in th e system to
measure busin ess ne eds. We can also d o very litt le to measur e syst em rel ia bil it y –
though we coul d per haps measure s yste m avail abi lit y, measuri ng d efects cal ls for a
tool designe d for th at p urp ose.
10
Complexity Metrics & Difference Analysis for better Application Management
What can we mea sure by loo king at the so urce cod e an d s yste m obj ect s?
As ment io ned earl ier, there are some key me ntal processes tha t pro grammers
engage in wh en per for min g mai nte nance. If we can measur e th in gs that rel ate to
these processes we will get some un derstan di ng of t he leve l of ma int ai nabili t y
qual it y:
Control Flow – what cond iti ons contr ol the progr am’s op erat ions and what is
their seq uence ?
Data Flow – wh at are the files and fie lds th at are inp ut, ho w are they
transfor me d, how ar e th e y outpu t?
Map real w orld actio ns, fe ature loc ation and bea con s – wh at is the q ual it y of
names assign ed to progr am tokens a nd the leve l of comment in g?
Chunkin g – to wha t de gree is th e code lo osel y coupl ed a nd cohesive and
readab le ?
If these are th e me nta l processes th at impact maint ai nab ili t y, wh at be measur ed for
them?
Looking at th is in strictl y RPG ter ms we can de fin e a nu mb er of aspects of the
source code that can h el p us measure th ese charact eristics:
RPG Metri cs that indic ate compr ehen sibil ity of Control Flow
• Cycl omatic compl exi t y – b asica ll y a count of Ifs, Dos, FORs, W HENs, etc.
• Greatest dep th of n ested ELSEs.
• Numb er of GOTOs or CABxxs.
• Greatest dep th of n ested IF/ Dos.
• Greatest nu mber of sta tements in an IF/DO block.
• Greatest dep th of l oo ps wi thi n l oops.
• Greatest nu mber of sta tements in a subro uti ne.
• Dept h of subro uti ne calls.
• Uses RPG Cyc le for pr ocessin g.
• Numb er of state me nts with cond iti oni ng ind icators.
• Decisi on densit y.
• Numb er of d eloca lizin g stateme nts.
RPG Metri cs that indic ate compr ehen sibil ity of Data Flow
• Halstea d vol ume – basical l y a measure of the nu mb er of disti nct fi elds a nd their
uses
• Numb er of d ata base files
• Numb er of d evice fil es
• Numb er of EXFMTs/ READs to d ispla y fi les
• Numb er of d ispla y fi le formats with fie lds th at out put to a d ata base file
• Numb er of sub- files in pr ogr am
• Numb er of call ed pro gra ms
11
Complexity Metrics & Difference Analysis for better Application Management
• Numb er of call in g pr ogra ms
• Numb er of fi elds wh ose val ue was set
• Numb er of fi elds wh ose val ue was use d
• Numb er of g lob al fie lds whose value was set
• Numb er of g lob al fie lds whose value was used
• Numb er of fi les u pda ted
• Numb er of pr ogra m-d escri bed in put fil es
• Numb er of pr ogra m-d escri bed ou tpu t fi les
• Numb er of a ppl icabl e OVRDBFs
• Numb er of a ppl icabl e OPNQRYF state men ts
• Aver ag e varia bl e span b y li ne nu mb ers
• Tot al variab le span b y lin e n umbers
• Aver ag e varia bl e span b y subro uti ne count
• Tot al variab le span b y subrou tin e cou nt
• Numb er of d eloca lizin g stateme nts
RPG Metri cs that indic ate compr ehen sibil ity through Knowled ge Ma pp abilit y
• Numb er of n on- hype r-l ocal fi el d n ames of l ess th an x characters
• Numb er of li nes o f commen ts
RPG Metri cs that indic ate compr ehen sibil ity through Chun kabi lit y
• Numb er of actu al lin es of code
• Numb er of actu al lin es of comme nts
• Greatest nu mber of sta tements in a subro uti ne
• Greatest nu mber of sta tements in an IF/DO block
• Numb er of i mpl icit g lob al par ameters i n a proced ure
• Numb er of d eloca lizin g stateme nts
• Maint ain abi lit y i nd ex – a formul a d evelo pe d b y HP thr ou gh experi ence
• Numb er of /COP Y members
• Numb er of state me nts chan ge d/a dde d in t he last 3 0-60- 90- 180- 36 0 d a ys
• Numb er of mont hs i n the l ast 12 mo nths th at ha d on e or mor e statements
added/cha ng ed
Some of these metrics ar e useful in mor e th an on e categ or y and some do not fit
neat l y int o th ese cate gori es or are not perf ect in dicat ors, but nevert he less, it
should be clear that th ere are in fact a number of useful metrics for u nd erstanding
maintai nabil it y an d over all pro gra m comple xit y.
It shoul d a lso b e clear th at t hese metrics can in fact be comp ute d fro m typical
source code, an d in fact, that is precisel y wh at Datab oro ugh ’s X-Aud it tool de livers.
If you ar e a n e xp erie nced progr ammer wh o is ma nag in g a lar ge app licati on, you
may look at t his list and no d yo ur he ad in recogn iti on that ma n y of these thi ngs
would be int eresti ng to h ave i n a sortab le list.
But the real questi on is, how can the se metric s m ak e a mea ningful differ ence?
12
Complexity Metrics & Difference Analysis for better Application Management
How Measurable Items Become Actionable
“What gets mea sured is w hat get s don e.”
- To m Pet ers
The fol lowi ng d iagr am sho ws the t wo primar y wa ys i n wh ich software metrics can
help mana ge a soft war e mai nte nance op erat io n.
The lef t bo x is mean t to show tha t metr ics inf ormatio n can be use d to bri ng bett er
manageme nt an d pl ann in g to you r software proj ects. So me of t he wa ys this
i nfor mat ion can be use d ar e:
• Adjust pro grammi ng estimates, and ther efor e sched ules and costs
• Decide wh ere more thor oug h a na l ysis is necessar y
• Decide wh ich reso urces are most appr opr iat e for a task
• Develo p more ap propr iat e a nd det ail ed testin g p la ns.
• Advise th e b usiness of add iti on al proj ect risks
• Decide on alt ern ative desig n p lans to mini mize chang es to hig hl y comple x code
For more infor mat io n on h ow to use metr ics for th ese pur poses see the use case
Improvi ng Project Ma na geme nt Throu gh Bett er In formati on.
The right bo x is mea nt to sho w th at me trics inf ormati on can b e used h elp yo u keep
your software in a more ma int ain ab le stat e a nd thus preserve its lon g ter m val ue
and abi lit y to respo nd to busin ess n eeds quickl y an d cost-eff ectivel y.
13
Complexity Metrics & Difference Analysis for better Application Management
This t ype of work can be ana l yze d i n a coupl e wa ys, le adi ng to tasks tha t:
• Refactor pro gra ms that cross a certain thr eshol d of comp le xit y, or,
• Refactor pr ogr ams that have shown a l arge increase in compl exit y and ar e
expected to cont in ue to d o so
For mor e infor mat io n o n main tai ni ng mai nta in abi lit y see the fol lo wi ng use cases:
• Monit orin g chan ges in pro gra m comp lexit y to preserve s ystem val ue a nd extend
its usef ul lif e
• Tar get ing th e to p 1 % of code tha t makes you r j ob diff icult
• Findin g pr ogr ams most likel y to pr od uce de fects wh en modif ie d
• Identif yin g unsee n risks i n yo ur ap plicat io n
• Cleanin g up yo ur s ystem so it wi ll reco mp ile in its en tire t y
Uses of Historical and Time Series Information
The metrics discusse d so far have be en poi nt in time metrics, in tha t th e y an al yze
source code and s ystem obj ects at t he time th e metrics dat a is gen erat ed. F or
over all s ystem man ag ement th ere ar e oth er usefu l persp ectives th at invo lve the
dimension of time and chan ge.
One import ant persp ective comes from un dersta ndi ng the chan ge in the comp lexit y
and mai nta in abi lit y of yo ur syste m over time :
In this case metrics d ata coll ected a t two or mor e differe nt po ints in ti me are
compared and the di ffer ences are sho wn.
Some of the purp oses of this sort of a nal ys is are:
• Deter min e t he overal l success of mai nta ini ng ma int ain abi lit y
14
Complexity Metrics & Difference Analysis for better Application Management
• Identif y pro gra ms th at cross a def in ed thr eshol d of maint ai nab ili t y i nto
unmaint ai nab ili t y an d ar e th us candi dat es for Refactor ing
• Identif y pro gra ms wit h sudde n chan ges in comple xit y an d tha t are for ecast t o
cont inu e with t hat tre nd, and ar e thus cand id ates for Refactor in g or other
at tempts to keep ma int ain ab le
• Identif y incre ases in compl exit y whe re th e y were not e xp ected, as a possibl e
i ndicat io n of po or pr ogr ammin g or desi gn
See the use case An aly zi n g Me tr ics Time Seri es Data for Chan ges in System
Compl exity for more inf ormati on.
Version Comparison
Versi on compar ison is a faci lit y th at ena bl es you to comp are two d iffer ent versions
of your app licati on at bot h the source cod e and obj ect levels. Here ar e a few
common scenari os wh ere th is is useful :
• Comp are a versio n of th e a ppl icatio n in use in on e l ocatio n t o th e version in use
at anoth er l ocati on
• Comp are a new version of a p acka ged pro duct rele ase to th e version current l y
i nstall ed in order to un dersta nd the diff ere nces
• Comp are t he curren t stat e of th e ap plicat io n to th e stat e it was in at a point in
ti me in the past
Difference An al ysi s
A product such as Dat abor ou gh’s X-Audit can do these compar isons a nd give
detailed re ports o n b oth source a nd ob ject d iffer ences b etwee n the versio ns.
This i nfor mat ion can poi nt to cha nges th at have to be ma de t o brin g two versi ons
i nto harmon y, or to i nte grat e a ne w version of the source. By comp ari ng versions
from diff eren t p oin ts in time th e a nal ys is can reve al une xp ected chan ges in the
s ystem in the in teri m.
Informati on conta ine d in such a n a na l ysis incl udes:
• Fil es and pro gra ms tha t h ave b een ad de d, cha ng ed or d elet ed
• Fields whose attri but es have chan ged
• Changes i n d ata base relat io nships a nd de pen de ncies
• Business rul es tha t h ave be en chan ged , a dde d or de let ed
• Source stat ements that have be en chang ed, ad de d or del ete d
15
Complexity Metrics & Difference Analysis for better Application Management
Source Comp ariso n
The l ast t yp e of a na l ysis in the ab ove l ist can b ecome ver y involve d as p ote nti all y
many source me mbers ma y h ave be en chan ged . It is import ant that a facilit y be
avai lable to quickl y dri ll down from a chang ed source member to th e specif ic lines
of code tha t h ave b een chan ge d, a dd ed or d elet ed.
A source comp arison tool is essenti al for ana l yzin g the diff ere nces in source code
between the versio ns be ing comp are d. A go od too l sho uld show yo u:
• W hich source memb ers have be en chan


Use: 0.4641