“Software kwaliteit en metrieken, Omnext Saas”

Dr. H. Vogt, presentatie Universiteit Urecht januari 2015

1

Agenda

• Introductie

• Software kwaliteit: Millennium probleem

• Waarom software kwaliteit?

• Software kwaliteit en metrieken

– ISO 25010/9126

– Een aantal software metrieken

– IFSQ level 1,2,3

• Omnext Saas

• Kosten en Metrieken

2

Introductie Dr. H. Vogt

• Informatica Universiteit Utrecht

• Promotie Universiteit Utrecht

– Hogere Orde Attributen Grammatica’s (parsers++)

• SERC (Software Engineering Research Centre)

– Finder 2000 Millennium Analyse tool

– Program Committee Working Conference Reverse Engineering

• Omnext

– Saas: Software Analysis As a Service

– Member of the NEN Normcommissie 381007 'Software and Systems

Engineering'

– Member of the NEN Werkgroep working on NPR5325 'Opleveren en

overdragen van software‘

– IFSQ level 1 en 2 gecertificeerd

Omnext

4

Millennium probleem

5

Het probleem

• Ontbreken eeuwaanduiding in jaartallen

– 83 wordt gezien als 1983

– 00 wordt gezien als 1900, niet als 2000

• 1900 geen schrikkeljaar, 2000 wel

• 99 wordt door veel systemen niet als een

jaartal beschouwd, maar als een

standaardwaarde voor bijvoorbeeld een

foutmelding

6

Voorbeeld

• Wie om vijf voor twaalf gaat bellen en om vijf

over twaalf ophangt zou rijk worden

• Het gesprek begint om 23.55 uur op 31

december van het jaar 1999 en eindigt om

00.05 uur van het jaar 1900

• Zonder doeltreffende maatregelen heeft dit

telefoongesprek een negatieve

telefoonrekening tot gevolg voor bijna een

eeuw bellen

7

Will London's lights go out?

Will London's lights go out?

http://www.pa.press.net/tech/year230997.html

By Giles Turnbull, New Media Correspondent, PA

IF NO ACTION WAS TAKEN, BUT ALL HAVE TAKEN ACTIONS

• Banks closing for most of January 2000

• Telephone lines only operating properly 75 percent of the time.

• Massive disruption to power supplies during December 1999 and the

following January.

• Stock market closed between 1st December 1999 and 24th January 2000

• Ten days of disruption to the postal service.

• Schools closed for four weeks

• Hospitals only open for emergencies for four weeks.

8

Embedded systems hard evidence

To: year2000-discuss@year2000.com

Date: Wed, 12 Nov 1997 09:44:12 -600 (CST6CDT)

Presented at the November meeting of the Energy Industry Y2K SIG

• Four Alcoa Steel Plants

– 50% of control systems will fail

• North Sea Expro (Shell-Exxon JV)

– Platform, Pipeline and Gas Plants

– 1200 systems identified, 12% failure rate

• BP Refinery, Grangemouth, UK

– 94 systems identified

– Couldn't find vendor for 20

– 74 assessed

– 3 will fail, 2 will cause shutdown

Jay Abshier, Mgr- Corporate Year 2000 Office

Texaco Inc, Bellaire, Texas

9

Tools for millennium

Prepare

Analysis

Adapt

Test

Implementation

Time

Tools

10

Waarom software kwaliteit?

11

Waarom software kwaliteit?

Complexity Is Killing Your Large Applications: Act Now to Save Them

12

Complexiteit

13

Complexiteit

14

Maintenance costs

Systemen steeds complexer

Weinig of geen documentatie

Geen mensen met kennis meer

Herbouw geen optie

15

Kosten besparen

Business Vraag: Sturen op kwaliteit code tijdens ontwikkeling en onderhoud

SaaS Antwoord: meten van metrieken van code als dienst in de cloud (Omnext), in het engels Software Analysis As a Service

- Complexity is killing your large applications : Act now to save them ( Andy Kite – VP & Gartner Fellow )

The Effects of Complexity

17

ISO 25010: non functionele requirements

Functionele requirements

Beschrijven specifiek gedrag of functies, die het

systeem dient te vervullen

Niet-functionele requirements

Niet-functionele requirements specificeren

criteria om het functioneren van het systeem te

beoordelen. Bijvoorbeeld performance

18

ISO 25010

• Niet-functionele requirements

• Product kwaliteitsmodel (product quality)

– 31 kwaliteitsattributen

– beperkt tot het doelsysteem – hardware en

software

• Kwaliteit tijdens gebruik (quality in use)

– 11 kwaliteitsattributen

– de gehele interactie tussen gebruikers en het

informatiesysteem

19

Product Quality

20

Maintainability

21

Metrieken

• Indicator

– maat voor één of meer kwaliteitseigenschappen.

Literatuur: ‘metrics’

• Meetvoorschrift

• Norm

22

Voorbeeld metrieken

• LOC

• FP backfiring

• Unit size

• Parameterlist

• CC

• MI

23

LOC

• Lines of Code

• Meer LOC, meer effort om te ontwikkelen

24

LOC

• Wat is LOC?

25

Function Point

• Wikipedia:

• A function point is a unit of measurement to

express the amount of business functionality

an information system provides to a user

• The cost (in dollars or hours) of a single unit is

calculated from past projects

• Example: 8 hours per function point

• FPA Functie Punt Analyse

26

FP backfiring

• LOC -> FP -> Herbouwwaarde systeem

• QSM Function Point Programming Language

Table

27

Too large unit size

• Method is doing more than its

name/signature might suggest

• Challenging for others to digest , excessive

scrolling causes readers to lose focus.

• Try to reduce the method length by creating

helper methods and removing any

copy/pasted code.

• Voorbeeld threshold: 100

28

Lengte Parameterlist

• Methods with numerous parameters are a

challenge to maintain, especially if most of

them share the same datatype

• These situations usually denote the need for

new objects to wrap the numerous

parameters.

• Voorbeeld threshold: 7

29

Parameterlist voorbeeld

30

CC (Cyclomatische complexiteit, McCabe 1976)

What the Experts say...

• One general recommendation from the recent SEI report entitled:

"Incorporating Software Requirements into the System RFP," suggests

including Complexity measurements in the statement of work and

enforcing limits on cyclomatic complexity. "Application complexity affects

software supportability. One generally accepted complexity measure is

McCabe’s Cyclomatic Complexity Measure, which should not exceed 10 for

a given module."

• Incorporating Software Requirements into the System RFP

Survey of RFP Language for Software by Topic, v. 2.0

Edited by Charlene Gross

MAY 2009 SPECIAL REPORT

CMU/SEI-2009-SR-008

Acquisition Support Program

31

CC

32

• Wat is het?

• Aantal beslispunten + 1

If a =b*b+4*3

Then 2+a

Else 3+b

Fi

• CC=2, #testpaden = 2

CC

33

CC

If a =b*b+4*3

Then 2+a

Else 3+b

Fi

If a =c*f+56

Then 2+f

Else 3+g

Fi

CC=3, #testpaden = 4

34

CC

If a =b*b+4*3

Then 2+a

Else 3+b

Fi

If a =c*f+56

Then 2+f

Else 3+g

Fi

If a =f*h+56

Then 2+j

Else 3+k

Fi

CC=4, #testpaden = 8

35

CC

• CC=8, #testpaden = ???

• Slechte cholesterol

36

CC

If land = NL

Then x

Fi

If land = DE

Then y

Fi

If land = GR

Then z

FI Goede cholesterol

37

MI

• [Oman and Hagemeister, 1991]

• Maintainability Index

• Bepaald onderhoudbaarheid van systeem

• Enkel getal

• Samengesteld uit

– LOC

– CC

– #number of comments

– Halstead metrics

38

MI

39

MI

Complex

40

MI

• Probleem: niet intuitief voor vinden wortel van het probleem

• Bij metingen met commentaar ook nog even als mens naar

kijken

• Alternatieven?

41

IfSQ

• Institute for Software Quality

• Collections defect indicators

• Three collections, level 1, 2, 3

• Why inspection?

– Code inspection is up to 20 times more efficient

than testing

– Code reading detected about 80% more faults per

hour than testing

42

Level 1

• Most commonly occurring defect indicators considered bad

practice

• Work in Progress

– WIP-1—Vague "To Do“

– WIP-2—Disabled Code

– WIP-3—Empty Statement Block

• Structured programming

– SP-1—Routine Too Long

– SP-2—Nesting Too Deep

• Single point of maintenance

– SPM-1—Magic Numbers

43

Vague “todo”

44

Disabled code

45

Empty block

46

Nesting too deep

47

Geen hardcoded constanten

48

Level 2

• Enkele extra defect indicators

• Voorbeeld

• SP-3: Logic Too Complex

• based on McCabe’s Complexity metric

49

Logic too complex

50

Defect indicators

• http://osqr.com/quick_scan.html

51

Praktijk case

• Stichting Capclaim strijdt onder leiding van Kenneth

Berkleef van het failliete Equihold tegen ict-

dienstverlener Capgemini. Inzet is het terugvorderen

van 43 miljoen euro schade.

Read

more: http://www.computable.nl/artikel/expertversl

ag/development/5208050/1277180/de-kwaliteit-

van-de-capgeminisoftware.html#ixzz3NPPBDDuU

52

Praktijk case (2)

• Extern onderzoek naar de kwaliteit

• In oktober 2010 heeft Equihold gevraagd aan Software Quality

Measurement and Improvement (SQMI) om de opgeleverde

software te onderwerpen aan een onderzoek. SQMI hanteert

een methodische aanpak waarbij het aantal coderegels met

een defect worden geteld en gegroepeerd in categorieën.

Gemiddeld kwam men op 175 foutieve regels per duizend

regels code wat een F-rating opleverde, een drie op een

schaal van één tot tien. De één na laagste score in de

geschiedenis van SQMI.

• Op basis van dit onderzoek is de eindconclusie dat de

onderhoudskosten voor dit product onnodig hoog zijn en de

software als platform voor verdere ontwikkeling ongeschikt is.

53

Praktijk case (3)

• Nog een extern onderzoek naar de kwaliteit

• In 2014 heeft Capgemini de Software Improvement Group (SIG) gevraagd

om de software te onderzoeken op onderhoudbaarheid. Zij hebben

hiertoe de methode SIG/TUViT-kwaliteitsmodel voor Trusted Product

Maintainability (april 2009) gehanteerd. Ook dit is een methodische

aanpak op basis van tellingen en een normenkader.

• Afgelopen juni hebben zij dit rapport gepresenteerd met als belangrijkste

conclusie dat de onderhoudbaarheid ‘marktgemiddeld’ is, afgezet tegen

de benchmark die SIG hanteert. Dit hoeft natuurlijk niet dezelfde

benchmark te zijn die SQMI hanteert en waarop het tot een F-rating komt.

Let wel dat SIG direct de onderhoudbaarheid van de software heeft

onderzocht en SQMI de software in het algemeen en daarbij als afgeleide

heeft geconcludeerd dat de onderhoudbaarheid onnodig duur is.

Omnext® SaaS Solution

Omnext SaaS Approach

Tivoli

JCL(Job control)

...

Java

.Net(OO)

Cobol

PL/1(3GL)

Workflow

Omnext SaaS

Data

Warehouse

• Parse Sources

• Resolve Relationships

• Calculate Metrics

• Check Anti-patterns

• Detect Code

Duplication

• Detect Dead Code

• Create Design Models

• Difference Analyses

UML-tools

Oracle

Uniface(4GL)

Omnext Portal

MS-Excel

Omnext® SaaS Solution

Supported sources

• Access

• ActionScript

• ANSI Cobol 85

• ASP

• Aquima

• C/C++

• C#

• Cobol (most dialects)

• Java

• JavaScript

• Objective C (2013)

• Oracle Forms

• Oracle SQL

• PHP

• PL/1

• Powerbuilder

• Powercenter

• RPG

• SAP ABAP (2013)

• Siebel eScript

• SQL Server

• Sybase

• DB/2

• UNIFACE

Support for new languages and configurations are added in future releases.

• VB.NET

• Visual Basic 6

• DCL

• JCL

• Tivoli Workload

Schedule

• SMF

• User menu

configurations

• Workflow

configurations

• …

• On Demand

• Cloud based

• SaaS Model

• NO licence, NO subscription

–Usage based pricing

Omnext® SaaS Introduction

Delivery

Omnext® SaaS demo

Omnext® SaaS Examples

58

Corporate Risk PolicyIdentify Maintenance Risk

59

Health checkMonitor Progress

60

SizeLines of code, Function points

61

ProductivityMaintenance Function Points

62

Call Tree and Where Used show all resolved

relations

Cross ReferenceAcross Technologies

63

Source ViewExample Sybase Stored Procedure

In the Source View

the code of any

language is well

structured, color

coded and

hyperlinked.

64

Source ViewCompare versions

65

The Design supports

analysis by showing

class diagrams,

sequence diagrams,

flow charts, call graphs,

structure diagrams, …

Design can be exported

to UML-tools

Design ViewFlow Chart

66

Design ViewJackson Structure Diagram

67

Design ViewUML Sequence Diagram

68

Standards & guidelinesBest practices

industry coding best

practices and customer

coding standards

69

Clone detectionFind duplicated code

Exact clones as well as

syntactic clones

70

Worklist

All identifiers and their use are stored separately in the data warehouse, making it easy to search and perform data flow analysis and create a work list. In this

example a SEPA work list is created using ‘iban’ and ‘transaction’ as starting points for further data flow analysis.

71

Search

72

Annotations

Annotations can be added to all items in the Omnext portal. One

can even add annotations to

selected lines of code, for instance to document Business Rules or

Issues to be solved

During an impact analysis a

developer can add annotations to

the objects in scope, with tags referring to the change or the

subject.

73

Annotations

The annotations can be filtered on tags (in this case the change

number or the subject). This

creates the work list of things to do.

The filtered annotations can be exported to Excel

74

Identifying interfaces and

Data persistency

Reports are available on interfaces and data persistency, with the option to trace the information from data layer to business layer

75

Customer Reports

By adding relations between components and Business Services, Business

Processes, Organisational Units, etc. In the Data Warehouse, reports can be created

on those levels.

76

Aggregate on Business LevelExample Function Points Report per Business Service

77

System HealthExample on iPad

78

Trend AnalysisExample on iPad

79

Test SupportExample of Quicktest Pro input file

Export Form Definitions to

Quicktest Pro to accelerate test

preparation.

Example: Powerbuilder

80

Batch Schedule OptimizationAnti Patterns

Technical Debt in Batch

Schedules:

• Dummy Jobs

• Incorrect/superfluous

dependencies

• backups in critical

timelines

• …In this example based on a Tivoli Application Database, Current Plans, Track Log information and JCL.

81

Batch Schedule OptimizationWhite space analysis

White space analysis, showing gaps in critical timelines.

In this example based on a Tivoli Application Database, Current Plans, Track Log information and

JCL.

Omnext is also mentioned in the IBM redbook‘Approaches to Optimize Batch Processing on z/OS’.

See: http://www.redbooks.ibm.com/abstracts/redp4816.ht

82

From current plan and track log

From application

database

Cross-reference

Tivoli – JCL - Cobol

Job schedule, JCL, resources and application information all linked and easy accessible in the portal

Batch Schedule OptimizationCross Reference

83

Use Case Editor

With the Use Case Editor in the Omnext® Portal, one can recreate functional documentation based on a structured walk through of the source code. With the use case editor, one can add logical labels (aliases) to pieces of source code that are functionally relevant. Also one can add found business rules to the use cases.

One can exclude, collapse or expand items in the use case editor.

• Exclude: exclude the item from the use case

• Collapse: include the complete item as one step in the use case

• Expand: show the call tree and conditions within the selected item

84

Save maintenance costs

• Uit de white paper Omnext

• How to save on software maintenance costs

• Maart 2010, Ir. F. Engelbertink en Dr. H Vogt

• Agenda

– Costs of understanding

– Documentatie helpt?

– Dode code

– Cloned code

– Bugs verwijderen

– Complexiteit

– Totaal

85

Costs of understanding

[3, SWEBOK]

86

Documentatie helpt?

• Hoeveel documentatie is genoeg?

• Studie 2005 [13, Universidade Católica de

Brasília, Brasilia, Brazil ]:– Source code and comments are the most important artifacts for

understanding a system to be maintained

– Data model and requirement description were other important

artifacts

– Surprisingly, and contrary to what we found in the literature,

architectural models and other general views of the system were not

found to be very important

• Zorg dat de code goed onderhoudbaar is zodat analyse niet zo

lang kost

87

Herdocumentatie

• Meeste systemen slecht gedocumenteerd

• Case study [5, Report from an experiment : impact of documentation on

maintenance in Journal of empirical software engineering, 1997]

– Geen documentatie: 21% langere analyse

– Onderhoud is tot wel 50% analyse

– Wel documentatie: 10% winst totale kosten

– Hun opmerkelijke cocnlusies

• Zonder documentatie: geen verschil goede/slechte pr.

• Met documentatie: goede beter

• Hun conclusie: goede pr. zonder documentatie weinig zin

88

Dode code

• [16,17 SIG and Free University of Amsterdam]

• Tot 30% code in systeem kan dode code zijn

• Gemiddeld 15%

• Vaak niet bekend wat dode code is

• Toch maar onderhouden

• Stel onderhoud per jaar kost 1$ per regel

• Applicatie 1 miljoen regels

• 15% dode code verwijderen

• 150000$ besparen

89

Cloned code

• 100% gelijke kloon

• Modulo variabele namen

• [19, Demantic Designs]

• Grote systemen 10-25% cloned code

• Moet onderhouden worden

• Bugs cloned

• Stel onderhoud per jaar kost 1$ per regel

• Applicatie 1 miljoen regels

• 15% cloned code verwijderen

• 150000$ besparen

90

Bugs verwijderen

• PMD, Stylecop, Bandera, ESC/Java2, FindBugs,

JLint

• Kunnen echte bugs opsporen

– Lege if statement

– Echte fouten

• The null check here is misplaced. If the variable is null a

NullPointerException will be thrown. Either the check is

useless (the variable will never be "null") or it is

incorrect.

91

Bugs verwijderen

• 1 miljoen regels code

• 10 bugs verwijderen (general experience)

• $500-$1000 per bug fix

• $5000-$10000 bespaard

92

Complexity

• Case study [22, Software Complexity and Maintenance Costs,

Communications of the ACM, Banker et al, November 1993]

– High levels of software complexity account for

approximately 25% maintenance costs or more

than 17% of total life-cycle costs

– Given the extremely high cost of maintenance in

commercial applications, the neglect of software

complexity is potentially a serious omission

93

Totaal

• 1 million lines of code

• $1 maintenance cost per line per year

94