Produktivität in der Software-Entwicklung

Transkript

1 Workshop Hot-Spots der Software-Entwicklung Produktivität in der Software-Entwicklung 16. Oktober 2008 Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy BICC-NET Bavarian Information and Communication Technology Cluster Florian Deißenböck Martin Fritzsche

2 Inhaltsverzeichnis 1 Einleitung 3 2 Teilnehmerliste 4 3 Programm 5 4 Florian Deißenböck»Produktivität Begriffsklärung«6 5 Melanie Ruhe»Produktivität in Forschung und Entwicklung - Rätsel oder Vision?«10 6 Dirk Taubner»Testmanagement und -automatisierung«18 7 Wolfgang Mansel»Produktivität bei der Softwareentwicklung für Bordrechner«39 8 Markus Pizka»Produktivität pragmatisch messen und wirksam steigern«49 2

3 1 Einleitung Aufgrund des hohen Zeit- und Kostendrucks in Softwareprojekten ist Produktivität in der Softwareentwicklung heute eines der Schlüsselthemen für Firmen in allen Anwendungsbereichen. Entsprechend vielfältig ist die Landschaft bisheriger Arbeiten, die einzelne Einflussfaktoren für Produktivität behandeln. Nichtsdestotrotz mangelt es bisher an einer allgemein akzeptieren Definition von Software-Produktivität sowie an einem umfassenden Verständnis der Zusammenhänge zwischen einzelnen Faktoren. Dementsprechend stehen in der Praxis bisher nur relativ eingeschränkte Methoden für Bewertung, Vergleich und insbesondere für die strukturierte Optimierung von Produktivität zur Verfügung. Ziel des Workshops war es, sowohl zum besseren grundsätzlichen Verständnis des Themas Produktivität in der Softwareentwicklung beizutragen als auch konkrete Methoden zu diskutieren, deren Einsatz im Unternehmen zur Bestimmung und Verbesserung von Produktivität beiträgt. 3

4 2 Teilnehmerliste Wolfgang Auer, Lebensversicherung von 1871 Gerd Beneken, Fachhochschule Rosenheim Wilhelm Braunschober, Krauss-Maffei Wegmann GmbH & Co KG Prof. Dr. Dr. h.c. Manfred Broy, TU München Dr. Beat Bühler, ATOSS Florian Deißenböck, TU München Roland Dürre, Interface AG Harald Elsperger, xpecto AG Heiko Erhardt, Giesecke & Devrient GmbH Martin Feilkas, TU München Peter Fleischer, Munich Airport Preben Folkjaer, Münchner Rück Martin Fritzsche, TU München Michael Greulich, Interface AG Ludwig Groten, Realtime Technology AG German Hehn, Giesecke & Devrient GmbH Wolfgang Hirschel, ESG GmbH Michael Hübler, BMW Group Thomas Hutter, S-REFIT AG Shareeful Islam, TU München Dirk Jepsen, ADAC e.v. Michael Kiesewetter, BMW Group Harald Kirschner, Integranova GmbH Bernd Koester, ABSC GmbH Bert Kaubisch, Kaubisch AV Sebastian Köhler, SpaceNet AG Dr. Stefan Kriebel, BMW Group Dr. Uwe Kühne, EADS Peter Lacher, Audi Electronics Venture GmbH Klaus Lochmann, TU München Hannes Mahlknecht, INTERASCO GmbH Dr. Wolfang Mansel, EADS Daniel Méndez-Fernández, TU München George Mesesan, MicroDoc GmbH Ludger Meyer, Siemens AG Dr. Carsten Ohlemeyer, Lebensversicherung von 1871 Nils Oppermann, Audi Electronics Venture GmbH Friedrich Ostermann, Konzeptwerk GmbH Dr. Markus Pizka, itestra GmbH Thomas Raab, S-REFIT AG Harald Ranner, Munich Airport Regina Rieder, Finanz Informatik GmbH & Co. KG Anton Röckseisen, Krones AG Melanie Ruhe, Siemens AG Ulrich Scholtze, coopt GmbH Markus Schwalb, mobilex AG Rainer Singvogel, msg systems ag Dr. Oscar Slotosch, Validas AG Melanie Späth, sd &m Jochen-Michael Speek, VR Kreditwerk Hamburg Bernhard Steckenbiller, Munich Airport Dr. Dirk Taubner, msg systems ag Joachim Terasa, coming GmbH Hans-Jürgen Thönnißen, ESG GmbH Gert Unterhofer, INTERASCO GmbH Hans-Georg Vogel, EADS Dr. Stefan Wagner, TU München 4

5 3 Programm 14:00 Begrüßung Prof. Dr. Dr. h.c. Manfred Broy, Technische Universität München 14:10 Produktivität Begriffsklärung Florian Deißenböck, Technische Universität München 14:30 Produktivität in Forschung und Entwicklung - Rätsel oder Vision? Melanie Ruhe, Siemens AG 15:15 Mehr Effizienz durch professionelles Testmanagement und -automatisierung Dr. Dirk Taubner, msg systems ag 16:00 Kaffee-Pause 16:15 Einflussfaktoren auf die Produktivität bei der Softwareentwicklung für Flugzeug Bordrechner Dr. Wolfgang Mansel, EADS Deutschland GmbH 17:00 Produktivität pragmatisch messen und wirksam steigern Dr. Markus Pizka, itestra 17:45 Abschlussdiskussion 18:15 Empfang 5

6 4 Florian Deißenböck»Produktivität Begriffsklärung«M. Broy, F. Deißenböck, S. Wagner Produktivität Begriffsklärung 16. Oktober 2008 HSE-Workshop»Produktivität in der Software-Entwicklung«Deißenböck Produktivität Begriffsklärung Produktivität Produktivität = Ausbringungsmenge Einsatzmenge = Output Input Person, Abteilung, Unternehmen, Branche, Nation? Quantifizierung von Ein-/Ausgaben? Stück, kg, PM,, LOC, FP? Basiert auf Characteristika von Fertigungsprozessen Signifikante Unterschiede zwischen Fertigung und»knowledge Work«Faktoren: Individuelle Fähigkeiten, Werkzeuge, Sprachen, Methoden, Qualität, Kundenzufriedenheit, Projekterfolg, Innovation? Deißenböck Produktivität Begriffsklärung 2 6

7 Wirtschaftlichkeit Wirtschaftlichkeit = Ertrag Aufwand Vereinheitlichung durch monetäre Einheiten Bestimmung von Ertrag und Aufwand oft schwierig Einflussfaktoren noch vielfältiger als bei Produktivität Externe Faktoren wie Kosten, Inflation, verändern Wirtschaftlichkeit bei konstanter Produktivität Zwischen Produktivität und Wirtschaftlichkeit liegt der Markt Deißenböck Produktivität Begriffsklärung 3 Performance Oft gar nicht oder sehr vage definiert Wird vielfach mit Produktivität gleich gesetzt Umfasst jedoch viele Faktoren jenseits der Produktivität Financial Perspective Customer Perspective Innovation and Learning Perspective Internal Business Perspective Balanced Scorecard Deißenböck Produktivität Begriffsklärung 4 7

8 Effektivität & Effizienz Effektivität Maß für die Zielerreichung»die richtigen Dinge tun«beeinflusst hauptsächlich den Zählers des Produktivitäts-Quotients Betrifft meist den Kunden Effizienz Maß für Ressourcen-Nutzung»die Dinge richtig tun«beeinflusst hauptsächlich den Nenner des Produktivitäts-Quotients Oft mit Produktivität gleich gesetzt Deißenböck Produktivität Begriffsklärung 5 Qualität»Productivity of knowledge work therefore has to aim first at obtaining quality [ ]. Only then can one ask: What is the volume, the quantity of work?«peter F. Drucker Messung der Quantität ohne Messung der Qualität bedenklich Software-Qualität ist schwer zu bewerten Bisher auch bei Nicht-Software-Produkten kaum anwendbare Konzepte für Berücksichtigung von Qualität bei Produktivitäts-Überlegungen Bei Software interessanter Zusammenhang zwischen Qualität und Quantität Deißenböck Produktivität Begriffsklärung 6 8

9 Zusammenhänge Kundenwahrnehmung, Innovation Performance Wirtschaftlichkeit Produktivität Ziel Effizienz Effektivität Funktionalität Qualität Aufwand Marktmechanismen basiert auf Triple-P-Model von S. Tangen, 2005 Deißenböck Produktivität Begriffsklärung 7 Zusammenfassung»The field is filled with practitioners with no conceptual models and weak operational definitions; the field is filled with academicians with weak conceptual models and no operational definitions. The result has been confusion in the literature and in practice [ ].«Sink & Tuttle, 1989 Unklare Terminologie im Bereich Produktivität Unklare Begriffe sind kein exklusives Problem des Software-Engineering Saubere Begriffe fördern den strukturierten Umgang mit Produktivität Deißenböck Produktivität Begriffsklärung 8 9

10 5 Melanie Ruhe»Produktivität in Forschung und Entwicklung - Rätsel oder Vision?«Corporate Technology Corporate Technology Produktivität in der Entwicklung Rätsel oder Vision? Produktivität in der Entwicklung Melanie Ruhe Rätsel oder Vision? Melanie Ruhe Hot Spots der SW-Entwicklung, München, den 16/10/2008 Hot Spots der SW-Entwicklung, München, den 16/10/2008 Contact Melanie Ruhe, CT SE 3 Tel.: +49 (89) melanie.ruhe@siemens.com Contact Melanie Ruhe, CT SE 3 Tel.: +49 (89) Copyright Siemens AG Alle Rechte vorbehalten. melanie.ruhe@siemens.com Copyright Siemens AG Alle Rechte vorbehalten. Siemens is One of the World s Largest Software Companies Siemens is One of the World s Largest Software Companies Seite 2 Siemens AG, Corporate Technology Seite 2 Siemens AG, Corporate Technology 10

11 Corporate Technology Kerntechnologien, Kompetenzen und Leistungen für Siemens Corporate Technology Kerntechnologien, Kompetenzen Kunden Leistungen für Siemens Unternehmensprojekte, Unternehmensprojekte, top+ innovation top+ innovation Corporate Technology (CT) Corporate Seite Technology 4 (CT) Sektoren / Divisions Kunden Sektoren / Divisions Energie Industrie Gesundheit Energie Industrie Gesundheit Corporate Research and Technologies (CT T) Kerntechnologien und -kompetenzen mit Mehrfachnutzen Pictures of the Future Corporate Research and Acceleratoren für neue Technologies Geschäftsmöglichkeiten (CT T) Kerntechnologien und -kompetenzen mit Mehrfachnutzen Pictures of the Future Acceleratoren für neue Geschäftsmöglichkeiten Regionen Regionen Corporate Intellectual Property and Functions (CT I) Intellectual Property Services und Strategie Standardisierung, Corporate Umweltangelegenheiten, Intellectual Property and Information Functions Research (CT I) Center Intellectual Property Services und Strategie Siemens AG, Corporate Technology Standardisierung, Umweltangelegenheiten, Information Research Center Seite Siemens AG, Corporate Technology Corporate Technologies (CT) Technologieabteilung Software & Engineering (SE) Corporate Technologies (CT) Technologieabteilung Software & Engineering (SE) Best Practice Networking Analyse und Engineering komplexer Systeme Best Practice Networking Engineering Software Analyse und Engineering komplexer Systeme Initiative Project Management and Systems Innovation Beratung von der Technologie Engineering Zu erfolgreichem Geschäft Project Management and Innovation USA Beratung von der Technologie Zu erfolgreichem Geschäft Seite Systems Software Initiative Qualität und Effizienz in der Softwareentwicklung Development Technologies Qualität und Effizienz in der Softwareentwicklung Software Development& Engineering Technologies USA Software Regional & Information Broker Verfolgung neuester Entwicklungen in führenden Unternehmen Architecture System and Software Processes Softwarearchitekturen für verteilte, mobile und eingebettete Systeme in führenden Unternehmen Verfolgung neuester Entwicklungen Softwarearchitekturen für verteilte, mobile und eingebettete Systeme Offices Architecture Prozessassessments und Prozessinnovationen Russland System and Software Regional China Processes Offices Prozessassessments und Indien Prozessinnovationen Russland Engineering China Indien Information Broker Siemens AG, Corporate Technology Seite Siemens AG, Corporate Technology 11

12 Motivation Motivation productivity = output input output Measurement productivity of output = by size metrics (e.g. lines of code) does not reflect added input value Complexity measurement reflects complexity of the solution only, but less complex solutions may Measurement generate more of added output value by size metrics (e.g. lines of code) does not reflect added value Science has very divergent opinion about productivity Complexity measurement reflects in R&D complexity organizations of the solution only, but less complex solutions may generate more added value Science has very divergent opinion about productivity Productivity measurement of R&D in R&D address organizations the myth with a different approach!? "output" of manufacturing "output" of manufacturing output as set of identical units => can be directly output as set of identical units derived from number of units "output" of => can be development directly derived from number of units "output" of development output as set of non-identical, interdependent units => cannot be directly output as set of Productivity of R&D address the derived from number of non-identical, units interdependent myth with a different approach!? units Seite 6 October 2008 M. Ruhe, CT SE 3 Corporate Technology => cannot be directly derived from number of units Seite 6 October 2008 M. Ruhe, CT SE 3 Corporate Technology Motivation (II) R&D organizations need to generate value for the customer effectiveness Motivation (II) as well as need to deliver value in time! efficiency R&D organizations need to generate value for the customer effectiveness as well as need to deliver value in time! efficiency Source: Todd Little- Value Creation and Capture, IEEE Software 2004 R & D value creation Productivi ty = Effective R & D budget sales volume vs. sustainable value Source: Todd Little- Value Creation and Capture, IEEE Software 2004 Seite 7 October R 2008 & D value M. creation sales volume vs. Ruhe, CT SE 3 Corporate Technology Productivi ty = sustainable value Effective R & D budget Seite 7 October 2008 M. Ruhe, CT SE 3 Corporate Technology 12

13 Focus Focus R & D value creation Productivi ty = Effective R & D budget R & D value creation Productivi ty = Effective R & D budget We want to understand the value creation process and find levers to increase R&D value creation in your organization? We want to understand the value creation process and find levers Increase to increase value R&D creation value instead creation of in reduce your organization? costs Questions: Questions: Increase value creation instead of reduce costs What are major value creating activities? What are the major influences for value creation? Who is the customer? What are major value creating activities? What are the major influences for value creation? Who is the customer? Seite 8 October 2008 M. Ruhe, CT SE 3 Corporate Technology Seite 8 October 2008 M. Ruhe, CT SE 3 Corporate Technology Literature Review on Productivity Management / Measurement Literature Review on Productivity Management / Measurement Represent sample levers for a single organisation Represent sample levers Source: for a single Capers organisation Jones about 2000 projects of (SPR) were examined Source: Capers Jones about 2000 projects of (SPR) were examined Many studies use typical productivity levers as fixed / not flexible model and analyze their individual degree of influence on productivity Within Siemens we develop a wide range of products & solutions; so far the fixed Many model studies approach use typical did productivity not sufficiently levers address as fixed the / organizational not flexible model specifics and analyze their individual degree of influence on productivity Within Siemens we develop a wide range of products & solutions; so far the fixed model approach did not sufficiently address the organizational specifics Seite 9 October 2008 M. Ruhe, CT SE 3 Corporate Technology Seite 9 October 2008 M. Ruhe, CT SE 3 Corporate Technology 13

14 Our new approach: ProdFLOW Productivity in R&D with FLOW Our new approach: ProdFLOW Productivity in R&D with FLOW R & D value creation Productivi ty = Effective R & D budget R & D value creation Productivi ty = Effective R & D budget - org.-specific model - indirect measurement of relative - org.-specific productivity model increase - indirect measurement of relative productivity increase The main goal is to balance the (3-5) major org.-specific levers as best as possible to increase R&D value creation! Seite 10 October 2008 M. Ruhe, CT SE 3 Corporate Technology The main goal is to balance the (3-5) major org.-specific levers as best as possible to increase R&D value creation! Seite 10 October 2008 M. Ruhe, CT SE 3 Corporate Technology Example: List of identified Levers L1 Example: Work flow List disturbances of identified and Levers multitasking L2 Peer-Communication (Communication on the same org.level) L3 L1 Knowledge Work flow disturbances documentation and and multitasking retrieval L4 L2 Requirements Peer-Communication Stability(Communication on the same org.level) L3 L5 Cooperation Knowledge documentation between R&D and retrieval product management L6 L4 Staff Requirements Turnover Stability L7 L5 Team Cooperation Cohesion between R&D and product management L8 L6 Clear Staff Turnover goals L9 L7 Information Team Cohesion Flow within the team L8 Clear goals Information Flow within the team L9 Seite 11 October 2008 M. Ruhe, CT SE 3 Corporate Technology Seite 11 October 2008 M. Ruhe, CT SE 3 Corporate Technology 14

15 1 1 Example: Lever Matrix Internal View Importance Example: Lever Matrix Importance External View Very High Importance Low Low High Very High High Very Low Very Low L4 L4 L8 L6 Low L5 L1 Internal View L8 L6 Low L7 L1 L2 L3 L2 L9 L3 High L9Very High Improvement Potential Very High Low Low High Very High High Very Low Decisions about TOP Levers: L1, L2, L3 L5 L7 High Very High Improvement Potential Importance Very Low Decisions about TOP Levers: L1, L2, L3 Very HighImprovement Potential Seite 12 October 2008 M. Ruhe, CT SE 3 Corporate Technology L4 L4 External View L7 L7 L6 L6 L5 Low L5 Low L2 L8 L2 L9 L9 L8 High High L1 L3 L1 L3 Very HighImprovement Potential Seite 12 October 2008 M. Ruhe, CT SE 3 Corporate Technology Define Lever indicators and initiate improvement Definition of suitable measurement / evaluation methods as well as indicators Define Lever indicators and initiate improvement for the selected major levers Define and plan productivity improvement measures to increase major Definition productivity of levers suitable based measurement on the identified / evaluation ideasmethods as well as indicators for the selected major levers Stimme Voll Zu Zustimmung bzw. Ablehnung in % (siehe Farbschema): 05/2008 Stimme Zu Define and plan productivity improvement measures to increase major productivity levers based on the identified ideas L3: Wissensrecherche Ich erachte den Umfang des Rechercheergebnisses als passend. 2,7 Das gefundene Wissen ist meiner Ansicht nach korrekt. 2,3 L3: Wissensrecherche Zustimmung bzw. Ablehnung in % (siehe Farbschema): 05/2008 Das gefundene Wissen ist meiner ,6 Ansicht Ich erachte nach den vollständig. Umfang des Rechercheergebnisses als passend. 2,7 Das gefundene Wissen ist meiner Ansicht Das gefundene nach aktuell. Wissen ist meiner 3, Ansicht nach korrekt. 2,3 Das gefundene Wissen hat mir ,6 geholfen. Das gefundene Wissen ist meiner Ansicht nach vollständig. 3,6 Das gesuchte Wissen steht mir schnell zur Das Verfügung. gefundene Wissen ist meiner 2, Ansicht nach aktuell. 3, Das Informationsmanagement-System stellt für mich eine wichtige Das gefundene Wissen hat 2, mir dar Informationsquelle geholfen. 2,6 Stimme teilweise zu Stimme teilweise nicht zu Stimme Stimme nicht Voll Zu zu Stimme Stimme überhaupt Zu nicht Zu Stimme teilweise zu Stimme teilweise nicht zu Stimme nicht zu Stimme überhaupt nicht Zu Das gesuchte Wissen steht mir schnell zur Verfügung. 2, Das Seite Informationsmanagement-System 13 October 2008 M. Ruhe, CT SE 3 Corporate Technology stellt für mich eine wichtige 2, Informationsquelle dar. Seite 13 October 2008 M. Ruhe, CT SE 3 Corporate Technology 15

16 Evaluate Balance using Bayesian Belief Networks Evaluate Balance using Bayesian Belief Networks - BBN s handle uncertainty - BBN s handle different scales - support BBN s handle scenario uncertainty simulation - BBN s handle different scales - support scenario simulation Seite 14 October 2008 M. Ruhe, CT SE 3 Corporate Technology Seite 14 October 2008 M. Ruhe, CT SE 3 Corporate Technology Benefits of ProdFLOW and Outlook Benefits of ProdFLOW and Outlook Revised understanding of productivity in the area of R&D Identify and become aware of major Revised understanding of productivity value creating activities in the area of R&D Objective and efficient analysis of major Identify and become aware of major bottlenecks in the R&D organization with value creating activities respect to value creation Objective and efficient analysis of major Research to do: how to define and measure the value of a potential bottlenecks in the R&D organization with products and/or solutions (apart from its pure economical value) respect to value creation Research to do: how to define and measure the value of a potential products and/or solutions (apart from its pure economical value) Seite 15 October 2008 M. Ruhe, CT SE 3 Corporate Technology Seite 15 October 2008 M. Ruhe, CT SE 3 Corporate Technology 16

17 For further information don t hestitate to contact me: Melanie Ruhe melanie.ruhe@siemens.com Phone: Mobile: Seite 16 October 2008 M. Ruhe, CT SE 3 Corporate Technology 17

18 6 Dirk Taubner»Mehr Effizienz durch professionelles Testmanagement und -automatisierung«mehr Effizienz durch professionelles Testmanagement und -automation Recardo Jackson, Dirk Taubner 16. Oktober 2008 TU München B msg systems ag, Jackson/Taubner Überblick Test- & Qualitätsmanagement Branchenschwerpunkte: Insurance Reinsurance Finance Automotive Healthcare Themen: Testmanagementberatung Konzeption, Testmethodik und -technik, u.v.m. Testautomatisierung Toolevaluierung, Testautomatisation, Beratung, Coaching Performancetests Last-, Stress-, Applikationstests, Sizing, Tuning Software Change- und Configurationmanagement Prozess- und Toolberatung (HP, SAP SolMan) Lösungen: msg.testsuite Bibliothek von manuellen und automatisierten Testfällen msg.testframework Testautomatisierung mit geringem Wartungsaufwand msg.batchanalyser Performanceoptimierung von umfangreichen Batches msg.testcenter Test-Support / On-/Offsite Übernahme von Testaktivitäten Partner: Performance- Team Experten Testmanagement Testkoordination Testcoaching Testautomations- Team Special Expertise Partner Test & Quality Management & Zugriff auf msg-pool von Fachberatern Datenbankexperten Systemadministratoren ABAP/Java/.Net/VB-Entwicklern B msg systems ag, Jackson/Taubner 2008 Übersicht 2 18

19 Häufig vorgefundene Ausgangssituation Testfallerstellung - Testfallbeschreibungen verteilt in MS EXCEL oder MS WORD - Keine Referenzierung auf die Fachkonzept/Anforderungen, z.t. lückenhafte Dokumentation - Mehrere Tausend beschriebene Testfälle, hohe Redundanz - Aktualität fraglich, da hoher Anpassungsaufwand Manuelles Testen Hauptsächlich Funktionstests, keine Prozesstests Akzeptanz beim Testen sehr niedrig Testaufwand hoch, da eingeschränkte Testautomation Qualität mangelhaft Kundenzufriedenheit in Gefahr Spätes Erkennen der Fehler führt zu hohen Kosten Ca. 40% der Entwicklungskapazitäten für Fehlerkorrekturen Fehlerverfolgung - Kein integriertes Defect Management - Führen einer offene Punkte Liste B msg systems ag, Jackson/Taubner Herausforderungen für die IT Dynamische Veränderungen im Markt und in Unternehmen Anpassung der Geschäftsanforderungen und Geschäftsprozesse Mergers & Acquisitions Re-Organisationen Neue Produkte, Kundensegmente, Lieferanten Skalierbarkeit der Anwendungen Zunahme Compliance Anforderungen Umstellung auf neue Standards, z. B. International Financial Reporting Standard (IFRS) Einhaltung von Compliance Richtlinien, z. B. SOX, SEC, FDA, Basel2, Solvency II Revisionssicherheit Dokumentationsvorschriften der Wirtschaftsprüfung Herausforderungen im Applikations- Lebenszyklus Kürzere Anpassungs- und Änderungszyklen Regelmäßige Patches, Bug Fixes, Support Packages Upgrades Unicode-Umstellung Steigender Kostendruck Notwendigkeit von Standardisierung und Automatisierung Trend zu Zentralisierung und Auslagerung Heterogene Systemlandschaften Integrative Geschäftsprozesse, die mehrere Plattformen nutzen Vielzahl von Schnittstellen und Zusatzentwicklungen Integration von Drittanbieter-Anwendungen B msg systems ag, Jackson/Taubner

20 Herausforderungen im Testmanagement Testprozess Abgestimmtes Release-, Anforderungs-, Test- und Testdaten- Management Einbeziehung von Fachanwendern in Qualitätsprozesse ( echte Bedürfnisse berücksichtigen) Revisionssicherheit des Testprozesses sowie der Testergebnisse Klare Testrollen und Zuständigkeiten Effiziente und effektive Koordination der internen und externen Ressourcen Testmanagement Herausforderungen Testmethodik Auswahl der richtigen Testfälle für optimale Testabdeckung Vollständigkeit und Interpretationsfreiheit der Anforderungen Redundanzfreie Wiederverwendbarkeit und Wiederholbarkeit von Testfällen Testwerkzeuge Homogene, plattformunabhängige Testtool-Landschaft Übergreifender Fehlerverfolgungsprozess Hoher Automatisierungsgrad mit geringem Wartungs- und Pflegeaufwand Verkürzung der Testzyklen durch frühzeitige Fehlererkennung B msg systems ag, Jackson/Taubner Agenda 1. Strukturiertes Testmanagement 2. Einsatz von Testmanagementwerkzeugen 3. Verbesserte Automatisierung 4. Wirtschaftlichkeit B msg systems ag, Jackson/Taubner

21 Qualitätssicherung im Application-Lifecycle Strategie Plan Define/ Entwickl. Einführung Design / Test Betrieb Kompletter Applikations- Lifecycle Projekte & Programme Portfolio Mgmt. Re-Use Demand Neu- Einführung Fix/ patch Zwischenrelease Fix/ patch Fix/ patch Zwischenrelease Drei Säulen der Qualitäts- Sicherung + Kompletter Qualitätsprozess Beschleunigter Qualitätsprozess + FUNKTIONALITÄT PERFORMANCE SECURITY Funktioniert die Anwendung richtig? Erfüllt Sie die Anforderung des Business? Ist die Performance für alle Nutzer ausreichend? Ist die Skalierbarkeit gewährleistet? Einhaltung der SLAs im Betrieb? Ist die Anwendung gegen alle Arten von Angriffen gesichert? Gibt es Angriffsmöglichkeiten für professionelle Hacker? B msg systems ag, Jackson/Taubner Zielsetzung Effektives und Effizientes Testen Effektives Testen Das Richtige testen Integration mit Business Anforderungen Change Impact Analysen Risikobasiertes Testen Effizientes Testen Mit den richtigen Mitteln testen Ganzheitliche, integrierte Lösung für fachliche Tester und Testspezialisten Unterstützung der Evolution vom manuellen zum automatisierten Testen Testautomatisierung, wo sinnvoll und angebracht B msg systems ag, Jackson/Taubner

22 Zielsetzung - Strukturiertes Testmanagement Priorisieren der Anforderungen ( Requirements ) nach Kritikalität und Fehlerwschk Integrieren, Standardisieren und Automatisieren des Testprozesses Planung Business Requirement Design Implementierung Test Einführung Verifizierung der Requirements Test Test Aufwand/ Kosten Traditionelles Testen Folgen/Auswirkungen Zeit Testfälle Oftmals zu entwickelt, zu spät t im wenn Entwicklungsprozess, Kenntnisse am größ ößten evtl. hoher und Expertise Aufwand vorhanden für f r Fehlerbehebung Zusätzliche Ungenügend gend Prüfung Zeit für f r der gute Fachkonzepte Testabdeckung möglichm vorhanden Frühzeitige Testfälle/Testdaten Top-Down Down-Vorgehensweise spiegeln IST weniger zur SOLL Testvorbereitung wieder Strukturiertes Testen Gute Vorbereitung auf Testaktivitäten, ten, da Testfälle vorhanden, wenn benötigt B msg systems ag, Jackson/Taubner Standardisierung / Zentralisierung Testmanagement Transformation der Qualitätssicherung Stufe 1 Testing auf Projektbasis Durchführung von Tests individueller Projekte ROI Effizientere Überführung der Werkzeuge in den produktiven Betrieb Stufe 2 Virtuelles QS-Team Zentrales Produkt verfügbar als ein Shared Service ROI Hardware und Software Konsolidierung Stufe 3 Zentrale QS-Organisation Zentrales Team hilft bei der Verbesserung von Projektqualität und Performance ROI Bessere Nutzung von Expertise Stufe 4 TestCenter Durchsetzung und Verbesserung von unternehmensweiten Qualitäts- und Performancestandards ROI Auswirkungen auf das Unternehmen B msg systems ag, Jackson/Taubner

23 Agenda 1. Strukturiertes Testmanagement 2. Einsatz von Testmanagementwerkzeugen 3. Verbesserte Automatisierung 4. Wirtschaftlichkeit B msg systems ag, Jackson/Taubner Testmanagement mit HP Quality Center TM HP Quality Center Dashboard Center Management Demand Project Resource Reporting Release Management QuickTest Professional Requirements Management Functional Testing WinRunner Test Plan Service Test TestDirector Test Lab Defect Management Business Process Testing Extensions SAP, SOA Accelerators for SAP, Oracle, Security Foundation Shared Data Repository Central Administration Workflows Open APIs B msg systems ag, Jackson/Taubner

24 HP QC 9.2 Release / Requirement Management Verknüpfen der Anforderungen mit den Releases/Testzyklen B msg systems ag, Jackson/Taubner HP QC 9.2 Release / Requirements Management Testabdeckungsanalyse und Fortschrittskontrolle B msg systems ag, Jackson/Taubner

25 Testmanagement mit HP Quality Center TM HP Quality Center Dashboard Center Management Demand Project Resource Reporting Release Management QuickTest Professional Requirements Management Functional Testing WinRunner Test Plan Service Test TestDirector Test Lab Defect Management Business Process Testing Extensions SAP, SOA Accelerators for SAP, Oracle, Security Foundation Shared Data Repository Central Administration Workflows Open APIs B msg systems ag, Jackson/Taubner HP QC 9.2 Requirements Management Geschäftsanforderung (z.b. SAP SolMan) Fachkonzept/Business Blueprint Prozesse/Spezifikationen Release (Release/Zyklus) Requirements (Testanforderungen) Anforderungen sind zu testen Testfälle verifizieren Anforderungen Test Plan (Testfälle) Test Lab (Testdrehbücher) Defect (Fehlerverfolgung) User Huber Rolle Manual Tester Developer CR ANALYSE OPEN ASSIGN FIXED RETEST CLOSE NEW B msg systems ag, Jackson/Taubner

26 HP QC 9.2 Test Plan / Test Lab (1/4) Requirements Management, Test Plan, Test Lab, Defect Management Festlegung untersch. Anforderungstypen Verbindet Anforderungen mit anderen Anforderungen (Seiteneffekte), Testplanung, Ausführung und Fehlermanagement Steuert den gesamten QM-Prozess mit eingebautem Nachverfolgungsmechanismus mit Historie Statusübersicht Coverage und Cross-Project Reporting Risikoanalyse zur Festlegung von Testschwerpunkten und Aufwandsermittlung Mehr als 30 Integrationen über offene API Einfache Anpassung des Fehlerverfolgungsprozesses Regelbasierte -notifikation für Eskalationen B msg systems ag, Jackson/Taubner HP QC 9.2 Test Plan / Test Lab (2/4) Umsetzung der fachlichen Spezifikation in einzelne Testfälle Einzelne Bearbeitungsschritte des Testfalls B msg systems ag, Jackson/Taubner

27 HP QC 9.2 Test Plan / Test Lab (3/4) Im TestLab werden die Testfälle zu TestSets zusammengefügt und Ergebnisse aus der Durchführung dokumentiert B msg systems ag, Jackson/Taubner HP QC 9.2 Test Plan / Test Lab (4/4) Im Defect-Modul werden die Defects erfasst und verwaltet B msg systems ag, Jackson/Taubner

28 Standardisierung von Werkzeugen Schrittweise Einführung einheitlicher Testwerkzeuge Schritt 1 Proof of Concept Überprüfung Nutzbarkeit, Einsetzbarkeit und Wirtschaftlichkeit Proof of Concept Erkenntnisse zu Einsatzmöglichkeiten, technische Machbarkeit, Kosten/Nutzen, Lizenzbzw. Ressourcenbedarf Schritt 2 Erster Einsatz Exemplarische Anpassung und Nutzung in einem Projekt Referenzprojekt Erkenntnisse zur Abbildung und Nutzung von Prozesses, Einsparungspotential Vorgehensweise bei Standardisierung und weiteren Einführung Schritt 3 Flächendeckender Einsatz Standardisierung von Prozessen und Werkzeugeinsatz Standardisierter Projekteinsatz Vorbereitete Projekt- Templates, standardisiertes Vorgehen und Nutzung, Übergreifende Analyse und Auswertung, Erzielung von Synergieeffekten B msg systems ag, Jackson/Taubner Agenda 1. Strukturiertes Testmanagement 2. Einsatz von Testmanagementwerkzeugen 3. Verbesserte Automatisierung 4. Wirtschaftlichkeit B msg systems ag, Jackson/Taubner

29 Ziele der Testautomation Verbesserung der Testqualität Einsparung von teueren Ressourcen Support des Szenario-, Integrations- und Regressionstests Große Anzahl von Prüfungen je Testfall B msg systems ag, Jackson/Taubner Einsatzmöglichkeiten der Testautomation Test von Grafischen Benutzeroberflächen Datenbankzugriffen Ein-/Ausgaben von Webservices Ein-/Ausgaben von Transaktionsmonitoren (MQ Series) Durchführen einer hoher Anzahl an Testfällen bei vielen Testzyklen Schnelles Erzeugen von Testdaten Rücksetzen von Testumgebungen Herstellen der Ausgangssituation für manuelle Tests Abgleich von migrierten Daten: Altsystem Aktuelle Applikation B msg systems ag, Jackson/Taubner

30 Vorbedingungen zur Testautomatisierung Genaue Testfallschreibung Testfälle müssen korrekt beschrieben sein: Ausreichende Detail-Tiefe, korrekte Werte, genaue Beschreibung der Navigation Stabile Testfälle Die Testfälle müssen qualitätsgesichert und nach einem Review abgenommen sein. Stabile Anwendung Die Anwendung darf sich nicht mehr in der Entwicklungsphase befinden bzw. die Oberflächenelemente und die Navigationsprozesse müssen einen gewissen Reifegrad erreicht haben. Unterstützung aus dem Fachbereich Es muss sowohl in der Automatisierungsphase als auch in der Ausführungsphase sichergestellt sein, dass bestimmte Kontaktpersonen aus dem Fachbereich benannt sind, die die Testautomation bei Bedarf unterstützen. Es muss sowohl in der Entwicklungsphase als auch danach in der Wartungsphase fachliche Verantwortliche für Testfälle geben. B msg systems ag, Jackson/Taubner Überblick: Capture Replay Tool Testdaten (Excel file) - Parameter - Ergebnisse Script (aufgezeichnet) - Navigationsinformationen - Testdaten: Konstanten, Parameter QuickTest B msg systems ag, Jackson/Taubner

31 Capture-Replay Tool: HP QuickTest Professional Baumstruktur Einfache Erstellung von automatischen Testfällen ohne Programmierkenntnisse. Unterstützung verschiedener Umgebungen: SAPGUI / SAP Portal Web Applikationen ( Portale, e-shops) Java Applikationen weitere Technische Merkmale: VBSkript ( Microsoft Standard ) DataTable Active Screen Technologie Wieder verwendbare Skriptkomponenten Verifikationspunkte ( DB, GUI, etc. ) Testdatentabelle Active Screen Einfache Abänderungen Automatischer Testfall kann mit verschiedenen von bestehenden Testdaten abgespielt werden. automatischen Testfällen. B msg systems ag, Jackson/Taubner Klassische Automatisierung B msg systems ag, Jackson/Taubner

32 Klassische Automatisierung Testdaten (Excel file) - Parameter - Ergebnisse Script (aufgezeichnet) - Navigationsinformationen - Testdaten: Konstanten, Parameter QuickTest Testfall Script Technisch gesehen unterscheiden sich Testfälle durch Testdaten und Prozessabläufe (verschiedene Navigationsmuster). B msg systems ag, Jackson/Taubner Klassische Automatisierung Testdaten (Excel file) - Parameter - Ergebnisse Script (aufgezeichnet) - Navigationsinformationen - Testdaten: Konstanten, Parameter QuickTest n Testfälle n Testdatenvarianten, 1 Script Testfall Script Wenn sich Testfälle nur durch ihre Daten unterscheiden (Datenvariationen, Datenvarianten), benutzt man dasselbe Script B msg systems ag, Jackson/Taubner

33 Klassische Automatisierung Testdaten (Excel file) - Parameter - Ergebnisse Script (aufgezeichnet) - Navigationsinformationen - Testdaten: Konstanten, Parameter QuickTest n Testfälle n verschiedene Testabläufe, n Scripts Testfall Script Wenn sich der Testablauf (=Navigationsmuster) von Testfall zu Testfall unterscheidet, muss für jedes Navigationsmuster ein eigenes Script erzeugt werden. B msg systems ag, Jackson/Taubner Wartungsproblem Testdaten (Excel file) - Parameter - Ergebnisse Script (aufgezeichnet) - Navigationsinformationen - Testdaten: Konstanten, Parameter Änderungen QuickTest n Testfälle n verschiedene Testabläufe, n Scripts Problem: Wenn sich Änderungen an Elementen der Oberfläche ergeben, die von vielen Scripten benutzt werden, sind auch viele Scripte zu ändern! Dieser Aufwand ist vermeidbar! B msg systems ag, Jackson/Taubner

34 Lösung: msg.testframework Testdaten (Excel file) - Aktionen - Parameter - Ergebnisse Script (programmiert) - Interpreter für Aktionen - Testdaten: Konstanten, Parameter QuickTest Lösung: 1. Ein Script deckt einen kompletten logischen Teil einer Anwendung mit all seinen Oberflächenelementen und möglichen Prozessabläufen ab 2. Das Script enthält keine fixen Navigationsmuster sondern interpretiert sogenannte Aktionen (die programmiert werden) aus dem Testdatenfile 3. In den Testdaten sind sowohl Daten als auch Aktionen enthalten Ein einziges Script ist in der Lage, eine große Menge an Testfällen abzubilden B msg systems ag, Jackson/Taubner Lösung B msg systems ag, Jackson/Taubner

35 Optimierung der Testautomation Schritt 1: Ad-hoc Testautomation Schritt 2: Klassische Testautomation Schritt 3: Professionelle Testautomation mit Business Process Testing oder dem msg.testframework Test Objekt Test Object Test Object Script Testdaten Script Testdaten Script Testdaten Testdaten Test Script Testdaten Testdaten Parametrisierung der Testskripts Trennung Testskript von Test Daten Test Script Testfall: - Kontroll- & Navigationsinformation -Testdaten (Eingangs-/Ausgangsparameter) - Wertüberprüfungen Trennung fachliche Testfallkettenbeschreibung von technischer Automatisierung Modularisierung der Testfallketten Parametrisierung des Testskripts Auslagerung Kontroll- & Navigationsinformationen Keyword-driven Interpretation der Kontroll- & Navigationsinfo B msg systems ag, Jackson/Taubner Zusammenfassung Klassische Automatisierung msg.testframework Testobjekt Testobjekt Aufgezeichnetes Script mitnavigationsinformation Programmiertes Script ohne Navigationsinformation Testdaten Je Testfall ein Script mit Testdaten Bei einer Oberflächenänderung müssen evtl. alle Scripte angepasst werden. Testdaten und Navigationsinformation Je Testfall Testdaten mit Navigationsanweisungen Bei einer Oberflächenänderung muss nur ein Script angepasst werden. B msg systems ag, Jackson/Taubner

36 Agenda 1. Strukturiertes Testmanagement 2. Einsatz von Testmanagementwerkzeugen 3. Verbesserte Automatisierung 4. Wirtschaftlichkeit B msg systems ag, Jackson/Taubner Vergleich der Testmethoden Projektstart Applikation verfügbar Projektende Manuelles Testing Dokumentieren der Testschritte Durchführung und Analyse der Tests Modifikation der Tests Automatisierung Dokumentieren der Testschritte Aufzeichnung der Tests Durchführung und Analyse der Tests Modifikation Modify tests der Tests Business Process Testing (manuell und automatisiert) Erstellung des Component flow Automat. BPT manuell Automat. Automate Testlauf Modifikation der Tests Durchführung und Analyse der Tests Modifikation der Tests Testfälle, Parameter, etc. werden gebaut bevor die Applikation verfügbar ist Tests werden früher ausgeführt und Defekte früher erkannt Reduzierung der Zeit für die Pflege/Wartung B msg systems ag, Jackson/Taubner

37 Mai ROI Betrachtung der Testmethoden Messung des ROI Aggregierter Aufwand (Stunden) Typischerweise 3 Testzyklen innerhalb eines Upgrades Beschleunigtes Testen ROI innerhalb 2 Testzyklen Manuell # der Testzyklen Traditionelle Automation BPT Automatisierung Traditionelle Automation ROI innerhalb 6 Testzyklen Aufwand (Stunden) (Annahme: 35 Business Prozesse) Quelle: HP B msg systems ag, Jackson/Taubner Kostenvergleich mit/ohne msg.testframework Projektbeispiel aus der Rückversicherung Kostenvergleich ,00 Kosten in Euro , , , , , ,00 Kosten für Aufand Automatisierung mit msg.testframework Klassische Automatisierung ohne msg.testframework 5.000,00 - Monate Januar Januar November September Juli Mai Januar November September Juli Mai Januar November September Juli B msg systems ag, Jackson/Taubner

38 Wirtschaftlichkeit Die Testfälle sind vollständig in MS Excel repräsentiert. Das ermöglicht eine freie Gestaltung der Testfälle im Gegensatz zu den fest vorgegebenen Strukturformaten von Capture Replay Tools Die Bearbeitung und Wartung der Testfälle ist auch vom Fachbereich möglich es ist weniger technisches Know-how erforderlich Vorlagen (in MS Excel) beschleunigen die Testfallerstellung und steigern die Effizienz durch Wiederverwendbarkeit Es entsteht ein Testfallbaukasten, der flexibel auf die Bedürfnisse des Fachbereichs angepasst werden kann Geringer Wartungsaufwand durch Vermeidung von Redundanzen B msg systems ag, Jackson/Taubner Vielen Dank für Ihre Aufmerksamkeit! B msg systems ag, Jackson/Taubner

39 7 Wolfgang Mansel»Einflussfaktoren auf die Produktivität bei der Softwareentwicklung für Flugzeug Bordrechner«Einflussfaktoren auf die Produktivität bei der Softwareentwicklung für Flugzeug Bordrechner Dr. Wolfgang Mansel TUM Workshop Produktivität in der Softwareentwicklung EADS 2008 All rights reserved Inhalt Definitionsbereich Softwar Produktivität Software Metriken Einflussfaktoren auf die Software Produktivität Fehlerreduzierung durch ausführbare Spezifikationen Codegenerierung Software Test Software Zulassung EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 2 39

40 Software Produktivität Flugzeug Bordrechner Zeit Kosten Abwicklung von Software Entwicklungsprojekten Qualität Randbedingungen komplexes technisches Umfeld Kostendruck Zeitdruck verteilte Echtzeitsysteme verteilte Entwicklung EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 3 Definitionsbereich SW Produktivität Prozessmodell Sicht SRR SDR SSR PDR CDR TRR FCA/PCA FRR FQR Operational Baseline Functional Baseline Allocated Baseline Equipment Development (Sub)System Product Baseline Product Baseline Equipm. Req's Analysis Equipm. Testing (Stage A) Operational Concepts System Concepts System Req's Analysis Subsys. Req's Analysis Rig Req's Analysis Rig Development System Integration Testing (Stage B/C) Flight Testing (Stage D) Operational Service Customer Software Req's Analysis Software Testing (Stage A) Customer Software Development System Definition System Development System Integration EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 4 40

41 Definitionsbereich SW Produktivität Planungssicht 1. Year 2. Year 3. Year 4. Year 1992 PL79 Feeze Operational Reqt s SDR System Reqt s Analysis Software Reqt s Analysis Software Development Software Testing (St. A) System Software Test (St.B) System Integration Test (St.C) Flight Test (St. D) Query Freeze PANAVIA SRR SSR Q Q Q Die Software Entwicklung erstreckt sich über ca. 70% der gesamten Entwicklungszeit eines System Upgrades. EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 5 SW Produktivität Verteilung der Aufwände System Requirement s Analysis FB Software Requirement s Analysis AB SSR Preliminary Design PDR Detailed Design CDR Coding and Unit Testing Software Integration and Testing TRR HW/SW Integration and Testing FCA (PCA) System Integration and Testing PB PCA 30 % 30 % 40 % EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 6 41

42 Software Metriken Zielsetzung Bestimmung der Software Qualität aus Source Code Metriken (ISO 9126) Quantifizierung des Entwicklungsprozesses mit Aufwandsmetriken Erfassung der Prozessdynamik mit Auswertung von Trends während der Entwicklung Identifikation von Prozessverbesserungen Metriken Prozessor Auslastung Speicherbelegung Milbus Auslastung SW-Metriken Lines of Code Statistik (Grösse, Änderungen) Komplexität von SW Komponenten Makro Metriken gemäss ISO 9126 Qualitätsmodell Fehler Statistik Requirementsänderungen Aufwandsdaten EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 7 Software Metriken Measured Parameters Source Code Metrics Size Factors Complexity Code Changes Between Versions Work Effort Data Derived Information Maintainability Testability Development effort Productivity Memory Consumption Time Load Development Risks Requirement Changes Error Data Stability of Requirements Rework EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 8 42

43 Einflussfaktor Komplexität verteilter Echtzeitsysteme Flugregelung Flugstabilität Rear HEA HEA FCCs FCCs FCS-Bus DECU Rear RGS RGS EMU IPU Flugzeuglage Rear LGS MLS/ DME-P LINS GPS SCAC NSCAC CSMU MDP PMDS LGS ESM C/F- ECM Dispens. DASS-Bus Missile LW Warner (nat. fit) Navigationsberechnung Rear DWP RadAlt Rear HEAPU HEAPU MDLR PDS Attack-Bus Struct. Sensors R L Fuel Comp. M HDDs DWP Avionic-Bus BSD Rear M HDDs NC Weapons Bus Rear CIUs DU HUD+ Camera DMG Flugzeug UCS-Bus Position HUD Repeater CIUs FLIR (nat. fit) Anzeige- und Bedienfunktion AC LC Cockpit-Bus CAMU DAC CSGs Rear LC MIDS Radar Radar-Bus VVR V/UHF Radios IFF- XPDR IFF- Interrog. CWI EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 9 Einflussfaktor verteilte Entwicklung MIDS LVT COMMS CRYPO BUS UTC Clock DWP DWP Rear MHDDs MHDDs HUD LC REAR Repeater REAR COCKPIT BUS LC LGS REAR LGS MIU CAMU V/UHFs ACVMS DME-P MLS RAD ALT SP3 TACAN IFF TRANS A & I HUD +Camera CIU REAR CIU RGS REAR RGS MDLR +PDS AVIONIC BUS (3910) NAV GPS LINS NC AC FLIR GPWS DMG HEAPU D & C ATTACK ATTACK BUS BUS (3910) SSICAs FCC 1 FCC 2 IMUs ESCAC NSCAC MAW DAC ESM ECM HEAPU REAR FCS FCS BUS WEAPON BUS DEFENSIVE AIDS BUS RADAR STORES FLARE SUs (13) CHAFF DU LW DISP DISP (9) ACS DASS RADAR BUS IFF INT CSG ADTs FCC 3 FCC 4 APU/CU DECUs P R O PU L GCUs EMU SPS ELECTRICAL POWER IPU BSD CSMU GENERAL SYSTEMS IMRS MDP +PMDS LEFT SPS COMP UCS UCS BUS RIGHT SPS COMP SPS - HYD LFE - ECS - FIIS PRP(T2) - FP LEFT FUEL COMP RIGHT FUEL COMP FUEL SYSTEM VVR Workshare Verteilung nach Subsystemen: LG FRONT COMP COMP Mehraufwendungen durch Abhängigkeiten von Partnern und Zulieferern LANDING ECS LIFE GEAR SUPPORT CREW ESCAPE EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 10 43

44 Einflussfaktor Fehlerquellen im Entwicklungsprozess Human Documentation Environment Data Interface Other 5% 5% 6% 6% 7% 2% Logic Design Requirements Errors 27% 42% mögliche Massnahmen zur Steigerung der SW Produktivität ausführbare Spezifikationen Codegenerierung aus Design Spezifikationen Reuse Testautomatisierung EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 11 Einflussfaktor spätes Erkennen von Spezifikationsfehlern Concept System Requirem. Analysis & Definition Development Software Software Design Requirem. Design Implementation Analysis & Definition Operation & System Mainten. Test and Test and Integration Integration Flight Test Problem: hspäte Fehlerdetektion hspäte Korrektur hzusatzaufwand wirkt sich auf Zeit und Kosten aus Update & Re-Test Zahlreiche Iterationen Aufwand (symbolisch) Korrektur Fehlerdetektion Fehleranalyse EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 12 44

45 Produktivitätssteigerung durch ausführbare Spezifikationen Kürzere Entwicklungszyklen durch weniger Reparaturzyklen bei gleichzeitig hoher Produktqualität Leistung Soll Ist SRS Design/Coding Test Zeit Ein Teil des Gesamtaufwandes wird von hinten nach vorne verlagert; insgesamt sinkt der Aufwand EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 13 Codegenerierung aus Design Spezifikationen Bisher nur Teilerfolge, z.b. Code für Symbolgeneratoren aus VAPS oder für Algorithmen aus MatLab. Kein realer Produktivitätsgewinn da kaum Codegeneratoren für Ada Codegeneratoren teilweise fehlerhaft Code schwer lesbar Nachweisführung keine durchgängigen Codegeneratoren verfügbar für eine Software Mischung aus Logik, Algorithmen, Behandlung von Datenstrukturen, zeitkritischen Datenzugriffen. Teilgenerierung von Code erhöht den Wartungsaufwand Einsatz leistungsfähiger höherer Programmiersprachen wie z.b. Ada und mehr Abstraktion bei der Software Design Repräsentation ist effizienter, besonders im Verbund mit Tools zur Unterstützung des Software Tests. EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 14 45

46 Effizienzgewinn durch abgestuftes Testkonzept Test Stage Test Method Test Facility Development Testing Single Module Tests Module Integration Tests Host Computer Facility, Debugger, Host Test Tools Development Testing Single Task Tests Microprocessor Development System, Pre-Target System Stage A (Equipment Level) Stage B (Computing Network Level) Stage C (Avionik System Level) Incremental Software Integration Multi Avionic computer Integration Avionic System Rig Integration Software Test Bench with AIDASS/MaTE Avionic Subsystem Test Bench with AIDASS/MaTE Avionic System Rig with AIDASS/MaTE Stage D Aircraft Integration Instrumented Test Aircraft EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 15 Software Test - Test Iterationen approx. 7 to 14 days Query System Demo to Query Design/System Eng. APR- Analyse * approx. 0.5 to 1 day ( daily load ) SW Query Board approx. 4 to 10 weeks Query Software- Stage A - Query Stage B/C Stage APR Developm. Eng.-Test Stage Eng.-Test A B // C approx. 3 to 5 months SW Engineering internal Flight Test Plan Flight Test Analyse Stage A QA-Test Abbreviations: Eng.: Engineering QA: Quality Assurance VDD: Version Description Document Develop.: Development APR: Avionics Problem Report OFP: Operational Flight Program LRU: Line Replaceable Unit * on OFP/LRU-Level on the RIG Stage B/C QA-Test Equipment- Developm. QA- Load (VDD) Test- Notes System Spec. Develop. Flight Release Flight test EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 16 46

47 Testing Concept Test automation with Software Test Tools or AIDASS/MaTE Rigorous unit testing of Library Functions & Generics Unit Testing of functions which can not be easily tested in integration/rig tests Hardware-near functions tested largely on target (AIDASS/MaTE Test Sequences / Event Processing driving User-Simulation) Hardware-distant subsystems tested largely initially on host Conversion of host tests for use on target to minimise test effort EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 17 Einflussfaktor Software Zulassung Prozess und Dokumente der Nachweisführung Prozess Dokumentation der Anforderungen Spezifikationsreview Design / Engineering mit PDR und CDR Test Readiness Review (TRR) Nachweisführung / Qualifikation (einschl. FCA/PCA bei Avionik) Zusammenstellung der Dokumentation Erstellung SW-DDPs / VDD, SRN für Musterprüfung Serienfreigabe (FAI) Dokumente Qualification Programme Plan (QPP) Qualification Test Procedure (QTP) Qualification Test Report (QTR) Analyse Reports Declaration of Design and Performance (DDP) / PSQS; SQS EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 18 47

48 Software Dokumentation Software Document Software Development Plan Requirements Specifications System / Subsytem FRDs LRI Processing Specification Software Top Level Design Document Software Detailed Design Document Software Design Hazard Analysis Software Test Plan Software Test Descriptions Unit Test Description Integration Test Description Acceptance Test Description (formal tests) Acceptance Test Procedure Code Walkthrough Report Review Reports Software Test Reports Unit Test Report Integration Test Report Formal Test Report Software Version Description Document Software Release Note Document Code SDP FRD LPS STLDD SDD HSD STP UTD ITD SAT SAP CWR SSR / CDR / TRR UTR SIT SAR VDD SRN EADS 2008 All rights reserved Datum/Date Arial - 8pt Titel/Title Arial - 8pt 19 48

49 8 Markus Pizka»Produktivität pragmatisch messen und wirksam steigern«produktivität pragmatisch messen und steigern Markus Pizka, itestra GmbH Workshop HSE 08 - Produktivität in der Softwareentwicklung Technische Universität München, Überblick itestra Vorstellung Produktivitätsziel Produktivität messen Definitionen, Metriken, Fragestellungen Produktivität steigern Change-Management Erfahrungen M. Pizka 2 49

50 Wer wir sind itestra 15 Jahre Forschung Systemarchitektur und Software Engineering Informationstechnologie und -strategie GmbH seit % - 40% Wachstum p.a. Standorte Garching b. München Tallinn, Estland Services Engineering: Geschäftskritische Systeme, Renovierung Consulting: Process Improvement, Software Management Produktivität in Entwicklungsprojekten: Wettbewerbsvorteil in Beratungsprojekten: Maß der erreichten Prozessverbesserung M. Pizka 3 Motivation itestra 1. Effizienz wird erfolgskritisch! Planbarkeit genügt im Wettbewerb nicht mehr. Waterfall (Royce) Cleanroom Spiral Model V-Modell RUP Agile Manifesto Open Source, E-Biz Zeit 2. Enormes Potential Hohe Software-Budgets Unreife Branche (u. a. Fachkräftemangel) Kaum physische Grenzen 50% (intuitiv, Literatur, ) 3. Wettbewerbsvorteile für Kunden sichern Auftraggeber: Kostensenkung Auftragnehmer: Ertrag, Preisvorteil Volumen (Effektivität) Auf-/ Absteiger Marktführer Bedroht Rendite (Effizienz) M. Pizka 4 Nische 50

51 Was ist Produktivität? itestra Ausschließlich grobgranulare Betrachtung Total Cost + Projektergebnis Basis: Effizienz = Output / Input Produktivität = Output / PT Output: Wert ~ Umsatz ~ Function Points Ökonomisch: Umsatzrendite: G / Umsatz ~ 1 (Preis O / PT) Gewinn (DB): Umsatz Kosten (inkl. GWK) Preis O PT Technisch Größe: RFSLOC/PT bzw. RFSLOC/PT Geschwindigkeit Qualität: Defects / SLOC Korrektheit SLOC/FP Angemessenheit M. Pizka 5 itestra Fehler/kSLOC M G O Q E L R U N S A T P Beobachtungen RFSLoC/PT Vergleichbare Projekte Enorme Varianz (RFSLOC, Fehler) Präzise Messung nachrangig Verantwortlichen i.d.r. unbekannt Korrelation mit Team A B C D G H I J K L M N O P Q COCOMO e R S COCOMO m T COCOMO s U Fehlerkosten in der Entwicklung Bugfix ~ 50% Gesamtkosten Lieferant & Auftraggeber Weitere Faktoren M. Pizka 6 51

52 Grundlegende Stellglieder itestra Zielsetzung Fähigkeiten Möglichkeiten Individuum Motivation Qualifikation Werkzeuge Engagement Kreativität Fach/Technik/Org./Sozial IDE, KM, Reuse, Generator, Hardware Organisation Vision Prozesse Infrastruktur Ausrichtung CMMi, V-XT, RUP, XP, HR, Requirements, QA (Test, Inspekt) Ruhe, Strom, Netz, Erreichbarkeit M. Pizka 7 Produktivität steigern itestra leicht 1. Was ist für hohe Produktivität notwendig? Bestmögliche Organisation und Individuen Stand der Technik Software Engineering und Management z.b. OO, Use Cases, Komponenten, Inspektionen, Test, Prozessreife, Problem: Nutzen der Methoden unklar das Beste ist diskutabel schwer 2. Wie wird dieser Zustand erreicht? Konsequente Einführung (kein Mangel an Wissen sondern an Umsetzung) Problem: jede/r macht bereits das Beste, was ihm/r bekannt ist Eingriffe in Arbeitsweisen Gewohnheiten Persönlichkeit M. Pizka 8 52

53 Change Management itestra Anforderungen: Bestmögliche Methoden identifizieren, d.h. Alternativen betrachten Dauerhafte (risikoarme) Umsetzung sicherstellen M. Pizka 9 Lean Elemente itestra Wert Wertschöpfung für den Kunden Wertstrom Maximierter Wertbeitrag der Aktivitäten Flow Kontinuierlicher Fluss kleiner Einheiten Pull Bedarfsgetriebene Produktion (JIT) Kaizen Kontinuierliche Verbesserung in Schritten Intelligenz (Jidoka), Abfall (Muda), Vor Ort (Gemba), Zahlen/Fakten (Genjitsu), 5W, Radikal handeln (Kaikaku), 5S, Fehlerverhinderung (Poka Yoke), Asynchrone Signale (Kanban),... Werkzeuge Prinzipien (Ziele) M. Pizka 10 53

54 Abbildung auf Software Entwicklung itestra Prinzipien: Eliminate Waste, Learning, Decide Late, Deliver Fast, Empower, Build Integrity Werkzeuge: Seeing Waste, Value Stream Mapping, Iterations, Refactoring, Test-First Fazit: Adaption als Prozessskizze Ziel: Vorgehen: Fazit: education to transfer Lean philosophy and practices thorough performance assessment custom action plan to address bottlenecks Individuelle Ausgestaltung Lean ist kein Prozess sondern eine CM-Denkweise! Kontrollierter Transfer kann risikoarm + dauerhaft Effizienz steigern. M. Pizka 11 Waste Wert versus Abfall itestra Wert = vom Kunden gewünscht und bezahlt Waste = wertlose Aktivität / Zwischenergebnis Motion Inventory Waiting Trans portation TIM WOODS is no friend of waste Over production Skills Defects Over processing M. Pizka 12 54

55 Waste Wert versus Abfall itestra Wert = vom Kunden gewünscht und bezahlt Waste = wertlose Aktivität / Zwischenergebnis #1 Waste, Fkt & Qualität, Rework ~ verlorene Arbeit, Zusatzarbeit Früh erkennen: Test, Inspect, Requirements; vermeiden: 5S Über-/unterforderung, ungeeignete Werkzeuge (Soft/Hard) Suboptimale Methoden (ineffiziente Wertschöpfung) Meetings, Fehlende Zulieferungen Langsame Infrastruktur (Netz, Software, Hardware) An-/Abreise, Kontext-Switch (1,5h 3h), Provisorien Papier / Abtippen, Projektlaufwerk statt KM Duplikation, unbenötigte Funktionalität, Flexibilität, Dokumente Financial Controlling? Test? M. Pizka 13 Ökonomisch quantifizieren itestra Waste Calculator Globale Parameter Durchschnittl. Verweildauer im Team [Monate] 8 Dauer Einlernphase [Monate] 1 Projektlaufzeit [Monate] 12 Anzahl Mitarbeiter 20 Wert eines Mitarbeiterjahres Ergebnisse Berechnungsmodus multiplikativ Anteil Waste insgesamt Waste insgesamt 31% Entspricht Produktivitätssteigerung 44% Entspricht Gewinnsteigerung Anteil reduzierbarer Waste Reduzierbarer Waste 25% Finanzielle Investition für Reduzierung Entspricht Produktivitätssteigerung 33% Entspricht Gewinnsteigerung Anteil der Phasen am Gesamtprojekt Alle 100% Design 30% Implementierung 40% Test 20% Phase Thema Kategorie Berücks. ja/nein Waste in Phase Waste gesamt Empirische Kalibrierung Waste gesamt reduzierba Alle Anreise Transport Nein 9,4% 9,4% 4,7% Anteil des Teams, der pendelt Alle Reorientierung nach Defects Ja 10,1% 10,1% 5,0% Anteil der Arbeit in Störungen durch Großraumbüro Alle Reorientierung aufgrund zu Motion Ja 3,3% 3,3% 3,0% Anzahl kleiner Bildschirme Scrolling/Taskw ec hsel pro Stunde Alle Wartezeit für Administration Waiting Ja 1,8% 1,8% 0,9% Durchschn. und Berechtigungen Verw eildauer im Alle Suche nach zuständigem Waiting Nein 2,1% 2,1% 1,0% Durchschn. Ansprechpartner für Verw eildauer im Anzahl Alle Arbeitsplatz-Umzug und - Motion Nein 0,8% 0,8% 0,8% Wiedereinrichtung bei Desk- Arbeitsplatzw echs Sharing el pro Woche Alle Warten auf Ressourcen Waiting Nein 0,5% 0,5% -0,1% Anzahl Ausfälle w ichtiger Alle Neustartzeiten und Waiting Nein 0,5% 0,5% 0,4% Anzahl Abstürze Datenverlust durch instabile pro Woche Design Spezifikation als Over-processing Ja 55,0% 16,5% 16,5% Anteil an IT- Implementierungsanleitung Konzept, der als langfristige Dokumentation Implementierung Warten auf IDE (Hardw are- Waiting Nein 2,7% 1,1% 0,5% Anzahl Build- Performance) Vorgänge pro Tag Alle Rückkopplung mit Waiting Nein 4,7% 4,7% 2,3% Durchschn. Zeit, Vorgesetztem die selbständig am Stück gearbeitet Implementierung Wiederholte Beantw ortung Waiting Ja 2,1% 0,8% 0,4% Durchschn. von FAQ für Neulinge Verw eildauer im Implementierung Warten auf Redeploy und Waiting Ja 5,0% 2,0% 1,0% Anzahl Neustart nach Änderung Änderungen mit anschließendem Aufwand Parameter für Reduzierung des Waste oder in EUR in Zeit [MA-Produktivität Reduz ierbar 50% Fahrten pro Woche 6 50% (einfach) 80% in pro Monat Anzahl Personen pro MA % Büro 10 einmalig Reorientierungszeit pro MA % pro Scrolling/Taskw echs Wartezeit bis voll % einsatzfähig [Tage] Dauer Einlernphase % [Monate] 2 Einrichtungszeit [min] % 1 30 pro Monat Durchschn. projektw Ausfall- eit 10,0% 80% und Wiederanlaufzeit Durchschn. Ausfall % und Wiederanlaufzeit Anteil an IT-Konzept, 15% 30% 100% der für grundlegende Implementierungsents cheidungen dient 8 Dauer Build [s] 60 50% 16 Zeitaufw and pro Abstimmung [min] 50% ,0% 10 einmalig Dauer Einlernphase projektw eit 70% [Monate] Anteil der 4 50% 50% Änderungen, die ein Redeploy / Neustart 15 M. Pizka 14 55