Das Dokument behandelt die Herausforderungen und Komplexität des Software Measurement bei eBay und stellt einen ganzheitlichen Ansatz vor, der sowohl tool-basierte als auch manuelle Evaluierungsmethoden umfasst. Ziel ist es, die Qualität von Softwareprojekten zu verbessern, Akzeptanzkriterien festzulegen und eine Vergleichbarkeit zwischen verschiedenen Teams zu schaffen. Die Implementierung von Audits und Feedback-Mechanismen wird hervorgehoben, um kontinuierliche Verbesserungen zu fördern und die Reife der Projekte zu bestimmen.

1. Software Measurement
in agilen Projekten
mit Open Source Tools
Michael Palotas & Dominik Dary
eBay Quality Engineering Europe
2011-10-11

2. Agenda
• Komplexität und Herausforderungen bei eBay
• Ausgangssituation
• Manuelles und Tool-basiertes Software Measurement
• Auswirkungen des Software Measurement
2
Erstellt von: Michael Palotas & Dominik Dary

3. Komplexität und Herausforderungen bei eBay
60 million lines of code
10.000+ Java application servers
2 billion page views/day
25,000 searches per second
110 million items in > 50,000 categories
25 Petabyte of data processed by Data Warehouse/day
4.4 billion API calls per month (public API)
48 billion SQL executions/day
2 Terabyte of application log files/day
2 million outbound emails/day
14 Gbps peak network utilization
Erstellt von: Michael Palotas & Dominik Dary

4. Ihre Referenten
Michael Palotas Dominik Dary
• Head of Quality Engineering • Senior Software Engineer in Test
Europe • E-Mail: ddary@ebay.com
• E-Mail: mpalotas@ebay.com
4
Erstellt von: Michael Palotas & Dominik Dary

5. Ziele von Software Measurement?
Wir möchten uns ständig verbessern in dem was wir tun
Festlegung von Akzeptanzkriterien aus der Sicht der
Qualitätssicherung
Schaffung der Vergleichbarkeit von Projekten und Teams
Ermittlung der aktuellen Reife (Maturity) der Projekte
Anreiz für das Team um sich zu verbessern
Um von dem „gutem Bauchgefühl“ Measurement Ansatz
wegzukommen J
5
Image Source: http://www.clickbuyhelp.org/wp-content/uploads/2010/03/Continuous-Improvement.jpg Erstellt von: Michael Palotas & Dominik Dary

6. Tool-basiertes Software Measurement
Beispiel: eBay Deals Anwendung
6
Erstellt von: Michael Palotas & Dominik Dary

7. Software Measurement in der Praxis?
Warum reicht Tool-basiertes Measurement nicht aus?
Ganzheitlicher Ansatz im Gegensatz nur zur Verwendung von
statischer Analyse-Tools
Nicht nur die “harten Fakten” werden mit einbezogen
Einige Kriterien können nicht Tool-basiert verifiziert werden (i.e.
Testfallqualität, Qualität der Dokumentation, Testplan)
Tool-basiert Manuelles Audit
- SONAR Open Source Tool
& - Durchgeführt vom QE
Engineer
- Alle 3-5 Iterationen
7
Erstellt von: Michael Palotas & Dominik Dary

8. Unsere Vision
Engineering Practices
QA QE DEV
Manual Tests Automated Testing
Large Small Integra-
Exploratory Tests Tests tion
Testing Tests
Projekt Audits
Fast
Continuous SCM Delivery
Integration
Acceptance
Test
Tools
Wiki
8
Erstellt von: Michael Palotas & Dominik Dary

9. Maturity-Definition der Key-Area “Test Strategy”
Test Plan
Maturity Definition
1
• Level 1:
Ein Testplan existiert für das Project.
Manual Tests
• Level 2:
User Acceptance Dev
Ein manueller Testplan existiert
Tests Tests
• Level 3:
System Tests & automatisierte Large
Regression Tests System Tests sind vorhanden und sind
Tests aufeinander abgestimmt.
• Level 4:
3 2 Low-Level Testplan existiert
• Level 5:
Large High-Level und Low-Level Tests sind
Tests aufeinander abgestimmt.
High level test
5
Low level test
Small Integration
Tests 4 Tests
Automated Tests 9
Erstellt von: Michael Palotas & Dominik Dary

10. Wie wird mit den Ergebnissen des Audits umgegangen?
Feedback an das SCRUM-Team & das Management
Scrum Master + Product Owner entscheiden basierend
auf den vorgeschlagenen Maßnahmen
Maßnahmen werden übers Produktbacklog umgesetzt
10
Image Source: http://en.wikipedia.org/wiki/File:Scrum_process.svg Erstellt von: Michael Palotas & Dominik Dary

11. Auswirkungen des Software Measurement
Messbare Verbesserung der Qualität des Quellcodes und des Produkts
Team sind motiviert sich beständig zu verbessern
Anreiz zwischen den Teams
Entwicklung der Maturity Levels: Beispiel Darstellung eines Audits
11
Erstellt von: Michael Palotas & Dominik Dary

12. Unsere Erfahrungen als Auditoren
Positive Erfahrungen Was haben wir geändert:
• Erste Audits benötigen • Neue Metriken:
einige Vorbereitungszeit • Continuous Integration
• Später durchgeführte • Code Reviews
Audits können schnell • Source Code Management
durchgeführt werden
• Schnelles Feedback über
die Projekte
• Die Leistungsfähigkeit
liegt in der Einfachheit
der Audits
12
Erstellt von: Michael Palotas & Dominik Dary

13. Kommentare, Vorschläge oder Fragen?
13
Erstellt von: Michael Palotas & Dominik Dary

14. Vielen Dank für Ihre Aufmerksamkeit!
14
Erstellt von: Michael Palotas & Dominik Dary