Erfolgsfaktoren für kooperatives SW Qualitätsmanagement. Ruth Breu Ruth Breu Kompetenzzentrum QE LaB Universität Innsbruck

Transkript

1 Erfolgsfaktoren für kooperatives SW Qualitätsmanagement OOP 2013 Ruth Breu Ruth Breu Kompetenzzentrum QE LaB Universität Innsbruck

2 Slide 2

3 lab.at/ QualityEngineering Laura Bassi Lab Living Models for Collaborative Systems Industry Partners Slide 3

4 Übersicht 1. Herausforderungen 2. Zehn Prinzipien ipien mit Beispielen aus der Praxis Slide 4

5 1. Herausforderungen an kooperatives QM

6 Beispiel 1 Elektronische Gesundheitsakte Gesundheitsnetzwerk Tirol Slide 6

7 Slide 7

8 Beispiel 2 Cloud Service Provider Slide 8

9 Herausforderungen Slide 9

10 Integrierter Produktionsprozess Slide 10

11 Vision Lebendige Modelle Ruth Breu et al.: Living Models Ten Principles for Change Driven Software Engineering. Int. Journal on Software and Informatics, 5 (1 2), Slide 11

12 2. Zehn Prinzipien lebendiger Modelle

13 P1 Stakeholder zentrierte Arbeitsumgebungen IT Manager Tester Security Engineer Enterprise Model Test Model Configuration Model 1. Quartal 2. Quartal 3. Quartal 4. Quartal context processedas : ProcessedAS: self.confidentiality ={ (self.annualincome), (self.clientid) } self.integrity ={ (self) } self.nonrepudiation ={ (self) } Document Analyze Decide Define tests Execute tests Report Configure system Monitor runtime behaviour Document Von Modellierungswerkzeugen zu modellbasierten Arbeitsumgebungen Slide 13

14 Beispiel: EAM IT zentrierte Sicht Textuelles Modellierungstool für IT Architekten Sehr schnelles Modellieren Sehr gute Wartbarkeit der Modellqualität In Eclipse integriert Unternehmensspezifisches Metamodell Generiert Ansichten Web basiertes View Framework Für verschiedene Stakeholder verwendbar Konfigurierbare Sichten Slide 14

15 P2 Enge Kopplung von Modell und Code/Runtime TaxAdvisor «receive» receiveas Entry/sendAnnualStatement(annualStatement) Municipality Client internalweb Service1 «invoke» ForwardAS Entry/notification:=sendProcessedAS (processedas) processedas notification «receive» receiveprocessedas Entry/sendProcessedAS(processedAS) internalweb Service1 «reply» sendnotification Modell Entry/sendProcessedAS := notification «reply» sendconfirmation Entry/sendAnnualStatement := confirmation Tool unterstützte tüt t Synchronisation z.b. Code Generierung, Modellgenerierung Code/Laufzeitumgebung Ziel: Modell repräsentiert das laufende System/den Code zu definierten Zeitpunkten Slide 15

16 Beispiel: Enterprise Architecture Models IT Manager System Administrator Software Engineer Business Process Engineer Slide 16

17 Pflege von EA Modellen Do you agree with the following sentence: The manual collection and maintenance of EA data in a sufficient quality, is one of the major challenges of EA practice.? QE/iteratec survey2011 Herausforderungen Synchronisation zwischen IT Landschaft und EA Modellen Überbrückung der semantischen Lücke Integration von Daten aus verschiedenen Domänen Slide 17

18 Living IT Landscape Models Change Management Tool,... Change Events Project Portfolio Management Tool Change Events Network Scanner, ESB,... Structured Data Data Expiry Events Tool supported Integration Process Driven by a process engine Fallback to manual input Support of Identity Reconciliation EAM Repository Kooperationsprojekt mit Slide 18

19 P3 Bidirektionaler Informationsfluss zwischen Modellen und Code/Laufzeit TaxAdvisor «receive» receiveas Entry/sendAnnualStatement(annualStatement) Municipality Client internalweb Service1 «invoke» ForwardAS Entry/notification:=sendProcessedAS (processedas) processedas notification «receive» receiveprocessedas Entry/sendProcessedAS(processedAS) internalweb Service1 «reply» sendnotification Modell Entry/sendProcessedAS := notification «reply» sendconfirmation Entry/sendAnnualStatement := confirmation KPIs, Events z.b. Anzahl laufender Instanzen, Performanz, Verfügbarkeit, Code Metriken Code/Laufzeitumgebung Slide 19

20 P4 Gemeinsame Systemsicht Gemeinsames Metamodell aller Stakeholder Funktionale Konzepte: BusinessProcess Process, Information Object, Service, etc. Nichtfunktionale Konzepte: Security Risk, Performance Requirement, Test Case, Bug, etc. Beziehungen als Basis für Nachverfolgbarkeit und Kommunikation Metamodell als Datenmodell Slide 20

21 QE LaB Referenz Metamodell Slide 21

22 Security Plug In Slide 22

23 P5 Persistenz und Evolution Systemmodelle als Instanzen des Metamodells Ein Systemmodell beschreibt den aktuellen Status des Systems auf allen Abstraktionsebenen Systemevolution = Sequenz von Systemmodellen (Systemmodellversionen) Slide 23

24 Traceability Pflege von Links Requirement Component Wer? Wo? Warum? Wann? Toolunterstützt? Slide 24

25 P6 Analyse Überprüfung der Systemmodelle auf Konsistenz Generierung von Sichten und aggregierter Information Steuerung von Prozessen Entdecken von Anomalien consistency, coverage Quelle: iteraplan Quelle: Quelle: Jürgen Döllner et al. Michele Lanza, /IV Richard Wettel, Slide 25

26 «FunctionalRequirement» Req_1.1 {Text = "The AR establishes a connection to the HG"} «FunctionalRequirement» Req_1 {Text = "The agent-less network has to be controlled"} «FunctionalRequirement» Req_1.2 {Text = "An identification has to be assigned to a connection"} «FunctionalRequirement» Req_1.3 {Text = "The assigned policy has to be applied to the network connection"} «SecurityRequirement» SReq_1.4 {Text = "The PDP has to be available" } Beispiel: Steuerung des Testprozesses durch Risikobewertung M M M I Impact Requirement defined assigned undertest «Servicecall» findpatientbyid {output = "patient" } «Assertion» {fail = "!pass", pass = "patient!= null" } Test R M PolicyEnforcement +enforcepolicy( policy : PolicyAction [*] ) PolicyDecision +decidepolicy( identificationdata : IdentificationData ) +addpolicy( policy : Policy ) new notexecutable executable evolution stagnation regression Risk M M P Probability Service new specified executable Cooperation Project with Slide 26

27 P7 Verantwortlichkeitsbereiche Slide 27

28 P8 Zustände Jedes Modellelement im System Modell kann einen Zustand besitzen Ein beigefügtes Dokument (z.b. ein SLA) Eine Kennzahl Durchschnittliche Anzahl laufender Instanzen für einen Geschäftsprozess Testüberdeckung einer Komponente Qualitätszustände Security Requirement: definiert, bewertet, erfüllt Slide 28

29 P9 Änderungsgetriebener Prozess Änderungen werden durch Events getriggert Neue gesetzliche Anforderung, neuer Geschäftsprozess, etc. Zeit Events Action Events manuelle Tätigkeiten der Stakeholder Prozess wird durch Change Events und Zustandsänderungen getrieben Change Events verursachen Zustandsänderungen (Change Propagation) Stakeholder überführen Zustände durch qualitätsrelevante Tasks in Zielzustände (Change Handling) Slide 29

30 Beispiel: State Machine State Machine von Security Requirement Action Event Bedingung an das Systemmodell Zielzustand Slide 30

31 Integration von Prozessen Requirement Component State Machine Zustandsänderung Event Task Benachrichtigung Slide 31

32 Beispiel: Security Requirements Management IT Security Manager Compliance Manager System/Platform Administrator Security Requirements im Kontext der IT Landschaft Kooperative Erstellung Hosting Provider Kooperative Bewertung Change Handling Slide 32

33 MoVE Model Evolution Engine e.at/ <<Servicecall>> Login {caller = UserCaller, input = VName, VPassword, output = VCustomer, service = } Login <<Assertion>> Assertion {pass = "VCustomer = Result" } System Architect Tool 1 Requirements Engineer Tool 2 Testing Expert Tool n Work Environments Adapter 1 Adapter 2 Adapter n MoVE Plug ins Design Model Requirements Model potential conflict Test Model Consistency Checks State Change Propagation MoVE Repository Common Meta Model + State Machines MoVE Environment Slide 33

34 P10 Automation Generierung von Sichten Traceability Unterstützung Datenanalyse Modelltransformation Automatisiert durchgeführte Tasks Change Propagation pg Task Management Slide 34

35 Zusammenfassung Collaborative Quality Management Knowledge Management Data Analysis Automation Change Driven Engineering Slide 35