D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

24 F. Massacci and L.M.S. Tran analysis rather than empirical observations in an industrial application, they confirmed the premise of the key to successfully change is knowledge about “where the enterprise is currently”, “where the enterprise wished to be in the future”, and “alternative designs” for the desired future state. Nurcan and others [24, 25, 30] presented the Enterprise Knowledge Development - Change Management Method (EKD-CMM) which was used in the ELEK- TRA project [26]. The main goal of EKD-CMM is to provide a framework to understand the way a specific organization works, determine the reasons and requirements for changes, alternatives to address the requirements, and the criteria for the evaluation of the alternatives. The application of the EKD-CMM results in three models, namely the As-Is-Model, the To-Be-Model and the Change Process Model. Also discussed on EKD-CMM, Barrios and Nurcan [4, 23] mentioned a critical need for realistic representations of “what are the current or future business situations”, or what should be changed in today enterprise. They provided a roadmap for EKD-CMM as a systematic way to deal with enterprise modeling and transformation. Enterprise objectives (or enterprise goals), processes, and systems are integrated in a single modeling framework using three-layer model. Other notable works include Dalal et al [8] and Kassem et al [13]. Dalal et al, in their article [8] identified four gaps related to EM methods. Among those, one serious gap is a lack of a formal theory enabling quantitative analysis in the interests of making better business decisions. Our proposal of the quantitative metrics of MaxBelief and Residual Risks directly addresses this issue. In [13], Kassem et al. presented guidelines for the selection of the right modeling method, and proposed a methodology for Enterprise Modeling. They found that the selection should be a function of: the purpose, the ease of communication between stakeholders, the characteristic of the modeling environment and the characteristic of the modeling technique itself. The methodology is based on the combined use of IDEF0 and Dependency Structure Matrix (DSM) to produce functional requirements for the collaborative software. This methodology hence is capable to understand complex interactions, facilitate the management of change, and create a shared vision of business processes. However, the authors did not focus on any further analysis for change management. 10 Conclusion In this work we have addressed the issues of modeling evolutions of enterprise systems. In particular, we focused on potential evolutions which can be foreseen, but it is not sure that these evolutions do actually happen. We called this problem managing known unknown. Our proposed approach introduces the notion of evolution rules, comprising of observable and controllable rules, as a mechanism for handling this phenomenon. The uncertainty of evolution is expressed using probability values represent expertise beliefs on the occurrence of evolutions, which is accounted using gametheoretic approach. Additionally, we provided a brief discussion about the graphical notion for representing these rules, which has been validated with ATM experts. Furthermore, based on that belief, we introduce two quantitative metrics to
Dealing with Known Unknowns: A Goal-based Approach 25 measure the level of usefulness of design alternatives. This provides a quantitative analysis that supports decision makers in deciding which is the optimal configuration for their enterprise. To exemplify our approach, we discussed a case study in ATM domain. This case study is about deploying AMAN to the working position of ATCOs, and its applicability aspects have been subject to a number of sessions with ATM experts. From that case study, we have drawn several examples to explain our idea, and also to show the promising applicability of our approach. Our future work is geared towards providing an interaction protocol with stakeholders that allow a simple elicitation and validation of the probability estimates. A promising avenue seems to use the Analytic Hierarchy Process (AHP) method for a first cut description and then use our game semantics to validate and refine them. References 1. C. Anderson. The long tail. Wired, October 2004. 2. A. I. Antón and C. Potts. Functional paleontology: The evolution of user-visible system services. IEEE Transactions on Software Engineering, 29(2):151–166, 2003. 3. S. Ba, A. B. Whinston, and K. R. Lang. An enterprise modeling approach to organizational decision support. In Proceedings of the twenty-eighth annual Hawaii International Conference on System Sciences, pages 312–320, 1995. 4. J. Barrios and S. Nurcan. Model driven architectures for enterprise information systems. In Proceedings of the 16th Conference On Advanced Information Systems Engineering, pages 3–19, 2004. 5. P. Bernus. GERAM: Generalised enterprise reference architecture and methodology. version 1.6.3, March 1999. 6. D. Boyd. A new management technique. Enterprise models: Industrial Management Review, 8(1), 1966. 7. CIMOSA. Computer integrated manufacturing open system architecture: A primer on key concepts, purpose and business value. Online primer, Accessed April 2009. 8. N. P. Dalal, W. J. Kolarik, and E. Sivaraman. Toward an integrated framework for modeling enterprise processes. Commun. ACM, 47(3):83–87, March 2004. 9. G. Dougmeingts, Y. Ducq, B. Vallespir, and S. Kleinhans. Production management and enterprise modelling. Comput. Ind., 42:245–263, July 2000. 10. A. Elberse. Should you invest in the long tail? Harvard Business Review, 2008. 11. J. L. Fiadeiro. On the challenge of engineering socio-technical systems. In Software- Intensive Systems and New Computing Paradigms, volume 5380 of Lecture Notes in Computer Science, pages 80–91. Springer-Verlag, 2008. 12. J. Hassine, J. Rilling, J. Hewitt, and R. Dssouli. Change impact analysis for requirement evolution using use case maps. In IWPSE ’05, 2005. 13. M. Kassem, N. N. Dawood, and D. Mitchell. A structured methodology for enterprise modeling: a case study for modeling the operation of a british organization. Journal of Information Technology in Construction, 16:381–410, 2011. 14. C. F. Kemerer and S. Slaughter. An empirical approach to studying software evolution. IEEE Transactions on Software Engineering, 25(4):493–509, 1999. 15. W. Lam and M. Loomes. Requirements evolution in the midst of environmental change: a managed approach. In CSMR ’98, 1998.
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 107: 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 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

Create successful ePaper yourself

Delete template?

Save as template?