9,00

6,20

6,80

Measuring the Software Size of Sliced V-model Projects

Andreas Deuter

Gregor Engels

9,00

6,20

6,80

Content

1 Challenges

2 Related work

3 Proposed approach

4 Application of the approach

5 Conclusion and future work

9,00

6,20

6,80

What is the problem?

Software importance increases a lot for industrial vendorsProduct innovations more and more software based

Product assembly lines highly automated and permanently measuredSoftware “assembly“ process is not software production

Improvements in software development are initiatedBut difficult to prove objectively

Productivity figures needed for software measurementQuantity is one required figureHow to measure?

9,00

6,20

6,80

This is necessary

# Requirement Description

R1 Figures on software output are concrete numbers

R2 Figures are objective (i.e., they are not based on questionnaires)

R3 Figures include the size of software and its development documentation

R4 The measurement of the figures is automated

R5 The figures are useable for trend analysis

Industrial software produces a lot of documentation Documents support life cycle management Customer and certification authorities require thorough documentation IEEE 610.12 definition of software: “computer programs, procedures

and possibly associated documentation.” [1][1] IEEE 610.12 - IEEE Standard Glossary of Software Engineering Terminology., Std., 1990

R3

9,00

6,20

6,80

Content

1 Challenges

2 Related work

3 Proposed approach

4 Application of the approach

5 Conclusion and future work

9,00

6,20

6,80

Cool, the sliced V-Model [2]

[2] A. Deuter, “Slicing the V-model - Reduced effort, higher flexibility” in Proceedings of 8th International Conference on Global Software Engineering, ICGSE’13, 2013, pp. 1–10.

Agility extension of traditional V-model

Reduces Work in Progress (WiP)

Documents are container of Work Items

Links between Work Items to form “V”

9,00

6,20

6,80

Artefact created during software developmentRequirementSpecificationTest CaseDefect

Represent documentationAnd can be also a

Task

Don‘t misunderstand the Work Item

9,00

6,20

6,80

Software productivity, hm?

Not defined in international StandardsMultiple approaches available. Petersen analyzed 586

articles with many different quantification approaches [2]CMMI and SPICE require measurement, however no

required method givenTherefore, Industry vendors need to select

and adopt out of varietyWe follow Sneed’s devils square [3]

[3] K. Petersen, “Measuring and predicting software productivity: A systematic map and review,” Inf. Softw. Technol., vol. 53, no. 4, pp. 317–343, Apr. 2011.[4] H. M. Sneed, Software Management for Engineers, ser. Ellis Horwood series in information technology. Ellis Horwood Ltd, 1989.

9,00

6,20

6,80

Functional quantity measurementAll function point variants

Constructive quantity measurementLOC, source-code analysis, churn

# Functional methods Constructive methods

R1 + +

R2 o +

R3 - -

R4 o +

R5 + +

We miss documentation measurement

9,00

6,20

6,80

Content

1 Challenges

2 Related work

3 Proposed approach

4 Application of the approach

5 Conclusion and future work

9,00

6,20

6,80

Analyzing source- code revisions

Get unified diff patch for each file

Sum up per “module” work item

Sum up per projectUPP, RevP,, FileP

Churn is a measure for developers activity

9,00

6,20

6,80

Counting work items linked with requirements and defect

RSize,DSize,WID,WIT

Sum up per projectBottom-Up Analysis

Work Items show documentation size

9,00

6,20

6,80

Content

1 Challenges

2 Related work

3 Proposed approach

4 Application of the approach

5 Conclusion and future work

9,00

6,20

6,80

Phoenix Contact supplier of electrical and electronic components for industrial applications. 13,000 employees, 51 owned sales companies and more than 30

sales partners worldwide. Software activities are carried out in three locations Bad Pyrmont,

Lemgo (Germany), Ann Arbor (USA).

Sliced V-Model implemented using Polarion ALM [5]

Reporting Tool implementingabove concept

Who are we?

[5] Polarion. http://www.polarion.com, 2014.

9,00

6,20

6,80

Analyzing three software projects and one detailed requirement:Windows development (A)Embedded development (B)Reporting tool (C)

How far are we

9,00

6,20

6,80

Simple trends

Discussion with project and test manager on project AMeaningful and helpful figures

Yes, it works

9,00

6,20

6,80

Content

1 Challenges

2 Related work

3 Proposed approach

4 Application of the approach

5 Conclusion and future work

9,00

6,20

6,80

R1: Concrete numbersNumber of work items, size of churn in kB

R2: Objective figuresTaken direct out of Polarion and Subversion database

R3: Software size including documentationWork Items represent documentation

R4: Automated measurementStand-Alone reporting tool

R5: Trend analysisComparing Snapshots creates trends

We are happy, …

9,00

6,20

6,80

Work with these figures in daily routinesPossible detailing

Detailed analysis on work items, e.g. including text sizeAnalyzing changes in work items (“work item churn”).

Challenge. Implement sliced V-model correctly in practiceCompare figures between projects

Integrate quantity figures in productivity measurementsCreate figures for quality, costs and durationCreate meaningful relationships between these figures

…but much more to do

9,00

6,20

6,80

Questions ?