Software-Evolution: Warum und Wie

n den Systemen, die uns die technisch die meisten Probleme machen, steckt oft der größte Wert. Wir würden sie am liebsten komplett neu entwickeln, aber das stellt sich bei näherem Hinsehen als äußerst schwierig heraus. Also vielleicht doch behalten? Oder heftig modernisieren? In diesem Vortrag erhalten Sie einen Überblick, worauf es bei Evolution von Software ankommt: Wir müssen auf geänderte Anforderungen reagieren, mit neuen und veränderten Schnittstellen zurecht kommen, unsere Basistechnologien austauschen können und ganz nebenbei noch auf Wartungskosten achten. Dazu beschreiben wir taktische und strategische Maßnahmen, die nicht nur zu der jeweiligen Entscheidung passen, sondern auch eine realistische Chance haben, in die Praxis umgesetzt zu werden.

Transcript

1. Ändern - aber richtig! Software-Evolution Warum und Wie http://commons.wikimedia.org/wiki/File:Evolution-des-wissens.jpg Wednesday 5 February 14
2. Ist! Wednesday 5 February 14
3. Soll! Wednesday 5 February 14
4. These: Ausbildung fokussiert auf Neubau Informatik von Systemen Wednesday 5 February 14
5. These: Praxis benötigt mehr Änderungskompetenz Informatik an Systemen Wednesday 5 February 14
6. These: Verbesserung ist mehr als Refactoring einzelner Klassen an Systemen Wednesday 5 February 14
7. These: Verbesserung ist mehr als Refactoring „Große“ Umbauten bedeuten (oft): • Umbau DB-Struktur, Datenmigration • Austausch von Software-Infrastruktur (z.B. Frameworks) • umfangreiche Änderung interner Abläufe • massive Änderung interner Schnittstellen Wednesday 5 February 14
8. These: Erfolgreiche Systeme sind verbaut meistens kommerziell Wednesday 5 February 14
9. These: Erfolgreiche Systeme sind verbaut Kommerziell erfolgreich: • Anwender fordern schnell viele Features • Schnelle Lieferung widerspricht „Engineering-Prinzipien“ Wednesday 5 February 14
10. These: Erfolgreiche Systeme sind verbaut Wednesday 5 February 14
11. These: Erfolgreiche Systeme sind verbaut Wednesday 5 February 14
12. http://www.flickr.com/photos/pasukaru76/9824401426 These: Erfolgreiche Systeme sind verbaut Wednesday 5 February 14
13. These: Änderungen an Systemen sind durch Geld motiviert Wednesday 5 February 14
14. • neue Features • veränderte NFA (z.B. Performance) • hohe Betriebskosten • hohe Änderungskosten These: Änderungen an Systemen sind durch Geld motiviert Wednesday 5 February 14
15. These: Budgetverantwortliche ignorieren Architekturprinzipien Wednesday 5 February 14
16. Architekturprinzipien und Clean-Code für • Entwickler • Architekten • sonstige „intrinsisch Motivierte“ These: Budgetverantwortliche ignorieren Architekturprinzipien Wednesday 5 February 14
17. 3 Fragen: • Wissen alle Stakeholder, wo die Probleme in der Architektur liegen? • Sind sich alle über die Konsequenzen einig? • Gibt es klare Strategien zur Verbesserung? Wednesday 5 February 14
18. Architecture Improvement Method Wednesday 5 February 14
19. Architecture Improvement Method free: ✓(as arc42!) open, contributions welcome easy to apply: ✓methodical patterns and practices ✓no specific tooling required grounded: ✓combines new and established practices ✓industry-proven Wednesday 5 February 14
20. analyze evaluate improve Wednesday 5 February 14
21. analyze evaluate improve • architecture • code • runtime • organization Wednesday 5 February 14
22. analyze evaluate improve determine „value“ of problems / risks / issues and their remedies Wednesday 5 February 14
23. analyze evaluate improve • define strategy • setup regression testing • refactor • re-architect • re-organize • remove debt Wednesday 5 February 14
24. analyze evaluate improve search for symptoms, problems, issues, risks, faults, mis-behavior, technical-debt... Wednesday 5 February 14
25. analyze evaluate improve • qualitative • ATAM • nominal-actual comparison • quantitative • structural • runtime • efficiency • resource consumption • logs, protocolls • known issues • bugs and bug clusters • organization • stakeholder • (development) process Wednesday 5 February 14
26. analyze evaluate improve • Capture-Quality- Requirements • Context-Analysis • Data-Analysis • Development-Process- Analysis • Documentation-Analysis • Issue-Tracker-Analysis • Profiling • Take What They Mean The Patterns... • Qualitative-Analysis • Quantitative-Analysis • Pre-Interview- Questionnaire • Requirements-Analysis • Runtime-Artifact-Analysis • Software-Archeology • Stakeholder-Analysis • Stakeholder-Interview • Static-Code-Analysis • View-Based- Wednesday 5 February 14
27. analyze evaluate improve • Capture-Quality- Requirements • Context-Analysis • Data-Analysis • Development-Process- Analysis • Documentation-Analysis • Issue-Tracker-Analysis • Profiling Patterns to find issues... • Qualitative-Analysis • Quantitative-Analysis • Pre-Interview- Questionnaire • Requirements-Analysis • Runtime-Artifact-Analysis • Software-Archeology • Stakeholder- Analysis • Stakeholder-Interview • Static-Code- Analysis Wednesday 5 February 14
28. Stakeholder Analysis who MIGHT have problems analyze evaluate improve Beispiele: Management, Auftraggeber, Projekt-Steuerkreis, sonstige Projekt-Gremien, PMO, Projektmanager, Produktmanager, Fachbereich, Unternehmens-/Enterprise-Architekt, Architekten, Methoden-Abteilung, QS-Abteilung, IT-Strategie, Software-Architekt, Software-Designer, Entwickler, Tester, Konfigurationsmanager, Build-Manager, Release- Manager, Wartungsteam, externe Dienstleister, Zulieferer, Hardware-Designer, Rollout- Manager, Infrastruktur-Planer, Sicherheitsbeauftragter, Behörde, Aufsichtsgremium, Auditor, Mitbewerber/Konkurrent, Endanwender, Fachpresse, Fachadministrator, Systemadministrator, Operator, Hotline, Betriebsrat, Lieferant von Standardsoftware, verbundene Projekte, Normierungsgremium, Gesetzgeber... Wednesday 5 February 14
29. Stakeholder Analysis (II) who MIGHT have problems analyze evaluate improve • use pre-interview questionnaire • conduct personal interviews: e.g. what are your top-3 issues with... 1. the system 2. the development / maintenance process 3. operation / infrastructure of the system 4. ... Wednesday 5 February 14
30. Capture-Quality-Requirements Qualitative Analysis • (similar to) ATAM • established methodology, published by SEI • industry-proven • basic idea: nominal-actual-comparison 1. determine explicit & specific quality goals 2. determine architecture approaches taken 3. analyze if 2. is sufficient for 1. analyze evaluate improve Wednesday 5 February 14
31. analyze evaluate improve Hierarchical Quality Model (1) Wednesday 5 February 14
32. analyze evaluate improve Hierarchical Quality Model (II) Wednesday 5 February 14
33. analyze evaluate improve Qualitative Analysis: Compare Goal / Solution Wednesday 5 February 14
34. analyze evaluate improve Static Code Analysis (here: SonarQube dashboard / Apache PDFbox) Wednesday 5 February 14
35. analyze evaluate improve Static Code Analysis (here: afferent coupling) Wednesday 5 February 14
36. • understand • root-causes of problems • determine „value“ of: • problems / risks / issues • their remedies • prioritize analyze evaluate improve Wednesday 5 February 14
37. analyze evaluate improve Goal: Convince Stakeholder (in their language) Wednesday 5 February 14
38. analyze evaluate improve • Determine Problem Cost • Determine Feature Value • Estimate Remedy Cost The Patterns... • Failure Mode And Effect Analysis • Impact Analysis • Root Cause Analysis • Separate Cause From Effect • Software Archeology • View Based Understanding Wednesday 5 February 14
39. analyze evaluate improve Issue „finding“ from the analysis-phase: symptom, problems, risks etc. Reason/Cause What‘s the (technical, structural...) reason behind the issue Cost / time what negative impact (in terms of money) does this issue have per time (i.e. per month)? Remedy what tactics, strategies or actions can resolve this issue, who need to be involved, prerequisites? Cost of remedy what will the remedies and actions cost? Impact & risk If remedy is taken what risks might follow, what impact might the remedy have? Wednesday 5 February 14
40. analyze evaluate improve Pri o Issue / Cause Cost / time Remedy Cost of reme dy Impact & Risk 1. data loss under high load damaged reputation, sales loss: €50.000/yr • replace in-memory data transfer by MOM • introduce transaction concept • apply standard integration patterns • 150 FTE-days • maybe: license cost • (-) higher complexity of implementation • (+) cleaner architecture • (+) modern middleware 2. high effort to configure to customer corporate identity cannot bill total effort to customer, €2.000/ customer • re-architect UI styling, introduce templating mechanism • re-implement pdf generation • 30 FTE-days • existing customers might require additional effort to migrate 3. pdf generator is rarely used, requires expensive license 25.000€/yr • migrate from iText-pdf to Apache pdfbox • 20 FTE-days • pdfbox is currently not well- documented • existing iTextPdf know-how not immediately useable • learning-curve Wednesday 5 February 14
41. Experience Report (Logistics) Analyze: ✓ ATAM & qualitative analysis ✓ Stakeholder interviews Evaluate: ✓ Prioritized issues ✓ Top-3 as „tasks“ to maintenance team Wednesday 5 February 14
42. solve issues, refactor, re-architect, re-structure, renew, migrate, cleanup analyze evaluate improve Wednesday 5 February 14
43. analyze evaluate improve • Automated Tests • Change by Extension • Change by Copy • Branch-for-Improvement • Refactoring • Refactoring-Plan • Refactor-Data-Structures • Migrate Data • Keep-Data-Toss-Code • Improve Code Layout • Handle-If-Else-Chains • Isolate Changes • Extract-Reusable- Component • Group Improvement Actions • Schedule Improvement Work The Patterns... Wednesday 5 February 14
44. Close for change Change-by-Extension Wednesday 5 February 14
45. Close for change Enable integrateability (auth/auth, navigation) Change-by-Extension Wednesday 5 February 14
46. Close for change Enable integrateability (auth/auth, navigation) Create new system for new features Change-by-Extension Wednesday 5 February 14
47. Close for change Enable integrateability (auth/auth, navigation) Create new system for new features Integrate and/or replace part Change-by-Extension Wednesday 5 February 14
48. Close for change Enable integrateability (auth/auth, navigation) Create new system for new features Integrate and/or replace part Change-by-Extension Wednesday 5 February 14
49. Close for change Change-by-Copy Wednesday 5 February 14
50. Close for change Enable integrateability Change-by-Copy Wednesday 5 February 14
51. Close for change Enable integrateability Copy System to A, B Change-by-Copy Wednesday 5 February 14
52. (A) (B) Close for change Enable integrateability Copy System to A, B Change-by-Copy Wednesday 5 February 14
53. (A) (B) Close for change Enable integrateability Copy System to A, B Evolve A parts Cut out B parts Change-by-Copy Wednesday 5 February 14
54. (A) (B) Close for change Enable integrateability Copy System to A, B Cut out A parts Evolve B parts Evolve A parts Cut out B parts Change-by-Copy Wednesday 5 February 14
55. (A) (B) Close for change Enable integrateability Copy System to A, B Cut out A parts Evolve B parts Evolve A parts Cut out B parts Change-by-Copy Wednesday 5 February 14
56. Define external, “ideal” interface Adapt to existing codebase Transform system to match interfaces Outside-in-Interfaces Wednesday 5 February 14
57. Define external, “ideal” interface Adapt to existing codebase Transform system to match interfaces Outside-in-Interfaces Wednesday 5 February 14
58. Define external, “ideal” interface Adapt to existing codebase Transform system to match interfaces Outside-in-Interfaces Wednesday 5 February 14
59. Limit Feature by Client Add new logic gradually Enable for specific client (user) groups only Allow for co-existence Wednesday 5 February 14
60. Remove Flexibility Analyze customizations by user/client kind Identify unused/rarely used paths Replace customizable parts with hard-coded alternatives Wednesday 5 February 14
61. Natural Death Separate old and new use cases + products Wednesday 5 February 14
62. Natural Death Separate old and new use cases + products Implement new logic in new parts Wednesday 5 February 14
63. Natural Death Separate old and new use cases + products Retire old parts once data is “dead” Implement new logic in new parts Wednesday 5 February 14
64. Architecture Backlog Treat issues as (special) features after analysis/evaluation! Wednesday 5 February 14
65. Architecture Backlog Treat issues as (special) features after analysis/evaluation! involve “Product owner“ Wednesday 5 February 14
66. Architecture Backlog Treat issues as (special) features after analysis/evaluation! involve “Scrum master“ involve “Product owner“ Wednesday 5 February 14
67. Front-end switch UI Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
68. Front-end switch Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
69. Front-end switch UI Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
70. Front-end switch UI Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
71. Front-end switch UI Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
72. Front-end switch UI Create new surface area (UI) Gradually replace backend parts Wednesday 5 February 14
73. «Your Pattern or Practice Here » Contributions welcome! → http://aim42.org Wednesday 5 February 14
74. Fazit Wednesday 5 February 14
75. These: Practices ersetzen Erfahrung nicht Wednesday 5 February 14
76. These: Erprobte Vorgehensweisen erleichtern Fokus aufs Wesentliche Wednesday 5 February 14
77. These: Grundsätzlich können wir ändern Wednesday 5 February 14
78. These: Techies müssen Notwendigkeit von Änderungen verkaufen Wednesday 5 February 14
79. These: Denken trotz Pattern- und Practice-Katalog erforderlich Logisches Wednesday 5 February 14
80. These: Spezifische Sprache erleichtert Kommunikation Wednesday 5 February 14
81. Questions? Comments? Dr. Gernot Starke, @gernotstarke gs@gernotstarke.de http://gernotstarke.de Stefan Tilkov, @stilkov stefan.tilkov@innoq.com http://www.innoq.com/blog/st/ innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH info@innoq.com Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270 Wednesday 5 February 14
82. References (excerpt) Books: ✓ M.Lippert, S.Roock: Refactoring in Large Software Projects: Performing Complex Restructurings Successfully (2006) ✓ M. Fowler: Refactoring ✓ M. Feathers: Working Effectively with Legacy Code. Research: ✓SERIOUS: „Software Evolution, Refactoring, Improvement of Operational & Usable Systems", ITEA-Eureka Project (2008) http://www.hitech-projects.com/euprojects/serious/deliverables.htm ✓ ATAM: Architecture Tradeoff Analysis Method, Software Engineering Institute, http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm Online: ✓practices see http://aim42.org for more Wednesday 5 February 14
83. Experience Report (Industry) Analyze: ✓ ATAM & qualitative analysis ✓ (extensive) stakeholder interviews ✓ Software Archeology approx 50 issues, problems found Evaluate: ✓Identifies ~5 issues as „safety critical production risk“ ✓ Identified architectural & code causes ✓ Cost of those issues: >100T€ Improve: ✓ Isolate-changes, introduce (internal) interfaces ✓ removal became high-priority for developers Wednesday 5 February 14