D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

that the interview guide is accurate. Moreover, to reduce this threat we have used a number of information sources and data collection techniques. – Internal Validity:Internal validity is an inductive estimate of the degree to which conclusions about causal relationships can be made (e.g. cause and effect), based on the measures used, the research setting, and the whole research design. A threat to internal validity in our case study was related to communication issues with the ATM experts. First of all there was a communication gap between the requirements analysts and the ATM domain experts: certain concepts have a different meaning for them. A second issue was related to language barriers: the ATM expert had to provide feedbacks not in their mother tongue language. For these reasons, some useful feedbacks might not have been given to the requirement analysts. – External Validity:External validity concerns the extent to which the (internally valid) results of a study can be held to be true for other cases, for example to different people, places or times. Since we have conducted a qualitative user study, our objective was not to do any generalization of the results to other contexts, but understand the change management process adopted when a new tool is introduced in complex and critical systems such as air traffic management systems and to investigate the applicability of the approach to model and reason on evolution. To generalized the findings of this user study we are planning to consider other complex systems in different application domains. – Conclusion Validity:This threat is concerned with the degree to which conclusions reached are justified. Our conclusions are based on the remarks and comments given by the ATM experts. The video recorded discussions between the ATM experts and requirement analysts have been analyzed to provide evidence in accordance to the real context of the ATM domain. To have an effective discussion with the ATM experts, the requirement analysts also had a prior meeting with them to confirm the protocol for the discussion. 5 Analysis of the Results This section summarizes the feedbacks that were collected during the two workshops WS1 and WS2 and analysis of the feedbacks by the requirement analysts. 5.1 Feedbacks During the Experiments Execution On the applicability to the ATM domain of the approach to model and reason on requirements evolution the participants P5 and P12 have pointed out that the approach could be very useful during the initial phase of the change management process adopted by ANSPs. The approach can help managers, technicians and controllers to understand the implications and impacts of a proposed change. P5 and P12 suggested that Evolution Elicitation and Probability Estimation might be useful to identify the alternative operational requirements associated with a proposed change. The Reasoning phase instead can be used to support the decision makers in identifying the best solution at operational level to be implemented. A challenge in applying the approach to model and reason on requirements evolution was reported by participants P6 and P9. They argued that due to the complexity of 10
Fig. 3. Codes Coverage ATM systems, it is very difficult to identify all possible evolutions in advance and to predict the probability of evolutions. P6 and P9 also remarked that it is possible to identify certain evolutions only during the change impact analysis phase. Thus, the ATM experts suggested that an incremental approach should be adopted to identify all possible evolutions for a given before-evolution requirements model. Moreover, participant P12 has pointed out that qualitative metrics such as risk severity are already used to classify a change, and therefore new metrics should be related to those already in use. On the graphical representation of evolution rules, all participants have agreed that they prefer the tree-like representation illustrated in Figure 1(a) rather than the swim lane representation in Figure 1(b). Moreover, participant P13 has expressed a positive opinion about the applicability of the graphical representation to capture the evolution in ATM, P6 and P9 instead were not totally confident about that. 5.2 Observations from Requirement Analysts Some of the main observations made by the requirement analysts are reported in what follows. – Build requirement models with the experts triggers many useful discussions with and among the experts, and help reveal inconsistencies and mistakes in the models. – More feedbacks could have been collected if the ATM experts would have applied the approach to model and reason on requirements evolution. – There was a communication gap between requirement analysts and domain experts regarding the terminology used in the study. ATM experts should have been encouraged to provide also written feedbacks to reduce the language barriers. – It would have been better to involve all the different stakeholders - air traffic controllers, managers, software engineers- who participate in the change management process adopted by ANSPs. – Having internal working sessions with the domain experts before the workshops is key for collecting useful feedbacks from the ATM experts. 11
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 and 118: Evolution Elicitation Probability E
Page 119 and 120: Table 2. Participants Background Pa
Page 121: for the defined success criteria. O
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

Create successful ePaper yourself

Delete template?

Save as template?