"Die Vermessung der Welt"- oder wie bewertet und beurteilt man komplexe Software-Systeme?

„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

Technical Due Diligence?

                 SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  2

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

A kind of Definiton…

  “Due-Diligence-Prüfungen                       Ein Prozess um einen 360-

 (sinngemäß übersetzt als „im
                                                  Grad-Blick auf ein
                                                  Unternehmen zu bekommen.

 Verkehr erforderliche Sorgfalt“)
                                                 Die Ermittlung von Fähigkeiten
                                                  im Hinblick auf Stärken als
                                                  auch Schwächen.
 analysieren Stärken und                         Der Grundstein für eine
                                                  zukünftige vertrauensvolle
 Schwächen des Objekts sowie                      Zusammenarbeit

 die Risiken des Kaufs oder                      Keine Torturen in Form
                                                  unendlich langer Checklisten

 Börsengangs, und sie
                                                  und Fragebögen.
                                                 Kein Stresstest für das

 bewerten das Objekt.“
                                                  Management.
                                                 Keine Kräftemessen oder
                                                  Intelligenztest
                          ~Wikipedia             Keine Verzögerungstaktik um
                                                  ein besseres Angebot finden

                                 SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  4

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

…but what about

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

                                             SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  6

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

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

Quality attributes….

      Qualitätsmerkmale betreffen alle Bereiche eines
       Systems.
      Auch als “systemic qualities”, “*illities” benannt.
      Einschränkungen bezüglich Zeit, Kosten, Anforder-
       ungen und Ressourcen führen oft zum Abwägen
       bezüglich der Umsetzung.
Usage                 Development           Operation                            Security
   Usability            Manageability        Performance                            Attacks
   Localization         Maintainability      Reliability                            Privacy
   Accessibility        Supportability       Availability                           Misuse
   Personalization      Extensibility        Scalability                            Legislation
   Customizability      Flexibility

                                                         SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  9

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

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

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

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

                                                                      SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  13

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            Man muss sich seiner
 haben einen Elefanten erlebt.“ – „Nun sagt                   eingeschränkten
 mir, ihr Blinden: Was ist denn ein Elefant?“                 Wahrnehmung und
                                                              Perspektive bewusst
 Sie versicherten ihm, dass der Elefant sei wie
                                                              sein um die richtigen
 ein Topf (Kopf), ein weicher Korb (Ohr), eine                Entscheidungen zu
 Pflugschar (Stoßzahn), eine Schlange                         treffen.
 (Rüssel), eine Baum (Bein), oder ein
 Seil(Schwanz).
                                               SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  14

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

Principles of good Software Architecture…

    Scalable                                  Business Anforderungen
                                               Kosten für Entwicklung
    Extensible                                 und Pflege
                                               Skills des
    Reusable                                   Entwicklungsteams
                                               Grenzen der genutzten
    Testable                                   Technologie

    Maintainable                              Integration

                                               Effizienz
    Open                                      Product Life Cycle

    Common semantics                          Keine neuen
                                                Anforderungen
    Secure                                    Zertifizierungen
                                               Joined Development
    “Keep it stupid simple”

                               SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  16

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

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

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

The real world constraints…

  Zeitrahmen meist sehr begrenzt:
       max. 2-3 Tage für Interviews und Assesments vor Ort
       ca. 7-10 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

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

Third-Party und Open Source

 In vielen Firmen gibt es keinen zentrales
  Repository über die genutzten Fremd-
  komponenten.
   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

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

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

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

“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

grazie.                  Ralf Hofmann
                         ralf.hofmann@live.com

          SEACON 2012 // Author Ralf Hofmann // Copyright © 2012 elvido // 06-JUN-12 //  27