Using Model-Driven Risk Analysis in Component-Based Development

Abstract

Modular system development causes challenges for security and safety as upgraded sub-components may interact with the system in unforeseen ways. Due to their lack of modularity, conventional risk analysis methods are poorly suited to address these challenges. We propose to adjust an existing method for model-based risk analysis into a method for component-based risk analysis. We also propose a stepwise integration of the component-based risk analysis method into a component-based development process. By using the same kinds of description techniques to specify functional behaviour and risks, we may achieve upgrading of risk analysis documentation as an integrated part of component composition and refinement.

Divide and Conquer – Towards a Notion of Risk Model Encapsulation

“…In [3] this is demonstrated by the instantiation in CORAS. In [5] this modular and component-based approach to risk assessment using CORAS is integrated into a component-based system development process to support risk assessment in the development process. The instantiation in CORAS is further elaborated in [15], resulting in an extension referred to as Dependent CORAS.…”

A Denotational Model for Component-Based Risk Analysis

“…We provide a formal model for representing events that harm assets. For a discussion of how to obtain further risk analysis results for components, such as the cause of an unwanted incident, its consequence and probability we refer to [3].…”

Risk Assessment Techniques and Survey Method for COTS Components

“…• Higher Complexity of components architecture and the connectors introduces the chances of risk [1]. • Mismatch between connectors and message protocols • Interface specification of the components is not clear or not specified [5] [13] as architects have at hand incomplete, imprecise and uncertain component information [16].…”

“…• Higher Complexity of components architecture and the connectors introduces the chances of risk [1]. • Mismatch between connectors and message protocols • Interface specification of the components is not clear or not specified [5] • Components are not interoperable [5] with each other due to missing well defined interfaces • Lack of Software architecture document that is extreme crucial in order to gain knowledge about the component • Loop holes in Architectural Style [13] as architects have at hand incomplete, imprecise and uncertain component information [16]. And the quality level that has been set during the initial phase of the software development cycle • Complicated system manual results lack of understanding by the users • Quality services after the COTS software installation at the user site are not given • User is not facilitated with the upgraded copies of the component based software • Updating or alteration of the component based system cannot be facilitated • Lack of tracing of alternate component in case of failure [8] • Planning the maintenance is difficult as the components have asynchronous cycle [8] A When the COTS Component and the requirement suggested by the user does not matches B Requirements of the users changes frequently C Budgets and schedules are not realistic D Unclear requirements specification E Lack of accuracy in schedule F Lack of reliable and suitable licensing contracts that encompass the appropriate documentation and responsibility of the vendor and developer in case of failure G Rigidness in Time constraints of schedule generates inflexibility H Market survey is not done properly than appropriate components that can map with user requirements cannot be found I Lack of contingency planning J Rapid requirement change of the user K Component search suffers from appropriate fetching and classification mechanism provided by the marketers L Architectural prototype not defined properly M Latest Technologies and fresh arrived COTS product are not analyzed or lack of market survey N Vendors incapability to delivers mind blowing demos and specifications of the COTS product O Architecture was not analyzed during the component selection process [8] P Cumbersome and complicated requirements Q Lack of vendor support R Missing authenticity of the components due to the lack of certified components S Unavailability of the source code leads to judging nature and the behavior of the components T Inappropriate domain knowledge of developer [7] U Higher Complexity of components architecture and the connectors introduces the Chances of risk V Mismatch between connectors and message protocols W Interface specification of the components is not clear or not specified properly X Incompatible or mismatch Interfaces may obstruct the data communication between the components which wants to exchange data Y Use of the Software model that does not support component based software Development process Z Prerequisite Quality is not met due to the lack of market survey that has to be done to Know Software Risk is "High Through this survey Risk factor come out to be in the second risk rating that reflects risk as low.…”