Identification of Critical Risk Phase in Commercial-off-the-Shelf Software (CBSD) using FMEA Approach Introduction OTS-based software development aims in building the software using the existing developed components. The components can be developed in house for usage among vast projects of similar requirements. The components can also be purchased from the market as the components are also developed as small software's which intend to provide the basic functionality required for large projects.
Various components are also available in the repositories with their functionalities and Quality attributes. A target application/ software are developed by selecting the appropriate components from the component repository & then integrating the components into a target system as in Figure 1 below.
At present time, more than 60% of software are developed using component approach due to its enormous features such as:
Author ?: Student, School of CSE, Lovely Professional University Phagwara, Punjab. e-mail: [email protected] Author ?: Assistant Professor, School of CSE Lovely Professional University Phagwara, Punjab. e-mail: [email protected]
Figure 1 : Component-based Software Development
? Rapidly development.
? Accessed Immediately.
? Reduced Complexity.
? Increases efficiency of products.
? Reduced implementation, operating and maintenance cost. ? Reduced amount of time to deliver products in the market, budget and schedule saving, more than half of the software developers used component based approach. This approach has reduced the software crisis at great extent [6].
The main rationale of CBSD approach is to develop big system by integrating the pre-built components which decrease the progress time & costs. There are five main phases: Identification, Evaluation, Selection, Integration and Development of component to develop software using CBSD approach as mentioned in Figure 2 below.
To provide a reliable and effective software product in the market, software industry influenced by COTS development approach. In software applications CBSD is the only need to be written once and re-used multiple times than being re-written every time when a new application is developed. CBSD approach overlaps the traditional software engineering approach where existing technologies were failed to deliver project ontime and on-budget. The main reasons of these failures are: Testing -Figure 2 : COTS Development Life cycle -efforts are not properly estimated; Team's skill is under/over estimated. However, the use of CBSD approach provides a lot of benefits, but still there are several challenges, risks, uncertainties related to this approach [6]. As the name suggested, CBSD approach means use of existing components, we are depending upon someone else (lack of trust). The main reasons of these problems are due to these factors:
? Wrong selection of components,? Black box nature (non-availability of code) of COTS Components,
? Lack of knowledge, guidance etc.
? Unknown quality of COTS Products.
Many times, some risks are not identified in one phase and it overlaps to the second phase so in this way, it influences the whole software and fails to the organization's business. So, there is a need of proper Risk Management for using this CBSD approach from the starting phase. Failure Modes and Effects Analysis (FMEA) is a systematic method for evaluating a process to identify where risk is and how it might fail and to assess the relative impact of different failures [7]. With the help of FMEA approach, this paper provides risk management strategy for Commercial-off-The-Shelf Software development.
In developing software using CBSD approach there is an uncertainty that there can be variations between the planned development approach and the actual software developed. A risk could cause an organization to fail to meet its approach and objectives. The main steps of this paper are as in Figure 3 below: The use of commercial-off-The Shelf software Development has become an important need for developing software as they offer reduce development time and effort. Similarly there are many challenges faced such as the quality attribute of selected components may cause deviation in the quality of final product, also the cost and effort involved in integrating component during the design process may cause the product design to deviate from the actual requirement There are many challenges that start during COTS development (Identification, Selection, Evaluation, Integration, and Development) summarised as below [1]
Using the COTS development approach the components are purchased from the third party vendor due to which the development of the software depends upon the customer support services provided by the vendors. So, there are several chances of arising risks on each phase of CBSD as in figure 4. The risks in CBSD life cycle are due to the factors such as the black box nature of COTS components, lack of interoperability standards, the disparity between the user & suppliers, incomplete format of requirement documentation etc. The classification of risks based on various phases is briefly defined as in [6]. Risk during this phase is associated with the problems of evaluating and selecting off-the-shelf software for use in the system. The risks in this phase are due to some parameters as unavailability of source code, inflexibility of COTS components, lack of requirement document, architecture mismatches etc.
These risks are associated with problems of integrating systems from the existing COTS components. These risks can occur while composing of COTS components due to the lack of interoperability standards, occurrence of incompatible format among different COTS components, incomplete format of requirements etc.
The risks in this phase are arises when we develop the architecture from the selected COTS components. The risk arises due to the problem of using an inappropriate development process.
The risks in this phase are during when we implement the final systems after selecting the appropriate components. These risks are due to the unclear design assumptions, performance factors, and security factors.
ii. Classification of Risks during Phase-wise of CBSD There are three types of areas where the identified risk arises mostly:
? Functional/ Operational Requirements -The risks are which arises with the functionality and performance of the system as perceived by its operators.
? Procedural approach -The risks that are related with the technical characteristics of COTS products. ? Production strategy -Those risks which are related with the vendor of the COTS product. In COTS components, the actual functionality and performance of a COTS product are not as publicized so the system may not meet its requirements.
Requirements Gap COTS component does not match the current operational requirements or procedures.
It may not be possible to certify that the product meets requirements because the COTS product must be tested as a black box without its implementation
If there is no access to source code, then it may be difficult to trace integration and testing problems to COTS products Upgrades Sometime during upgrading COTS software, it increases the size of the programs & the size of the hardware memory in the system may be insufficient.
The main focus is to track, control and reduce the identified risk. A survey was conducted in various CMM level 2 companies which summarized the possibility of risk and corresponding impact of risks. Two approaches are used to calculate the risk score of identified risks in order to plan mitigation approach for the high impact risks. a. Failure Mode and Effect Analysis (FMEA) b. Goal-Driven software Risk Management (GSRM) a. Failure Mode and Effect Analysis A failure mode and effects analysis (FMEA) is a method for examine of potential failure modes within a system for classification by the probability and likelihood of the failures [5]. This procedure helps a team to identify potential failure modes based on past experience with similar products, enabling the team to design those failures out of the system with the minimum effort and resource expenditure. Effects analysis refers to studying the consequences of those failures. To calculate the risk score of identified risks, we are using this approach & filled the questionnaire from the 12 team member based on their past experience of using COTS components.
The probability of each risk item is measuring on likert scale ranging from low (1), moderate (3), and critical ( 5 The impact of corresponding risk item is ranging from very low (0) to critical (5) Here are some assumptions of choosing these values:
? It is assuming that the impact of each risk could be different at each phase; it could be or not be same at each phase. ? Suppose there is a probability of arising risk is Low (1), but its impact may be moderate (2) or may be critical (5). The working formula is:
Results of questionnaire: The results that have been conducted from the respondents are shown as below: - From the above risk score, we analyzed RS5; RS 8 are critical risks because they have high impact of risks. During study it is analyzed that if the risk in one phase is unseen or undetected, it goes to the second phase and so in this way it impacts to the whole system. If the risk in one phase is not detected, it overlaps to the second phase and increases its multiplicative impact factor [5]. In GSRM approach the main focus is to integrate the whole risk activities, so that we can identify those phases which have high impact of risks and then we can mitigate those risks. So we will calculate the total impact of risks as table 10.
The working formula to calculate total risk is as: Analysis of Total Risk Score Now the mitigation strategy will be designed for most critical risk that is Integration Phase.
Total Risk Score= ?RS k +?RINT k +?RD k + ?RI kCOTS Integration means when different COTS packages are combine into a system with "glue code". For ex, Office Automation Software, email, messaging system, where the components are bundled as a procedural library [1]. But in this phase many risk arises as:
? Lack of interoperability standard.
? Lack of tools, methods to integrate components.
? Effort for integration may increase from what was estimated. ? When developers try to integrate incompatible COTS components etc.
This integration phase becomes a most challenging phase in Component-based Software Development. The main failures in software arise due to wrong integration of components. As in [4], the recent computer screen upgrade in the British Government caused nearly 80,000 desktop computers to crash The crash halted the United Kingdom's pension and benefits agency that provides benefits to about 24 million people. The crash delayed the process of new claims and forced employees to fax and fill out some payment checks by hand. The problem occurred during an upgrade across the network of computers. So there is need to improve Integration techniques of COTS components.
Mitigation guidelines for Integration of COTS Components:
1. A proper understanding of component's capabilities is must how components are packaged and evaluated.
2. A developer should avoid general modifications to COTS components.
3. Modifications that add the complexity to the project of COTS components should be avoided. IV.
Commercial-off-The-Shelf Software Development has become a great need for large organizations as it saves development time and money. It is belief that COTS components fulfill everyone's needs and can be used as-is. In reality, the risk arises in each phase of CBSD as, COTS selection, Integration, Development and on maintenance phase. In this paper, the main focus is to provide risk identification strategy for COTS based software Development. The risk adds on each phase of CBSD was identified and risk score is calculated to examine the critical risk phase.
1. Risks Involving in Functional/ Operational | |
Requirements | |
Requirements | |
Availability | In the case of COTS components, it is |
Risks | difficult to predict that the available |
COTS component will meet the | |
functional requirements, so the | |
estimated development cost and | |
schedule are highly uncertain | |
Functionality | |
& Performance |
Conformance | COTS components do not conform to | ||
to | commercial | standards | so |
Commercial | interoperability with other selected | ||
Standards | COTS products may be difficult & | ||
costly. | |||
Integration | Contractor does not have the technical |
For this | Risks | |||
potential | ||||
kinds of | ||||
Risks are: | ||||
Acquisition | During evaluation time, alternative | |||
Alternatives | methods of acquiring COTS products | |||
Risks | are not evaluated | |||
Vendor | Sometimes, the vendor of COTS | |||
Reliability | product is financially weak or unstable | |||
Risks | & poor support. | |||
Cost and | The cost and schedule estimates are | |||
Schedule | not considered during acquiring the | |||
Completeness: | COTS-based system. | |||
Business Skills The | relationship | between | the | |
contractor and vendor contractor are | ||||
weak. |
COTS | Risk Id | Risk in Selection Phase | Risk Score | |||
Driver/Factor | ||||||
Behaviour Factors | RS1 | Unavailability of source | 124 | |||
code | ||||||
RS2 | Organizations have very | 108 | ||||
limited access to product's | ||||||
internal design. | ||||||
RS 3 | The Quality level of a | 118 | ||||
component is unknown. | ||||||
RS 4 | During | evaluation, | 126 | |||
developers have limited | ||||||
chance to verify COTS | ||||||
behaviour. | ||||||
Functionality | RS 5 | Requirement of the user and | 174 | |||
Factors | component | architecture | ||||
does not match. | ||||||
RS6 | Architecture | of | the | 113 | ||
component is not analyzed | ||||||
according | to | the | ||||
functionality. | ||||||
RS 7 | Difficult for requirement | 86 | ||||
engineers to select among | ||||||
different | techniques | of | ||||
selection. | ||||||
RS 8 | Lack of market survey. | 207 | ||||
Cost Factor | RS 9 | Required COTS is found | ||||
costly as compared to in- | ||||||
house Development cost. |
Risk Driver/ | Risk Id Risks in Integration | Risk | ||||
Factors | Phase | Score | ||||
Cost Factors | RINT1 | Underestimate | the | 122 | ||
development time and | ||||||
cost | ||||||
RINT2 | The cost is too much to | 83 | ||||
configure the components | ||||||
RINT3 | Immature | COTS | 91 | |||
components. | ||||||
RINT4 | Lack | of | requirement | 211 | ||
configurations. | ||||||
RINT5 | Lack of cost control. | 112 | ||||
Size Factors | RINT5 | Difficult to predict the size | 132 | |||
of components. | ||||||
Personnel | RINT6 | Lack of knowledge. | 73 | |||
shortfall factors | ||||||
RINT7 | Lack of interoperability | 146 | ||||
standard. | ||||||
RINT8 | Lack | of | integrator | 150 | ||
personnel. | ||||||
Security | RINT9 | Vulnerability risks. | 140 | |||
factors | ||||||
Functionality | RINT10 | Unavailability of source | 137 | |||
Factors | code. | |||||
RINT11 | Components | are not | 86 | |||
platform independent. | ||||||
Analysis of Risk Score |
Phase | |||||
Functionality | RI 1 | Unclear | design | 139 | |
Factors | assumptions. | ||||
Usability | RI 2 | Users cannot retrieve | 97 | ||
Factors | relevant & needed | ||||
information. | |||||
Security | RI 3 | System can be used in | 132 | ||
Factors | unintended way. | ||||
RI 4 | Increase in vulnerability | 160 | |||
attack by integrating | |||||
components with one | |||||
another. | |||||
Performance | RI 5 | Effect | on | system | 114 |
Factors | performance. |
Total impact of risk | |
CBSD phase | Total Risk |
Risk in Selection phase | 1098 |
Risk in Implementation Phase | 1481 |
Risk in Implementation Phase | 642 |
44 Year 2014 Volume XIV Issue II Version I | 4. 11. A developer should use open Standard technologies that are freely distributed among different data models or software infrastructure |
( D D D D ) c | which provide basis for communication and enable consistency among different COTS |
Global Journal of Computer Science and Technology | components [6]. 12. A proper estimation of time and cost should be estimated, before integrating COTS Components. 13. All drivers should be considered before measuring component behaviour. For ex, ACIEP-used for COTS Integrator Experience with the product, ACIPC -used for COTS Integrator Personnel Capability. |
Requirements Engineering Challenges in Development of Software Applications and selection of Customer-off-The-Shelf (COTS) components. International Journal of Software Engineering(IJSE) 2010. p. .
Conceptual Model for Integration of COTS Components. Department of Computer science &IT, p. .
Improving COTSbased Software Development Process by Identification and Mitigation of Component Risks. International Journal of Advanced Research in Computer Science and Software Engineering 2013. p. .
Risk Management Guide for DOD Acquisition. OUSD (AT&L) Systems and Software Engineering/Enterprise Development,
Determination of Risk During Requirement Engineering Process. Journal of Emerging Trends in Computing and Information Sciences, p. .