D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

To conduct the user study we have designed a research method that consists of three main steps: User Study Design, User Study Execution, and Analysis of Results. Table 1. Research Questions and Success Criteria RQ1 RQ2 Research Questions(RQ) and Success Criteria(SC) How is evolution managed in a fully realistic and complex setting such as ATM domain? SC1 The phases of the change management process adopted by Air Navigation Service Providers are identified. For each phase of the process the participants and the artifacts used to support the phase are identified. Can the approach to model and reason on requirements evolution be applied to the change management process adopted by Air Navigation Service Providers? SC2 The approach to model and reason on requirements evolution can support and facilitate the change management process by by Air Navigation Service Providers; SC3 The approach to model and reason on requirements evolution is sufficiently expressive to capture the evolution in the ATM domain; SC4 The approach to model and reason on requirements evolution can be easily understood by ATM domain experts 4.1 User Study Design The first step of the research study was to identify the research questions to be addressed and the success criteria to evaluate the results obtained from the user study(see Table 1). The main objective of the user study is to understand the process to handle change adopted by Air Service Navigation Providers and to investigate the applicability of the approach to model and reason on evolution to the different phases of the process. Once identified the research questions, the ATM domain experts were selected. Eight domain experts were involved in the user study: P5 has worked in several projects related to the ATM domain and has a good knowledge of requirements engineering domain, P6 has been an air traffic controller for several years, P7 and P8 has worked in operational projects regarding the development and the management of ATM systems, P11 and P12 are air traffic controllers and P12 and P13 are Human Factors and Safety experts in the ATM domain. Since ATM domain experts were not very familiar with requirements engineering and do not have knowledge about the approach to model and reason on requirements evolution, it was necessary to prepare training material in form of presentations. The training material includes presentations about – main concepts and analysis techniques relevant for change management in requirements engineering domain – the approach to model and reason on requirements evolution (see Section 3). The introduction of the AMAN was used as illustrative example through all the training materials since the ATM domain experts were familiar with this scenario. Also an interview guide containing a list of questions to lead the discussions during the interviews was prepared. 6
Table 2. Participants Background Participants Role Position Education Years of Professional Experience P 1 RA,OBS PostDoc PhD 2 P 2 RA,OBS PostDoc PhD 4 P 3 RA,OBS PhD MSc 1 P 4 RA,OBS Full Professor PhD > 10 P 5 DE Consultant MSc 20 P 6 DE Consultant PhD > 5 P 7 DE ICT Manager MSc > 10 P 8 DE SyS Admin MSc > 10 P 9 DE ATCO MSc > 10 P 10 DE ATCO MSc > 10 P 11 DE Human Factors & PhD > 10 Safety Expert P 12 DE Human Factors & PhD > 10 Safety Expert The table gives an overview of the role and the background of each of the participants of the experiment. In the table OBS = OBServer, RA = Requirement Analyst, DE = Domain Expert, ATCO = Air Traffic COntroller, SyS Admin = System Administrator. The feedback collection from the ATM experts was carried out through semi-structured interviews and focus groups and by recording the meetings for later analysis. 4.2 User Study Execution Table 3 outlines the organization of our study. The first column denotes the meeting type, which can be preliminary meeting (PM), internal working session (IWS) or workshop (WS). The second column specifies when the meeting took place. The third column lists the participants of the meetings. Finally, the last column indicates what happened during the meeting. The study was organized into two separated workshops: one held in April (WS1), and the other one in June 2011 (WS2). Before conducting these two workshops, one preliminary meeting (PM1) was held among requirement analysts and observers to identify the research questions of the study, the success criteria, and the strategy to be followed during the study. In between the meetings, there were internal working sessions (IWS1 and IWS2) where requirement analysts prepared relevant materials for the study, including case study description and models, presentations, and other training materials such as the interview guide. These documents were distributed to the domain experts before the workshops in order to being able to collect feedbacks from them. The two workshops were divided into two sessions: Designing session and Validation session. The former lasted the first day of WS1: requirement analysts discussed with domain experts P5, P6, P11 and P12 about prepared training material (e.g., case study, presentation slides) to get their feedbacks. Then the training material were modified based on domain experts’s feedbacks. The Validation session was held during the 7
Page 1 and 2:
D.3.3 ALGORITHMS FOR INCREMENTAL RE
Page 3 and 4:
1.14 19 January Final 1.15 23 Janua
Page 5 and 6:
Index DOCUMENT INFORMATION 1 DOCUME
Page 7 and 8:
1 Introduction This deliverable pre
Page 9 and 10:
(Clause 6.4.3) processes of ISO/IEC
Page 11 and 12:
3 Orchestrating Requirements and Ri
Page 13 and 14:
grey. The ADS-B introduction requir
Page 15 and 16:
The security risk manager identifie
Page 17 and 18:
are supported by the argumentation
Page 19 and 20:
ADS-B Manage ADS-B signal ADS-B sig
Page 21 and 22:
the stagnation suite (i.e. obsolete
Page 23 and 24:
5 A framework for modeling and reas
Page 25 and 26:
sectors. And there is 42% of probab
Page 27 and 28:
SDA(C) = {DA 2 , DA 4 , DA 8 , DA 1
Page 29 and 30:
application contexts is saved if th
Page 31 and 32:
Figure 14. ATM model state after qu
Page 33 and 34:
References [1] Yudis Asnar, Fabio M
Page 35 and 36:
Managing Changes with Legacy Securi
Page 37 and 38:
Failure in the provisioning of corr
Page 39 and 40:
propagated to the system designer a
Page 41 and 42:
APPENDIX B D.3.3 Algorithms for Inc
Page 43 and 44:
is sometimes difficult, especially
Page 45 and 46:
Tactical Monitor air R controller t
Page 47 and 48:
protected from harm. Since in CORAS
Page 49 and 50:
CModel. The postcondtion checks the
Page 51 and 52:
of ADS-B signal and Availability of
Page 53 and 54:
extensions to i* to model and analy
Page 55 and 56:
3. Bzivin, J., Dup, G., Jouault, F.
Page 57 and 58:
APPENDIX C D.3.3 Algorithms for Inc
Page 59 and 60:
steps. Section V demonstrates the R
Page 61 and 62:
that should be mitigated by the sys
Page 63 and 64:
CPU value PINconfirmed(PIN, card-de
Page 65 and 66:
TABLE IV PRIORITIZATION OF RISKS FO
Page 67 and 68: context. We believe that the Common
Page 69 and 70: Managing Evolution by Orchestrating
Page 71 and 72: 1.1 The Contribution of this Paper
Page 73 and 74: Fig. 3. Integrated Change Managemen
Page 75 and 76: The requirement analysis is an iter
Page 77 and 78: Table 1. Conceptual Interface Requi
Page 79 and 80: Legend: Goals surrounded by dashed
Page 81 and 82: Table 5. Test Suite for GP-2.2 Tran
Page 83 and 84: 6. P. K. Chittimalli and M. J. Harr
Page 85 and 86: Noname manuscript No. (will be inse
Page 87 and 88: Dealing with Known Unknowns: A Goal
Page 113 and 114: Understanding How to Manage Require
Page 115 and 116: Chatzoglou et al. [4] conducted a s
Page 117: Evolution Elicitation Probability E
Page 121 and 122: for the defined success criteria. O
Page 123 and 124: Fig. 3. Codes Coverage ATM systems,
Page 125 and 126: The feedbacks provided by the ATM e
Page 127 and 128: 3. P. Carlshamre, K. Sandahl, M. Li
Page 129 and 130: Quick fix generation for DSMLs Ábe
Page 131 and 132: • extensibility: the supported li
Page 133 and 134: Fig. 7. Overview of the Quick fix g
Page 135 and 136: Fig. 9. Evaluation results (|V(M I
show all

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?