1. Measuring the Software Size of Sliced
V-model Projects
Andreas Deuter
Gregor Engels

2. Content
1 Challenges
2 Related work
3 Proposed approach
4 Application of the approach
5 Conclusion and future work

3. What is the problem?
Software importance increases a lot for industrial vendors
Product innovations more and more software based
 Product assembly lines highly automated and permanently
measured
 Software “assembly“ process is not software production
Improvements in software development are initiated
 But difficult to prove objectively
 Productivity figures needed for software measurement
Quantity is one required figure
How to measure?

4. 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
R3
 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

5. Content
1 Challenges
2 Related work
3 Proposed approach
4 Application of the approach
5 Conclusion and future work

6. Cool, the sliced V-Model [2]
Agility extension of
traditional V-model
Reduces Work in
Progress (WiP)
Documents are
container of Work
Items
 Links between Work
Items to form “V”
[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.

7. Don‘t misunderstand the Work Item
 Artefact created during
software development
Requirement
 Specification
 Test Case
 Defect
Represent documentation
And can be also a
Task

8. Software productivity, hm?
Not defined in international Standards
 Multiple approaches available. Petersen analyzed 586
articles with many different quantification approaches [2]
CMMI and SPICE require measurement, however no
required method given
Therefore, Industry vendors need to select
and adopt out of variety
 We 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. We miss documentation measurement
Functional quantity measurement
 All function point variants
Constructive quantity measurement
LOC, source-code analysis, churn
# Functional methods Constructive methods
R1 + +
R2 o +
R3 - -
R4 o +
R5 + +

10. Content
1 Challenges
2 Related work
3 Proposed approach
4 Application of the approach
5 Conclusion and future work

11. Churn is a measure for developers activity
Analyzing source-code
revisions
Get unified diff patch
for each file
 Sum up per “module”
work item
Sum up per project
UPP, RevP,, FileP

12. Work Items show documentation size
Counting work items
linked with
requirements and
defect
RSize,DSize,WID,WIT
Sum up per project
Bottom-Up Analysis

13. Content
1 Challenges
2 Related work
3 Proposed approach
4 Application of the approach
5 Conclusion and future work

14. Who are we?
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 implementing
above concept
[5] Polarion. http://www.polarion.com, 2014.

15. How far are we
Analyzing three software projects and one detailed
requirement:
Windows development (A)
Embedded development (B)
Reporting tool (C)

16. Yes, it works
 Simple trends
 Discussion with project and test manager on project A
Meaningful and helpful figures

17. Content
1 Challenges
2 Related work
3 Proposed approach
4 Application of the approach
5 Conclusion and future work

18. We are happy, …
R1: Concrete numbers
Number of work items, size of churn in kB
R2: Objective figures
 Taken direct out of Polarion and Subversion database
R3: Software size including documentation
Work Items represent documentation
R4: Automated measurement
Stand-Alone reporting tool
R5: Trend analysis
Comparing Snapshots creates trends

19. …but much more to do
Work with these figures in daily routines
Possible detailing
 Detailed analysis on work items, e.g. including text size
 Analyzing changes in work items (“work item churn”).
Challenge.
Implement sliced V-model correctly in practice
Compare figures between projects
 Integrate quantity figures in productivity measurements
Create figures for quality, costs and duration
Create meaningful relationships between these figures

20. Questions ?