Software Engineering

p-ISSN: 2162-934X    e-ISSN: 2162-8408

2012;  2(5): 203-207

doi: 10.5923/

Dynamic Verifier Core: A Practical Solution to Mitigate the Risks of Software Risk Management Process

Ahdieh Sadat Khatavakhotan, Siew Hock Ow

Department of Software Engineering, Faculty of Computer Science and Information Technology, University of Malaya, Kuala Lumpur, 50603, Malaysia

Correspondence to: Ahdieh Sadat Khatavakhotan, Department of Software Engineering, Faculty of Computer Science and Information Technology, University of Malaya, Kuala Lumpur, 50603, Malaysia.


Copyright © 2012 Scientific & Academic Publishing. All Rights Reserved.


Risk management is considered as a crucial activity in all types of software development processes. While risk management plans are proposed to control and mitigate the risks, they may face some risks too. According to the formal reports, the remarkable rate of failure in IT projects shows the relative unsuccessfulness in the risk management process. This indicates the necessity of improvements in the current risk management models. The authors of this research proposed a dynamic verifier core (DVC) committee for mitigating the risks of risk management of software projects. This important is done by identifying deviations and thereupon leads to performance improvement in risk management process. The model tries to identify and control the involved risks in risk management process. Using a communication system facilitates close relations between the previous ad current projects’ employees. This system also accelerates the instant awareness of the changes with the comprehensive classification of risk factors and increases the efficiency of the model. In order to validate the model, the risks of a Customer Relationship Management (CRM) system of an industrial company have been managed. In the case study the related risk factors are successfully identified and classified. The results show the effectiveness and practicality of the model.

Keywords: Risk Management, Dynamic Verifier Core, Validation, Risk Identification, Risk Factors

Cite this paper: Ahdieh Sadat Khatavakhotan, Siew Hock Ow, "Dynamic Verifier Core: A Practical Solution to Mitigate the Risks of Software Risk Management Process", Software Engineering, Vol. 2 No. 5, 2012, pp. 203-207. doi: 10.5923/

1. Introduction

Software risk management process is different from the other products risk management due to the non-physical nature of deliverables. There have been proposed a verity of methods for software projects risk management. Some of these methods identify, monitor, and control the risks in accordance to the software development process, however, the rest of risk management methods act independently of the development process and do the risk management process by focusing on risks classification and risk factors identification[1]. An important point that researchers are emphasizing on is that risks have a changing nature. This means that a lot of internal or external, controllable or uncontrollable, hidden or obvious factors are affecting risk factors frequently, continuously, and dynamically[2].
By considering the aforementioned issues, this research proposes an iterative model with a dynamic verifier core to improve the risk management process by using some advantages of current models. To check the validity of the model, the risks of developing a Customer Relationship Management project are managed.

2. Dynamic Verifier Core (DVC)

Figure 1. The DVC steps
All the actions done for risk identifying and restraining are faced internally with some dangers, threats, and risks. Ignoring some risks, considering those risks that never happen, low or high unstable evaluations of risk factors probability occurrence, and their damaging impacts are some of the mentioned threats. When risk control process is properly performed during a project, the involved personnel do their responsibilities safely[3]. Therefore, weak risk management may amplify the threats of the project[4]. Embedding DVC in the centre of IT projects risk management is a beneficial approach to reduce the intensity of possible dangers and prevent probable deviations. There are three suggested steps for DVC as illustrated in figure 1.
At the end of each level in risk process, without considering the used method, the prepared reports, calculations, and documents deliver to DVC core, to audit and identify probable deviations from the goals, programs, and actions. Finally the required actions for removing such errors will be applied.

2.1. Risk Review Committee Combination

The risk management process is a professional job throughout which some experts with various skills and in different phases have special duties[5]. The main reason that most of risk management models are being done in some levels and phases, is that special experts do their professional activities in each phase.
Figure 2. The structure of the DVC for software analysis and assessment phases
Figure 3. The structure of the DVC for risk mitigation phase
By considering the aforementioned issues, at the end of each phase of risk process like risk identification, measurement, assessment, and mitigation, the related experts should be the review committee key members. Involving independent experts who are neither the direct stakeholders of this project, nor have personal interest or prejudice in this projects activities is recommended. Although, this committee can make decisions, it is suggested that project manager and risk manager have permanent plenipotentiary representatives in the committee. The last advice is that the number of committee members should be odd to avoid getting into deadlocks in decision making process and voting. Figures 2 and 3 show the structure of DVC for different phases of software risk management. The word “Dynamic” in the core indicates the flexibility of the structure of the committee. Figure 2 includes risk identification, risk measurement and risk assessment phases of software risk management. These three steps are called analysis and assessment phases. While figure 3 presents risk mitigation and contingency plan phase (See Fig. 2 & 3).

2.2. Identification and Classification of Deviations

As illustrated in figure 4, focusing on the goals of each step is the initial step to identify and classify the deviations[6]. Figure 4 illustrates DVC phases to control and mitigate arisen risks. By considering the changeability, flexibility, dynamism and risks reformation nature, the review committee should independently, accurately and fairly monitor the documents and activities and must be aware of project’s current status, threats and opportunities[7]. Therefore, using an interactive multi-user system called “Unseen-Overseen Project Change” (UOPC) to assist review committee is suggested.
Figure 4. The DVC phases
UOPC creates a link between project stakeholders, involved personnel, and even experts who were cooperating in the previous phases of risk process. While these people are facing to deliberate or unintentional changes, and even recognizing a threat or an opportunity, should broadcast their ideas, notices, and suggestions with the corresponding documents through the communication system to the review committee. Therefore, deviations’ classification could be predictable as below:
• Risk management actions’ deviations from the goal of each phase
• Risk management actions’ internal deviations in each phase
• Deviations from current requirements and real properties of the project compared to the initial requirements defined for risk management.

2.3. Recognizing the Severity of Deviations

Another important classification that should be done in DVC is to recognize the severity rate of the deviations. Three categories of deviation importance rate are: ignorable, resolvable in DVC, and necessary to be resolved by the originator. Classes two and three are ranked in a Meta class named “significant deviations.” Before the complete handling and removing the significant deviations, the rest of risk actions cannot be performed unless may lead to more deviations[8].

3. Customized Risk Factors

Table 1. The customized risk factors checklist
IT risk management scholars have proposed some different classifications for risk factors. Boehm is one of the earliest and effective experts in this field, who identified and proposed ten important risk factors from operational, practical, resources, and scheduling aspects[9]. Also in 2007, Symantec Corporation introduced four classes including security, availability, performance, and compliance with their sources and consequences. In 2008, Sutton and others have presented some risk factors from the aspects of system-user correlations, goals, and managers’ commitments in business systems[10].
The combinations of the studies done by the aforementioned researchers, OZ in 2000[11], Fairiey in 2003 [12], Tesch in 2007[13], and Fowler in 2007[14], are shown in Table 1. A comprehensive checklist of risk factors are gathered and presented in the following table which facilitates the risk management of IT projects.

4. The Case Study: Applying DVC on CRM Project

The selected company for the implementation of the model is working on some fields like interior and exterior design, industrial design, graphics, and multimedia. Customer Relationship Management (CRM) project is the current software system developing by this company. This project is the integration of various systems such as buy and sell, marketing and so on. The identified risks of this project are inserted in Table 2.
The remarkable point is that some risk factors can be in more than two classes. For instance, the risks arisen of using a new technology may relate concurrently to user capabilities, training programs, and attributes of the proposed technology.
Table 2. The identified risks during RM phases

5. Discussion and Results

The core of dynamic verifier was formed by creating a committee consists of company manager, financial manager, and projects administrator as the independent member. Deviations of the identified risks are explained in Tables 3 and 4.
Not only some important risks such as invoices confidentiality, data input control and protection risks were ignored, but also credit and contract risks were not identified either. There are some important points about DVC corrections; firstly, the main duty of DVC is to identify the unseen or newly arisen risks during the management process and prioritize the received risk factors and classifications based on their severity and occurrence. Secondly, as it is clear in Table 4, the Marginal risks will be ignored in DVC activities and the main focus and rankings id referred to Catastrophic and Critical risks.
Table 3. The new identified risks by DVC
Table 4. The verified risks by DVC
Another Specific feature of DVC is the flexible formation of expert committee. The combination of committee established for identifying deviations shows its high performance by addressing the weakness of software projects in contracts and costumer validation issues[15]. Thus, both software project and its product, that is, CRM system were improved. Adding related subsystems to the contracts as an important momentary requirement and defining subsystems for costumer identification, convert project hidden threats to opportunity. This opportunity is qualitative improvement of current processes and projects.

6. Conclusions

Re-monitoring the performed actions and prepared documents of every phase in the risk management, without considering the used approach, improves the efficiency of the model[16]. The proposed model in this research is to identify deviations and removing them, by forming experts committee who have various skills in related phases. Creating a dynamic communication link between project and organization employees and DVC practitioners facilitates the management of new or changed risks. This link also accelerates the identification and classification of the deviations. The case study shows the possibility of converting risks to opportunities by focusing on the project and IT product.


[1]  F.Tuysuz, C. Kahraman, “Project risk evaluation using a fuzzy analytic hierarchy process: an application to information technology projects,” International Journal of Intelligent Systems, vol. 12, pp. 559-584, 2006.
[2]  Vlasenko, O.&Kozlov, S. (2009). Choosing the Risk Curve Type. Technological & Economic Development of Economy, 15(2), 341-351. doi:10.3846/1392-8619.2009.15.341-351.
[3]  R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, "Identifying software project risks: an interactional Delphi study,". Journal of Management Information Systems, vol. 17:4, pp. 5-36, Spring 2001.
[4]  Cox Jr. L. (2008). Why Risk Is Not Variance: An Expository Note. Risk Analysis: An International Journal, 28(4), 925-928. doi:10.1111/j.1539-6924.2008.01062.x .
[5]  Yetman, L. (2006). Project Management: Careful Planning or Crystal Ball? Journal of the Quality Assurance Institute, 20(3), 40-42.
[6]  A. K. Chua, “Exhuming IT Projects from their Graves: an Analysis of Eight Failure Cases and Risk Factors,” Journal of Computer Information Systems, vol. 49(3), pp. 31-39, 2009.
[7]  Fraser, J. S., Schoening-Thiessen, K.&Simkins, B. J. (2008). Who Reads What Most Often? A Survey of Enterprise Risk Management Literature Read by Risk Executives.Journal of Applied Finance, 18(1), 73-91.
[8]  Kloss-Grote, B.& Moss, M. (2008). How to measure the effectiveness of risk management in engineering design projects? Research in Engineering Design, 19(2/3), 71-100. doi:10.1007/s00163-008-0049-y.
[9]  Boehm, B.W.; , "Software risk management: principles and practices," Software, IEEE , vol.8, no.1, pp.32-41, Jan. 1991doi:10.1109/52.62930.
[10]  Sutton, S. G., Khazanchi, D., Hampton, C.& Arnold, V. (2008). Risk Analysis in Extended Enterprise Environments: Identification of Critical Risk Factors in B2B E-Commerce Relationships. Journal of the Association for Information Systems, 9(4), 151-174.
[11]  E. Oz, & J. Sosik, "Why information systems projects are abandoned: a leadership and communication theory and exploratory study," Journal of Computer Information Systems, vol. 41:1, pp. 66-78, Fall 2000.
[12]  R. E. Fairiey, M. J. Willshire, "Why the Vasa sank: 10 problems and some antidotes for software projects," IEEE Software, pp. 18-25, March/April 2003.
[13]  D. Tesch, T. J. Kloppenborg, and M. N. Frolick,” IT Project Risk Factors: The Project Management Professionals Perspective,” Journal of Computer Information Systems, vol. 47(4), pp. 61-69, 2007.
[14]  J.J. Fowler, P. Horan, “Are Information Systems’ Success and Failure Factors Related? An Exploratory Study,” Journal of Organizational and End User Computing, vol. 19(2), pp. 1-22, 2007.
[15]  Benaroch, M., Lichtenstein, Y.& Robinson, K. (2006).Real options in Information Technology Risk Management: An Empirical Validation for Risk-Option relationship.MIS Quarterly, 30(4), 827-864.
[16]  Wu, D.& Olson, D. L. (2009). Introduction to the Special Section on “Optimizing Risk Management: Methods and Tools”. Human & Ecological Risk Assessment, 15(2), 220-226. doi:10.1080/10807030902760967.