Vedligeholdelsesindekset (MI) er en af de mest anvendte sammensatte målepunkter inden for måling af softwarekvalitet. Det kondenserer tre strukturelle egenskaber: kode, størrelse, kompleksitet og volumen til en enkelt numerisk score, der forudsiger, hvor svær koden vil være at ændre. For moderne sprog er formlen, tærsklerne og værktøjerne veletablerede. For COBOL er situationen mere kompliceret, og de fleste teams anvender enten den generiske formel uden justering eller opgiver kvantitativ måling helt, fordi scorerne ikke synes at svare til, hvad udviklere rent faktisk oplever.
Begge tilgange giver misvisende resultater. Anvendelse af standard MI-formlen på COBOL uden at forstå, hvordan dens komponenter opfører sig i COBOLs syntaktiske kontekst, producerer scorer, der er systematisk forudindtagede på måder, der får programmer af høj kvalitet til at virke marginale, og programmer af lav kvalitet til at virke acceptable. Hvis man helt opgiver måling, efterlader moderniseringsbeslutninger uden det kvantitative grundlag, de har brug for for at kunne forsvares af forretningsinteressenter og for at prioritere afhjælpningsarbejde i forhold til en portefølje af tusindvis af programmer.
Få det fulde billede af COBOL-målinger
SMART TS XL rangerer hvert COBOL-program efter kompleksitet, fan-in og JCL-afhængighedsdybde samtidigt.
Mere infoDen rigtige vej er at forstå, hvad MI-formlen specifikt måler i COBOL, hvor den undervurderer og overvurderer kvalitet, hvilke supplerende metrikker der korrigerer for dens COBOL-specifikke blinde vinkler, og hvordan man kalibrerer tærskler i forhold til din faktiske portefølje i stedet for i forhold til generiske benchmarks afledt af moderne sprogkodebaser. Denne vejledning dækker alle fire, med tilstrækkelig teknisk dybde til at implementere et COBOL MI-program og tilstrækkelig praktisk vejledning til at bruge det til moderniseringsbeslutninger.
Et sidste punkt før mekanikken: Vedligeholdelsesindekset forsøger at give et holistisk overblik over den relative vedligeholdelsesbyrde for forskellige dele af et projekt ved at blande en række forskellige målepunkter. Dette holistiske overblik er værdifuldt for COBOL-porteføljer, netop fordi ingen enkelt målepunkt indfanger det fulde billede. Vedligeholdelsesindekset er udgangspunktet, ikke den komplette historie, men det rette sted at begynde.
Hvorfor vedligeholdelsesmåling er vigtigere for COBOL end for moderne sprog
Måling af vedligeholdelsesvenlighed i en Java- eller Python-kodebase, der er to år gammel, veltestet og vedligeholdt af det team, der skrev den, giver nyttige oplysninger, men er sjældent presserende. Koden er læselig for dens forfattere. Logikken er dokumenteret eller kan udledes af tests. Ændringsomkostningerne er begrænset af teamets fortrolighed.
COBOL-porteføljer i regulerede brancher er forskellige på tre måder, der gør kvantitativ vedligeholdelsesmåling ikke en kvalitetspraksis, men en operationel nødvendighed.
Videnshullet. Det meste COBOL indeholder forretningslogik, der aldrig er formelt dokumenteret. Batchjob skrevet for årtier siden koder regler, som ingen husker. De udviklere, der kan læse koden flydende og estimere ændringsomkostninger præcist, går på pension. De udviklere, der er tilbage, har delvist kendskab til dele af porteføljen. Uden kvantitative målinger afhænger estimering af ændringsomkostninger helt af, hvilken udvikler du spørger, og variationen i disse estimater er høj nok til at gøre projektplanlægning upålidelig.
Skalaproblemet. En typisk COBOL-portefølje indeholder tusindvis af programmer, hvoraf mange ikke er blevet berørt i årevis. Intet team kan manuelt vurdere tusindvis af programmer, før et moderniseringsprogram begynder. Målinger, der kan beregnes automatisk på tværs af hele porteføljen på få timer, erstatter uger med manuel gennemgang.
Kravet om business case. Moderniseringsprogrammer kræver investeringsbegrundelse. Ledere, der godkender moderniseringsbudgetter på flere millioner dollars, ønsker kvantitativ dokumentation for, at investeringen er berettiget. MI-score, tekniske gældsforhold udledt af MI og ændringsomkostningsestimater, der refererer til MI-tærskler, leverer denne dokumentation i en form, der kan præsenteres for ikke-tekniske interessenter.
MI-formlen og dens COBOL-specifikke komponenter
Den mest almindeligt anvendte formel til beregning af vedligeholdelsesindekset er:
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)Microsofts afgrænsede variant, der bruges af de fleste kommercielle værktøjer, kortlægger dette til en skala fra 0-100:
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Hver komponent har specifikke COBOL-relevante overvejelser.
Kodelinjer i COBOL
COBOL-kildefiler indeholder fire opdelinger: IDENTIFIKATION, MILJØ, DATA og PROCEDURE. IDENTIFIKATIONSAFDELINGEN identificerer programmet. MILJØAFDELINGEN beskriver dets runtime-miljø. DATAAFDELINGEN definerer dets datastrukturer. Kun PROCEDURE-AFDELINGEN indeholder eksekverbare sætninger.
Målespørgsmålet: skal LOC tælle alle linjer på tværs af alle fire divisioner, eller kun PROCEDURE DIVISION-udsagn?
I forbindelse med MI-formål øger optælling af alle linjer (inklusive datadeklarationer) LOC betydeligt uden tilsvarende stigninger i udførelseskompleksitet. Et COBOL-program med 400 DATA DIVISION-linjer, der definerer postlayouts, og en PROCEDURE DIVISION på 100 linjer har andre vedligeholdelseskarakteristika end et program med 100 DATA DIVISION-linjer og en PROCEDURE DIVISION på 400 linjer, men rå LOC behandler dem identisk.
Bedste praksis: Til COBOL MI-beregning skal du bruge PROCEDURE DIVISION-sætningens antal (eksklusive tomme linjer, kommentarlinjer og divisions-/afsnits-/paragrafoverskrifter) i stedet for det samlede antal kildelinjer. Dette giver LOC-værdier, der mere svarer til den eksekverbare kompleksitet.
Problemet med COPY-medlemmer: COPY-sætninger inkluderer eksterne kildemedlemmer ved kompileringstid. En COPY-sætning, der udvides til 200 linjer med datadefinitioner, bidrager med én linje til kildefilen, men 200 linjer til det kompilerede program. Nogle værktøjer tæller logisk LOC (post-copy expansion); andre tæller fysiske kildelinjer. Forskellen kan være en størrelsesorden for programmer med stor COPY-brug.
Pas på: Hvis dit MI-værktøj tæller fysiske kildelinjer, vil programmer med omfattende COPY-brug virke mindre og mere vedligeholdelsesvenlige, end de faktisk er. Kontroller altid, om LOC i dit værktøj er før- eller efterkopieringsudvidelse.
Cyklomatisk kompleksitet i COBOL
Cyclomatic Complexity er en kodekvalitetsmåling, der måler forståeligheden og vedligeholdelsen af kode ved at måle antallet af uafhængige stier gennem den pågældende kode. I COBOL omfatter de beslutningsstrukturer, der skaber uafhængige stier:
| COBOL-konstruktion | Cyklomatisk kompleksitetspåvirkning |
|---|---|
IF ... END-IF | +1 pr. IF |
IF ... ELSE ... END-IF | +1 pr. IF (ELSE tilføjer ikke en anden sti) |
EVALUATE ... WHEN | +1 pr. WHEN-klausul |
PERFORM UNTIL condition | +1 pr. INDTIL-betingelse |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 pr. VARIERENDE |
AT END klausul om LÆSNING | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 pr. undtagelseshåndterer |
ON OVERFLOW / NOT ON OVERFLOW | +1 pr. overløbshåndtering |
ON SIZE ERROR | +1 fejlhåndtering pr. størrelse |
Den blinde plet på 88 niveauer: COBOLs betingelsesnavne på 88 niveauer skaber logiske betingelser, der vises i IF- og EVALUATE-sætninger, men som er defineret i DATA DIVISION. Et program med tyve betingelser på 88 niveauer, der hver især refereres til i flere beslutningsstrukturer, har betydeligt mere adfærdsmæssig kompleksitet, end PROCEDURE DIVISIONs sætningstælling antyder. Cyclomatic Complexity tæller beslutningspunkterne, men kan ikke registrere de semantiske relationer mellem navne på 88 niveauer og den logik, der tester dem.
PERFORM THRU implicit kompleksitet: PERFORM SECTION-A THRU SECTION-Z udfører alle afsnit mellem SECTION-A og SECTION-Z. Antallet af afsnit og beslutningsstrukturerne i dem er alle en del af den effektive kompleksitet af PERFORM-sætningen, men CC beregnet på sætningsniveau behandler PERFORM THRU som én sti, uanset hvad der ligger imellem.
Halstead-volumen i COBOL
Halstead Volume er et mål for programmets størrelse og kompleksitet baseret på antallet af operatorer og operander. I COBOL:
Operatorer er COBOL-verber og -nøgleord: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN osv.
Operander er datanavne, literaler og figurative konstanter: dataelementer defineret i DATADIVISIONEN, numeriske og strengliteraler og COBOL-figurative konstanter (MELLEMREMMELSER, NULLERMÆNGDER, HØJE VÆRDIER, LAVE VÆRDIER).
Ordforrådsfaktoren: COBOL er betydeligt mere ordrig end moderne sprog til tilsvarende logik. Et Java-udtryk total = quantity * unitPrice * (1 - discount) er én linje med fire operatorer og fire operander. COBOL-ækvivalenten:
COBOL
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)Dette er nogenlunde ens i operatorer og operander, men overvej en mere kompleks beregning, der i Java kan bruge tre linjer. I COBOL kan det kræve fem eller flere linjer på grund af manglen på udtrykskæder og kravet om at bruge mellemliggende arbejdslagerfelter. Halstead-volumenet vil være tilsvarende højere for COBOL end for tilsvarende Java, simpelthen fordi COBOL udtrykker den samme beregning med flere sprogtokens.
Den praktiske konsekvens: COBOL-programmer vil have højere Halstead-volumener end moderne sprogprogrammer med tilsvarende logik. Højere Halstead-volumen reducerer MI. COBOL-programmer vil derfor systematisk score lavere på MI end moderne sprogprogrammer med tilsvarende kompleksitet, ikke fordi de er sværere at vedligeholde, men fordi COBOL er syntaktisk mere ordrig.
Hvor Standard MI ikke lever op til COBOL: Fire blinde vinkler
Selv korrekt beregnet, overser standard MI-formlen fire dimensioner af COBOL-vedligeholdelse, som har betydelig indflydelse på de reelle forandringsomkostninger.
1. COPY Medlemskobling
En COBOL-kopibog, der er inkluderet i 300 programmer, er en vedligeholdelsesafhængighed, der påvirker alle 300 programmer, når der foretages ændringer i den. Denne kobling forekommer ikke i nogen komponent af MI-formlen. Et program, der inkluderer tyve kopibøger, har 300 implicitte afhængigheder, som MI behandler som ækvivalente med et program uden kopibøger.
Supplerende metrik: Copy Member Dependency Count, antallet af unikke COPY-sætninger i et programs DATA DIVISION. Programmer med høj COPY-kobling kræver konsekvensanalyse før enhver ændring for at forstå, hvilke andre programmer der deler de samme kopibogsdefinitioner.
2. Fan-In (opkaldt antal)
Et COBOL-underprogram, der kaldes af 150 andre programmer, er et højrisikoændringsmål uanset dets MI-score. Et meget vedligeholdelsesvenligt underprogram (MI = 85), der kaldes af 150 programmer, er sværere at ændre sikkert end et dårligt vedligeholdelsesvenligt værktøj (MI = 45), der kaldes af ingen. MI-formlen tager ikke højde for, hvor udbredt et program er.
Supplerende metrik: Fan-In, antallet af forskellige programmer, der kalder et givet program via CALL eller dynamisk dispatch. Fan-in er den primære drivkraft for ændringsrisiko for underprogrammer uafhængigt af deres interne kompleksitet.
3. JCL-afhængighedsdybde
Et COBOL-program, der kaldes af et JCL-job, der har femten downstream-afhængige job, job der kører efter det og afhænger af dets output, indebærer en operationel risiko, der ligger helt uden for MI's omfang. Et program med MI = 55, der kører standalone, er mindre risikabelt at modificere end et program med MI = 80, der sidder i centrum af en kompleks batchafhængighedskæde.
Supplerende metrik: JCL-afhængighedsdybde, dybden af den efterfølgende afhængighedskæde i JCL-jobnetværket. Programmer med høj JCL-afhængighedsdybde kræver et bredere testomfang for enhver ændring, uanset deres interne MI-score.
4. Død kodeinflation
Døde afsnit og sektioner, COBOL-kode, der er defineret, men aldrig kaldet af nogen udførelsessti, oppuster LOC og Halstead Volume uden at bidrage til vedligeholdelsesbyrden af live-kode. Et program med 600 linjer død kode og 200 linjer live-kode har en MI, der straffer det for den døde kode, selvom den døde kode er irrelevant for ændringsomkostningerne.
Supplerende metrik: Procentdel af dødkode, andelen af PROCEDURE DIVISION-sætninger, der ikke kan nås fra nogen produktionsudførelsessti. Høje procentdele af dødkode indikerer, at den MI-beregnede LOC og Halstead-volumen er betydeligt oppustede.
En komplet COBOL-metrikpakke
Ingen enkelt metrik indfanger COBOL-vedligeholdelse. Følgende pakke, brugt sammen, giver et komplet billede:
| metric | Hvad det måler | COBOL-specifik bemærkning | Primær brug |
|---|---|---|---|
| Vedligeholdelsesindeks | Generel nem vedligeholdelse (komposit) | Anvend på PROCEDURE DIVISION-sætninger; verificer COPY-håndtering | Baseline kvalitetsscore; porteføljerangering |
| Cyklomatisk kompleksitet | Antal uafhængige udførelsesstier | Medtag VURDER HVORNÅR, UDFØR INDTIL, VED SLUT, VED UNDTAGELSE | Ændringsindsats pr. program; estimat af antal testcases |
| Halstead Volume | Beregningsbelastning (operatorer + operander) | Forvent højere værdier end tilsvarende moderne sprogprogrammer | Del af MI; sammenligning på tværs af programmer inden for COBOL-porteføljen |
| KOPI Medlemsantal | Afhængighedskobling gennem delte definitioner | Programmer med >15 COPY-medlemmer kræver konsekvensanalyse før enhver ændring | Ændring af risikoklassificering |
| Fan-In (Opkaldt af) | Hvor mange programmer kalder dette | Primær drivkraft for ændringsrisiko for delprogrammer | Migreringssekvensering; ændring af godkendelsestærskel |
| Død kode % | Procentdel af uopnåelig procedurekode | Oppust LOC/HV, hvis ikke udelukket; ekskluder fra konverteringsomfanget | Omfangsreduktion for modernisering |
| JCL-afhængighedsdybde | Dybde af kæden til downstream-batchjob | Kan ikke beregnes udelukkende fra COBOL-kildekoden; kræver JCL-analyse | Risiko for operationel ændring; testomfang |
| Indlejret PERFORM-dybde | Maksimalt indlejringsniveau for PERFORM-kald | Dyb nesting indikerer strukturel kompleksitet, der ikke fanges af CC | Refactoringprioritet |
Tærskelkalibrering for COBOL
Standard MI-tærskler er afledt af moderne sprogkodebaser og gælder ikke direkte for COBOL. Tabellen nedenfor sammenligner standardtærskler med COBOL-relevante ækvivalenter og forklarer justeringsrationalet.
| Score rækkevidde | Standardfortolkning | COBOL-fortolkning | Grundlag |
|---|---|---|---|
| 85-100 | Meget vedligeholdelsesvenlig | Meget vedligeholdelsesvenlig (konsistent) | De bedste COBOL-programmer scorer i dette interval, ren struktur, passende størrelse |
| 65-84 | Moderat vedligeholdelig | Moderat vedligeholdelsesvenlig, gennemgå COPY-kobling og fan-in | Standardgrænseværdier gælder, men supplerende metrikker er vigtigere her |
| 50-64 | Dårlig, refactoring nødvendig | Marginal, vurder i kontekst | Mange velstrukturerede COBOL-programmer scorer her udelukkende på grund af detaljerigdom; brug CC og fan-in til at skelne virkelige problemer fra syntaksartefakter |
| 25-49 | Meget dårlig | Dårlig, sandsynligvis høj CC og/eller overdreven LOC | Programmer i dette område angiver pålideligt strukturelle problemer, ikke kun COBOL-detalje |
| 0-24 | Kritisk, større refaktorering | Kritisk, højeste prioritet for afhjælpning eller tilbagetrækning | I overensstemmelse med standardfortolkning |
Vigtig kalibreringsvejledning: Kør MI på tværs af hele din COBOL-portefølje, før du fastsætter programspecifikke tærskler. Beregn porteføljens median og interkvartilinterval. Indstil din "opmærksomhed krævet"-tærskel til den 25. percentil af din egen portefølje, programmer i den nederste kvartil af din specifikke kodebase, ikke programmer, der scorer under en tærskel afledt af Java-programmer. Denne tilgang er selvkalibrerende og tager højde for den systematiske COBOL-verbosity-effekt.
Brug af MI til moderniseringsbeslutninger
MI-scorer bliver mest værdifulde, når de informerer specifikke operationelle beslutninger. Her er de primære anvendelser.
Migrationsbølgesekvensering. Programmer med høje MI-scorer (velholdte, lav kompleksitet) er de bedste kandidater til tidlige migrationsbølger. De er lettere at validere, mindre tilbøjelige til at indeholde udokumenterede edge cases og har en lavere risiko for at producere uventet adfærd i det migrerede miljø. Programmer med lave MI-scorer bør migreres i senere bølger, efter at teamet har opbygget erfaring og tillid, og efter grundig udvinding af forretningslogik.
Vedligeholdelsesprioritering. Programmer med MI under den 25. percentil, der også har høj fan-in (kaldet af mange programmer) eller høj JCL-afhængighedsdybde, repræsenterer den højest risikable kombination: strukturelt komplekse programmer, som mange andre programmer er afhængige af. Disse er de programmer, der mest sandsynligt vil producere ændringsrelaterede defekter, og som er dyrest at afhjælpe, når de gør det. De bør være de første mål for et program til reduktion af teknisk gæld.
Beslutninger om at bygge versus købe. Når man vurderer, om et COBOL-program skal vedligeholdes på lang sigt eller erstattes med et SaaS- eller et moderne alternativ, danner MI-scoren og ændringsomkostningshistorikken det kvantitative grundlag for beregningen af bygge versus købe. Et program med MI = 30, der er blevet ændret femten gange i løbet af de sidste tre år, hvor hver ændring tager betydeligt længere tid end estimeret, har dokumenterede vedligeholdelsesomkostninger, der kan sammenlignes med udskiftningsomkostningerne.
Ændringsgodkendelsestærskler. Nogle organisationer bruger MI-scorer til at bestemme det nødvendige niveau af ændringsgodkendelse. Programmer under en bestemt MI-tærskel kræver mere grundig gennemgang, uafhængig testning og yderligere godkendelse før produktionsimplementering. Dette skaber en kvalitetsbevidst ændringskontrolproces uden at kræve manuel vurdering af hver ændring.
Den eneste ting MI ikke kan: forudsige den forretningsmæssige effekt af en ændring. Et program med MI = 85, der udfører beregninger af regulatorisk kapital, kræver mindst lige så meget testning og validering som et program med MI = 40, der udfører en rapporteringsfunktion med lav risiko. MI måler ændringsindsatsen, ikke ændringens konsekvens. Begge dimensioner er nødvendige for en komplet risikovurdering.
Hvordan SMART TS XL Etablerer og sporer COBOL-vedligeholdelsesmålinger
Det er ligetil at beregne MI for et enkelt COBOL-program. Det kræver automatiseret analyse i stor skala at beregne den nøjagtigt for en portefølje af tusindvis af programmer, tage højde for COPY-udvidelse, identificere død kode og supplere MI med de ekstra metrikker, den mangler.
SMART TS XL's statisk kodeanalyse beregner hele COBOL-metriksuiten, der er beskrevet i denne vejledning, på tværs af hele porteføljen samtidigt. MI beregnes ved hjælp af PROCEDURE DIVISION-sætningsantal i stedet for samlede kildelinjer, hvor COPY-udvidelse udføres før analyse for at sikre, at delte datadefinitioner tilskrives korrekt. Cyclomatic Complexity tager højde for EVALUATE WHEN-klausuler, PERFORM UNTIL-betingelser og undtagelseshåndteringsgrene, ikke kun IF-sætninger. Halstead Volume beregnes ud fra COBOL-verber og dataoperander i PROCEDURE DIVISION.
Afgørende SMART TS XL supplerer MI med de målinger, som formlen mangler. kortlægning af applikationsafhængighed producerer fan-in-værdier, kaldet-af-tællinger, for hvert program i porteføljen og identificerer højrisikoprogrammer uanset deres MI-score. JCL udvidelse Funktionen giver JCL-afhængighedsdybden for hvert program og forbinder COBOL-niveau MI-analysen med den operationelle risikokontekst, som kun JCL-analyse kan afsløre.
Identifikation af død kode fra konsekvensanalysefunktionen markerer afsnit og sektioner uden indgående udførelsesstier, hvilket muliggør udelukkelse af død kode fra MI-beregningen og leverer den procentvise dødkode-metrik, der afgør, om et programs lave MI-score afspejler reel kompleksitet eller en oppustet LOC.
Virksomhedssøgningsfunktionen gør det komplette metrikdatasæt forespørgbart: find alle programmer med MI under 40 og fan-in over 20, sorteret efter JCL-afhængighedsdybde, de højest prioriterede afhjælpningsmål i porteføljen, i en enkelt forespørgsel på tværs af millioner af COBOL-linjer. Denne forespørgbare metrikopgørelse er grundlaget for vedligeholdelsesprioritering, migreringssekvensering og ændringsgodkendelsesapplikationer beskrevet ovenfor.
Endelig viser MI, der spores over tid og genberegnes efter hver væsentlig ændringscyklus, om programmet forbedres eller forringes. SMART TS XLs analyse køres på den aktuelle kilde i stedet for cachelagrede snapshots, hvilket sikrer, at metrikkene afspejler kodebasens faktiske tilstand på tidspunktet for hver analyse i stedet for en vurdering på et givet tidspunkt, der er forældet.
Målinger, der matcher sproget
Vedligeholdelsesindekset er en gyldig og værdifuld metrik for COBOL-porteføljer, men kun når det anvendes med en forståelse af, hvordan COBOLs syntaktiske egenskaber interagerer med dets komponenter. Anvendelse af generiske tærskler på COBOL-programmer giver misvisende resultater. Supplering af MI med de metrikker, den overser, COPY-kobling, fan-in, JCL-afhængighedsdybde og dødkodeprocent, giver et billede, der svarer til, hvad udviklere rent faktisk oplever, når de arbejder i en COBOL-portefølje.
De organisationer, der bruger disse målinger effektivt, er dem, der behandler dem som et udgangspunkt for en informeret samtale, ikke som en endelig dom over programkvalitet. En MI-score er et signal. Signalet er værd at følge, det peger konsekvent mod de programmer, der er dyre at ændre, risikable at modificere og værd at adressere, før moderniseringen begynder. Hvad MI ikke kan gøre, er at erstatte den dømmekraft, som en udvikler, der læser koden, har, eller erstatte den strukturelle analyse, der afslører de afhængigheder og den forretningslogik, som ingen enkelt måleenhed kan indfange.
