D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

Table 3. User Study Organization Meeting Date Participants Contents PM1 March, 2011 RA, OBS Participants identify the research questions of the user study, and the success criteria. Further more, the strategy to be followed to conduct the study is sketched. IWS1 March, RA, OBS, DE RAs,OBSs and DEs define and agree upon the IWS2 WS1 (day 1) 2011 March, 2011 April, 2011 RA RA, OBS, DE research design. RAs prepared the training materials (tutorials about requirements engineering, requirements evolution, interview guide. These documents were distributed to all the DEs. RA present the training material to domain experts. Domain experts give feedback to enrich each of discussed items, and to improve the way they are presented. WS1 (day 2) April, 2011 RA, OBS, DE RA gives an introductory talk about ideas of evolution. Next, RA presents research objects. During each of presentation, DEs are interviewed to collect feedbacks about the change management process adopted by ANSPs. IWS3 May 2011 RA,OBS The RAs analyze feedbacks from WS1 and WS2 IWS4 June, 2011 August, 2011 prepare for WS2. RA, OBS, DE Participants continue the validation work. DEs elaborate more on the approach to model and analyze requirements evolution. RA, OBS, RAs analyze the feedbacks collected during the two workshops. The table shows the organization of the user study. In this table PM = Preliminary Meeting, IWS = Internal Working Session, WS = WorkShop. second day of the first workshop and during the second workshop. In this session, requirements analysts gave presentations about the proposed approach to model and reason on evolution. The domain experts were asked whether the approach would make sense or useful based on their experience. The domain experts also reported the existing process to change management adopted by Air Navigation Service Providers. 4.3 Results Analysis The qualitative data collected in the form of video recording were transcripted to understand and review the conversations between the ATM experts and the requirement analysts. The tool used to perform qualitative data analysis is NVivo 9 [7]. Using NVivo, the transcription is coded (in terms of qualitative analysis) to distinguish between the various topics of discussion and points of feedback. Different codes and their descriptions are reported in Table 4. The coding was further analyzed to emerge with evidence 8
for the defined success criteria. On the various transcripts, the code percentage coverage was performed to display the percentage of occurrence of a code in comparison with other codes. The percentage coverage diagram reported in Figure 3 shows that the conversations related to operational procedures and change management procedures have maximum coverage on the transcription. Table 4. Description of codes used. Code Description AMAN The specific discussion points related to AMAN which covers the factors considered as constraints for AMAN, the expectations of the experts from AMAN and the procedures associated with AMAN. Change Managemencludes the steps of Brain Storming, Risk Assessment, Simulation, The discussions on the change management procedure which in- Human Verification, Type of Change, Evolution, Change Management Procedure and Constraints for change management. Functionality The specific functionality mentioned in accordance to the role of either the Controller or the Coordinator. Goals The discussions related to goal refinement and goal sharing concepts in i*-based requirements modeling language. Operational The operational procedures followed by Air Traffic Controllers in Procedure the real situation. Organizational The composition of organizational roles in ENAV. Role Feedback on The feedback obtained on the graphical representation of evolution Graphical Representation presented by the requirement engineers. Behavior The behavior observed apart from the discussion points as silence, indirect answer and not interested. 4.4 Threats to Validity We consider threats to construct, internal, external and conclusion validity [17] as relevant for our user study. – Construct Validity:Threats to construct validity are related to decide to which extent what was to be measured was actually measured.The main construct validity threat in this study regards the design of the measurement instrument: are the questions formulated so that the interviews answer our research questions? Our main measurement instrument is the interview guide which includes the questions to be asked. Three requirement analysts have constructed it by analyzing the research questions and creating sub-questions. The list of questions have been reviewed by the consultants to check for completeness and consistency; therefore we believe 9
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: Table 2. Participants Background Pa
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

Create successful ePaper yourself

Delete template?

Save as template?