Software metrics

540
-1

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
540
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Software metrics

    1. 1. successful projects doen‘t happen You have to make them
    2. 2. success rate and project duration 80% 60% 40%GULP poll 20% successful 0% changed 1-3 3-6 6-12 >12 months stopped
    3. 3. why do they fail• deficit of soft-skills• dogmatism• no universal IT-architecture• no clearly defined interfaces• lack of clearness & precision• lack of manageability
    4. 4. working in projects New Development Support 30 % 40 % Maintenance 30 %
    5. 5. working in projects under- normalestimated work New Development Support 30 % 40 % Maintenance 30 %
    6. 6. these: increasing project runtime
    7. 7. these: increasing project runtimemore complex erodingarchitecture architecture
    8. 8. eroding architecture• is normal• quality of architecture is not easy to measure• typical signs: • many dependancies • cyclic dependancies
    9. 9. reasons• distributed system knowledge• size generates complexity• outgrowing dependancies and complexity• time pressure and money is a good reason to loose structure• no one pays attention
    10. 10. what next?• cycle check with JDepend / SonarJ• code reviews• CheckStyle and FindBugs• using metrics• generate abstraction with own frameworks
    11. 11. what to do?• definition of architecture• use of relevant metrics• pattern and rules to keep the system simple• early violation recognition• regular reviews• agile development
    12. 12. abstract architectureUser InterfaceBusiness Logic Data Access 1. layer
    13. 13. abstract architectureUser Interface Customer Contracts Common UserBusiness Logic Data Access 1. layer 2. functional slice
    14. 14. abstract architectureUser Interface Customer Contracts Common UserBusiness Logic Data Access 1. layer 2. functional slice 3. allowed interactions
    15. 15. abstract architectureUser Interface Customer Contracts Common subsystem UserBusiness Logic Data Access 1. layer 2. functional slice 3. allowed interactions
    16. 16. layer, slices and subsystems• a subsystem belongs to one layer• a subsystem may belong to a functional slice (not required)• classification by naming conventions• not all layer need functional slices• subsystems can be private
    17. 17. assignment of elements• physical • type • build unit • package• logical • subsystem is a set of packages with naming conventions for packages and interfaces • layer is a set of subsystems • functional slices with naming conventions
    18. 18. reduce dependancies• Dependency Inversion Principle (Robert C. Martin) • use interfaces / traits
    19. 19. reduce dependancies • Dependency Inversion Principle (Robert C. Martin) • use interfaces / traits Main Mid 1 Mid 2Detail Detail Detail Detail
    20. 20. reduce dependancies • Dependency Inversion Principle (Robert C. Martin) • use interfaces / traits High Level Main Policy Mid 1 Mid 2 Interface Interface Interface Detailed Detailed DetailedDetail Detail Detail Detail Implement. Implement. Implement.
    21. 21. metrics
    22. 22. Average ComponentDependency (ACD metric)
    23. 23. Average Component Dependency (ACD metric) 6 3 3 1 1 1ACD=15/6=2.5
    24. 24. Average Component Dependency (ACD metric) 6 3 3 3 1 1 1 1 1 2 3 2ACD=15/6=2.5 ACD=12/6=2 Dependancy Inversion
    25. 25. Average Component Dependency (ACD metric) 6 3 6 cycles 3 3 1 1 6 6 1 1 1 2 3 2 1 6 1ACD=15/6=2.5 ACD=12/6=2 ACD=26/6=4.33 Dependancy Inversion
    26. 26. stability vs. instability (Robert C. Martin) This metric has the range [0,1]. I=0 indicates a maximally stable category Ca I=1 indicates a maximally instable categoryInstability I = (Ce+Ca) Ce = Efferent Couplings (incoming) Ca = Afferent Couplings (outgoing)
    27. 27. stability vs. instability (Robert C. Martin) This metric has the range [0,1]. I=0 indicates a maximally stable category Ca I=1 indicates a maximally instable categoryInstability I = (Ce+Ca) Ce = Efferent Couplings (incoming) Ca = Afferent Couplings (outgoing) Y is instable Y 3 / (0+3) = 1
    28. 28. stability vs. instability (Robert C. Martin) This metric has the range [0,1]. I=0 indicates a maximally stable category Ca I=1 indicates a maximally instable categoryInstability I = (Ce+Ca) Ce = Efferent Couplings (incoming) Ca = Afferent Couplings (outgoing) Y is instable X is stable Y 3 / (0+3) = 1 0 / (3+0) = 0 X
    29. 29. stability vs. instability (Robert C. Martin) This metric has the range [0,1]. I=0 indicates a maximally stable category Ca I=1 indicates a maximally instable categoryInstability I = (Ce+Ca) Ce = Efferent Couplings (incoming) Ca = Afferent Couplings (outgoing) Y is instable X is stable Y 3 / (0+3) = 1 0 / (3+0) = 0 X lower elements need to be more stable
    30. 30. abstractness (Robert C. Martin) na abstractness A = ncna = number of abstract classes in categorync = total number of classes in category This metric has the range [0,1]. 0 means concrete and 1 means completely abstract
    31. 31. abstractness vs. instability (Robert C. Martin) 1 Th eAbstraction M ain Se qu en c e 0 Instability 1
    32. 32. abstractness vs. instability (Robert C. Martin) 1 Th o ss Zo l es U e f se ne sne Th eAbstraction M ain Se qu en c e Th e Pain Zo ne of 0 Instability 1
    33. 33. distance (Robert C. Martin) 1 Th o ss Zo les U e f se ne sne D = A + I – 1 Th e Abstraction M ain D range [-1 .. +1] Se qu en ce Th e Pain Zo ne of 0 Instability 1„Any category that has a D value that is notnear zero can be reexamined and restructured“
    34. 34. design rules• create a logical architecture based on layer, functional slices and subsystems as an incremental process• no cycles beginning at package level• use metrics (e.g. as part of the build process) • rACD less less than 15% (for smaller systems and less than 4% for bigger systems) • compile units should have less than 1000 LOC • limit for CCN• implement frequent architecture reviews

    ×