Die Vermessung der Welt

Transkript

1 Die Vermessung der Welt oder wie bewertet und beurteilt man komplexe Software-Systeme? SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 1

2 Technical Due Diligence? SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 2

3 The Challenges Geben Sie bitte das Gewicht des Gebäudes anhand des Bildes an......zu schwierig? Dann geben Sie doch bitte einfach die Höhe des Gebäudes an (Toleranz < 1%) SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 3

4 A kind of Definiton Due-Diligence-Prüfungen (sinngemäß übersetzt als im Verkehr erforderliche Sorgfalt ) analysieren Stärken und Schwächen des Objekts sowie die Risiken des Kaufs oder Börsengangs, und sie bewerten das Objekt. ~Wikipedia Ein Prozess um einen 360- Grad-Blick auf ein Unternehmen zu bekommen. Die Ermittlung von Fähigkeiten im Hinblick auf Stärken als auch Schwächen. Der Grundstein für eine zukünftige vertrauensvolle Zusammenarbeit Keine Torturen in Form unendlich langer Checklisten und Fragebögen. Kein Stresstest für das Management. Keine Kräftemessen oder Intelligenztest Keine Verzögerungstaktik um ein besseres Angebot finden SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 4

5 Technical Due Diligence Standard Due Diligence Vorgehen betrachten weitgehende nur Aspekte in den Bereichen: Produkte / Marktwirtschaft / Wettbewerb Finanzen Steuern Recht / Datenschutz / Intellectual Properties Personalwesen Liegenschaften / Technik Aspekte in den Bereichen der IT werden meist erst zum Zeitpunkt der Integration betrachtet SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 5

6 but what about Die Analyse und Bewertung von Software- und Hardware-Systemen sollten von Beginn an im Due Diligence Prozess berücksichtigt werden. Gegenüber anderen Aspekten ist die Bewertung jedoch komplexer: Software ist nicht sichtbar. Software ist nicht fassbar. Software kann man nur in direkt vermessen. Software verändert sich permanent. System, Plattformen und Softwarelösungen bilden komplette Eco-Systeme und sind in den meisten Businessabläufen erfolgskritisch. Mobile Apps, Web-Apps, Softwareprodukte und Online-Services sind heute feste Bestandteil von Produkten oder Service-Angeboten. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 6

7 Goals for Technical Due Diligence Ziel ist es den Wert, die Risiken aber auch das Potential der Softwaresysteme zu ermitteln, in dem Antworten auf konkrete Fragenstellungen gesucht werden: Komplexität für das Ändern und Hinzufügen neuen Funktionalität, Flexibilität und Erweiterbarkeit. Wartbarkeit und Robustheit des System. Bewertung hinsichtlich Software-Qualitätskriterien. Risiken und Stärken hinsichtlich Skalierbarkeit. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 7

8 Goals for Technical Due Diligence (cont.) System-Design, Code-Größe, Technologien und Komplexität. Abhängigkeiten von Third-Party-Komponenten. Security, Datenschutz und rechtliche Risiken. Skills des Entwicklungsteam, Praktiken und Prozesse, Operations-Praktiken. Openess hinsichtlich APIs und der Unterstützung von Standards. Internationalisierung, Portabilität, Standardisierung. Integrationsaufwände. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 8

9 Quality attributes. Qualitätsmerkmale betreffen alle Bereiche eines Systems. Auch als systemic qualities, *illities benannt. Einschränkungen bezüglich Zeit, Kosten, Anforderungen und Ressourcen führen oft zum Abwägen bezüglich der Umsetzung. Usage Usability Localization Accessibility Personalization Customizability Development Manageability Maintainability Supportability Extensibility Flexibility Operation Performance Reliability Availability Scalability Security Attacks Privacy Misuse Legislation SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 9

10 Code Quality Assessment Design Principles and documentation Coding standards and reviews Source code static analysis and metrics Security and encryption protocols Version control practices Exception handling and error notification API Design Technologies, Frameworks and Components Not-Invented-Here-Problematik SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 10

11 Development Environment Assessment Development methodologies Change Management Requirements Management Unit, functional, and integration testing processes Continuous integration / Automated deployments Quality Management / Test automation Team discipline and project management Functional backups & staging environment SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 11

12 Operations and Security Assesment Rollout and Deployment Prozess Monitoring and Alerting Incident Management Network Diagramm Review Review Data Center SLAs Security Awareness / Security Policies Vulnerability Scan Automated Penetration-Test Code- and Architecture Reviews regarding crytographie usage SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 12

13 Risk Levels. Geringes Risiko Geringe Gefahr Anzeigen von internen Informationen Ineffiziente Nutzung von Ressourcen Eingeschränkte Nutzbarkeit und Flexibilität Performancedegeneration Suboptimale zukünftige Managebarkeit des Produktes Niedrige finanzielle Auswirkungen Mittleres Risiko Einschränkung eines Sicherheitsziels Hohes Schadenspotential mit niedriger Eintrittswahrscheinlichkeit Grundlegende Vorgehen nach dem Stand der Technik ist nicht gegeben Verletzung von Lizenz- oder Patentrechten Kontinuierliche Verschlechterung der Produkt- und Code-Qualität Einschränkungen bezüglich Performance und Betrieb Mittlere Finanzielle Verluste Hohes Risiko Gefährdung eines Sicherheitsziels Verstöße gegen rechtliche Anforderungen oder Richtlinien Ausnutzen von Schwachstellen durch Hacker Grobe Verletzung von Lizenz- oder Patentrechten Aufwände für Weiterentwicklung sind nicht schätzbar Sehr hohe Aufwände für die Einhaltung von Qualitätsanforderungen erforderlich Hohe finanzielle Schäden Kritisches Risiko Gefährdung eines Sicherheitsziels wahrscheinlich Verlust von vertraulichen Daten Triviales Ausnutzen von Schwachstellen Betrieb- und Nutzung der Produkte ist gefährdet Grundlegende Qualitätsstandards sind gewährleistet Schadensansprüche aus Verstöße gegen rechtliche Anforderungen Nachhaltige finanzielle Verluste SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 13

14 Blind men and an elephant Einst lies der Raja in Indien sechs blind geborene Männer versammeln, damit sie einen Elefanten erleben um ihn zu beschreiben. Nachdem die blinden Männer den Elefanten befühlt hatten, ging der Raja zu jedem von ihnen und sagte, Ihr habt einen Elefanten erlebt, ihr Blinden? So ist es, Majestät. Wir haben einen Elefanten erlebt. Nun sagt mir, ihr Blinden: Was ist denn ein Elefant? Sie versicherten ihm, dass der Elefant sei wie ein Topf (Kopf), ein weicher Korb (Ohr), eine Pflugschar (Stoßzahn), eine Schlange (Rüssel), eine Baum (Bein), oder ein Seil(Schwanz). Man muss sich seiner eingeschränkten Wahrnehmung und Perspektive bewusst sein um die richtigen Entscheidungen zu treffen. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 14

15 Software Architecture The reason that good architectures are centered around use-cases is so that architects can safely describe the structures that support those use-cases without committing to frameworks, tools, and environment. ~ Robert C. Martin (Uncle Bob) SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 15

16 Principles of good Software Architecture Scalable Extensible Reusable Testable Maintainable Open Common semantics Secure Keep it stupid simple Business Anforderungen Kosten für Entwicklung und Pflege Skills des Entwicklungsteams Grenzen der genutzten Technologie Integration Effizienz Product Life Cycle Keine neuen Anforderungen Zertifizierungen Joined Development SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 16

17 Design Principles we expect The Single Responsibility Principle A class should have one, and only one, reason to change. The Open Closed Principle You should be able to extend a classes behavior, without modifying it. The Liskov Substitution Principle Derived classes must be substitutable for their base classes. The Dependency Inversion Principle Depend on abstractions, not on concretions. The Interface Segregation Principle Make fine grained interfaces that are client specific. The Public API Separation Principle External Interaction is encapsulated in a consistent designed API SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 17

18 Design Principles we expect (cont.) The Release Reuse Equivalency Principle The granule of reuse is the granule of release. The Common Closure Principle Classes that change together are packaged together. The Common Reuse Principle Classes that are used together are packaged together. The Acyclic Dependencies Principle The dependency graph of packages must have no cycles. The Stable Dependencies Principle Depend in the direction of stability. The Stable Abstractions Principle Abstractness increases with stability. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 18

19 Our current approach Nutzung eines Fragenkatalogs als Checkliste (ca. 150 unterschiedliche Fragen und Aspekte) Wird den Partner vorab zu Vorbereitung zur Verfügung gestellt Fragen werden aber in den Interview-Session gemeinschaftlich beantwortet In den Interview-Session ergeben sich aus den Antworten und Reaktionen oft weitere Fragenstellungen, die bei der Gesamteinschätzung helfen. Transparenz des gesamten Prozesses für den Partner. Falls möglich nutzen wir entsprechende Tools für die automatisierte Analyse des Source-Codes (Fortify, Sonar, FxCop, etc.) Bewertungen erfolgen auf Basis von vier Risikoklassen SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 19

20 The real world constraints Zeitrahmen meist sehr begrenzt: max. 2-3 Tage für Interviews und Assesments vor Ort ca Tage für Analyse und Bericht Der Sourcecode steht nur bedingt zur Inspektion zur Verfügung. Der Mix einer Vielzahl von Technologien, Frameworks, Sprachen macht die automatisierten Erhebung von Metriken und deren Bewertung sehr schwierig. Es steht nur eine bedingt nutzbare bis gar keine technische Dokumentation zur Verfügung. Technische Experten stehen für das Interview nicht zur Verfügung. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 20

21 Analyse und Metriken Wir nutzen unterschiedliche Metriken zur Bewertung der Code- und Architektur-Qualität: Lines of Code / Executive Lines of Code HC Halstead Complexity CCN - Cyclomatic Complexity Number / McCabe MI - Maintainability Index ACD - Average Component Dependency Die Metriken dienen aber nur zur Erhebung eines groben Gesamtbildes und als Orientierung für weitere Stichproben. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 21

22 Third-Party und Open Source In vielen Firmen gibt es keinen zentrales Repository über die genutzten Fremdkomponenten. Implikationen auf lizenzrechtliche Aspekte Auswirkungen auf Sicherheitsaspekte Auswirkung auch auf Effizienz und Wartbarkeit Wir erstellen auf Basis einer vom Partner durchgeführten Bestandsaufnahme eine entsprechende Risikobetrachtung SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 22

23 Technical Due Diligance Report Der Report wird meist nicht gelesen, mit Ausnahme des Management Summary. Gewünscht ist im Management Summary eine konkrete Entscheidungsempfehlung. Versuchen Sie für den aktuellen Status, Potential und Risiken möglichst auch eine grafische Darstellung. Ein Report wird erst dann kritisch gelesen, wenn es später zu Schwierigkeiten kommt. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 23

24 Lessons learned und some advices Sprechen sie mit dem Management die potentiellen Ziele der Akquisition zu Beginn ab. Kommunizieren sie auf gleicher Augenhöhe mit dem Partner. Suchen sie nicht nur nach den Schwächen und Risiken Spielen Sie in den Interviews zukünftige Szenarien durch Achten Sie auf outgesourcte Skills und Verantwortlichkeiten Berücksichtigen sie rechtzeitig die auch die möglichen Integrationszenarien Kommunizieren sie ihre Findings offen. Nutzen sie die Chance den Bericht vorab durch den Partner auf die sachliche Richtigkeit reviewen zu lassen. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 24

25 Lessons learned und some advices Nehmen Sie den Partner mit in die Verantwortung, durch Bereitstellung von entsprechenden Informationen. Falls keine Dokumentation zur Verfügung steht, erarbeiten sie mit den beteiligten Architekten einen Architekturmodell. Überprüfen sie die lizenzgerechte Nutzung von Third-Party Komponenten (speziell Open Source). Machen Sie Stichproben im Sourcecode und nutzen Tools zur Code-, Architektur-, System- und Security-Analyse. Überbewerten sie keine Software-Metriken. Sprechen Sie die Findings im Team durch (speziell Lizenz Problematiken oder Security und Datenschutz). Erarbeiten Sie eine Checkliste und eine Vorgehensmodell. SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 25

26 Do not hire a man who does your work for money, but him who does it for love of it. ~Henry David Thoreau SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 26

27 grazie. Ralf Hofmann SEACON 2012 // Author Ralf Hofmann // Copyright 2012 elvido // 06-JUN-12 // 27