Using V-Model Methodology, UML Process-Based ...

2014 International Conference on Cloud Computing and Internet of Things (CCTOT 2014)

Using V-Model Methodology, UML Process-Based Risk Assessment of Software and Visualization Muhammad Rashid Naeem

Adeel Akbar Memon

WeihuaZhu School of Software Engineering Chongqing University Chongqing, China rashidnaeem717@yahoo. com

Adeel Khalid School of Software Engineering Chongqing University Chongqing, China

Risks are affecting largely to software industry. W. Han and S. Huang also describe its effect on software projects and show report [4] by Standish Group in 2004, which indicated that 53% of projects were unable to deliver on time within budget or within required functionality, whereas 18% projects were cancelled due to software risks. According to this report, risk assessment is one of the most critical parts of software engineering.

Abstract-Risk Assessment is one of the most critical parts of software engineering process, and risks are the factors that could be results in software failure if they are not correctly handled. In this Paper, we propose a solution to reduce risks using UML visualization (Software performed

of

software

Development to

produce

development lifecycle.

processes Lifecycle verified

in

detail,

Model)

results

and

V-Model

techniques

in

each

phase

are of

Using all above aspects and research

findings, we propose "Risk Assessment V-Model". Furthermore,

For risk assessment, there are various measures have been taken, and some of them are implemented and currently in use by many organizations. Most of these measures focus on specific area of risks. In next section we will discuss some of related approaches proposed by authors to handle risks.

we use "Do Sale Process" to discuss different properties of our model. This model is quite in general and can be applicable and expendable for many kinds of software systems.

Keywords-Risk

Assessment,

UML,

Risk

Identification,

Software Project Risks, V-Model

I.

II.

INTRODUCTION

One of the critical concerns in software industry today is risk management. Risks could results in software failure if they are not managed accordingly. Risks are basically combination of two factors where first is software malfunctioning. It focuses on failure to deliver at certain part of software development cycle. Second factor is severity. It shows effects of malfunctioning in software processes. Sometimes malfunctioning cannot be manageable. For example if all software processes are dependent on malfunctioned process and it need to be changed. It may affect whole software and may results in software failure.

Ranking risks is the most popular technique to measure severity of software risks. In [5], Y. Wang et al. proposed a technique to rank risks on historical data. Assessment is divided into two parts, First part is gathering assessment set from Historical data. Secondly, achieve matrices values for risks in the set. Trustworthiness is also a major factor in software development model. In [6], J. Li et al. propose trustworthiness metrics and risk management effectiveness calculation methods with risk transfer assumptions and cost constraints to improve software process risk assessment and enhance trustworthiness for software process management.

Software risk management is the practice of assessing and controlling risks that affects the software projects, process or products. In [1], S. Nurazlina et al. describes that risk management as practice to avoid software risk and using software visualization it may helpful for software risk assessment in software development life cycle.

Software Visualization technique is also a good way to reduce software risks as we mentioned previously in [1]. Using software visualization there is more possibility of assessment accuracy.

In [2], M. Bosan et al. defined possibility of loss by software risks in form of poor quality and increased cost and also as software failure or delay in completion. As formation Technology is expanding, there are more chances of risks in software development then before. In [3], Z. Kremljak and C. Kafol describe different types of risks to which companies are exposing day by day and their effect on software projects

978-1-4799-4764-5/14/$3\.00 ©20141EEE

RELATED WORK

Risk assessment is done at different levels and stages. There are several methodologies are introduced to handle different kinds of software risks associated with software and software development lifecycle.

Besides, these are many assessment models for risks, some of them based on probability matrices, mathematical matrices or on questionnaires based risk assessments, and most of them are for specific field of use.

197

Changchun, CHINA

A survey conducted by K. Georgieva et al. in [7] gives analysis of different assessment models and a timeline from 1995 to 2008 about risk assessment. Some of them ensures qualitative and some quantitative assessments.

selected basis on type of risk. The seven and last phase is to calculate-risks and takes measures to solve them.

From all above observations, we conclude that software risk assessment is critical part and as risks involve, there is possibility of failure or delay in software completion. There are many models to overcome, but we use assessment based on UML Specifications. As UML can better visualize software processes, therefore it's easy to determine risks at every phase. Our model is methodological base which main goals are to identify and monitor risks and also ensures traceability at each phase. III.

RISK ASSESSMENT MRTHODOLOGY

In this model, we use methodology based on UML and V­ Model development lifecycle. As we know, UML is the most widely used for software development, and it is understandable by developers and designers. UML diagram also helps to manage complexity of system and architectural problems, and enhances comprehensibility [8] and [9]. Fig. 2. Phases of Risk Assessment V-Model

On other hand, V-Model is widely accepted development lifecycle for software development [10]. It is best model for test driven software development. Each phase of V-Model have two objectives. One is Validation, and second is Verification as defmed by IEEE in [11]. Validation refers to requirements analysis and verification refers to evaluation of requirements at each phase with respect to validation.

In this section, we discussed our risk assessment methodology and importance of phases to be used in our model with respect to V-Model methodology. In next section, we will discuss our model and its phases in detail with application

In our methodology, we assume validation as identification of risks and validation as monitoring or evaluation of risks. We have seven phases of risk assessment in our model as shown in Fig. 1.

IV.

RISK ASSESSMENT V-MODEL & ApPLICATION

As we discussed before, our model is methodological based and its phases overview. In this section, we will discuss its aspects in detail as The Risk Assessment V-Model is shown in Fig. 2.

Each phase of risk assessment, V-Model shows identification and evaluation of risks at start and end respectively. First phase is about requirements mapping as we know risks are common in requirements phase. In [12], S. Li and S. Duo describe hazards caused by risks in software requirements in models and process.

A. Requirement Mapping

Using requirement mapping is one of the good ways to eliminate risks at initial level. But the most challenging task is to map requirements in right way. As we know, using case diagrams are considered to be the best way to map requirements in visual form. In [15], F. L. Siqueira and P. S. M. Silva propose to transform stakeholder requirements into software requirement to ensure requirement refinement. As we know, using case diagram is best way to map user requirement, so in first phase we propose to evaluate initial risks using use case diagram.

Second phase is about detail process analysis focuses to identify risks within processes that could be severe in future. Third phase is to identify the risk elements in list form based on possibility in phase two. Risk Prioritization [13] is one of modem ways of risk assessment in software development. X. Lin and D. Mingrong in [14] focuses to indexing of risks to gain more accuracy in risk assessment. In third phase, we assume to prioritize risks. Solving risk items is also a critical part of software development. Phase five focuses on difficulty of risk solution by means of risk occurrence probability. We can identify solution difficulty by applying weights.

In our strategy, we assume that if risks are highlighted in use case diagram it will be more convenient way to evaluate risk elements at requirement level. Fig 3 shows the use case diagram of sale process. In this figure, when buyer calls "do sale" process, other sub system or provider calls for validation of sub processes that are connected to sale process. This will help software engineers to visualize possibility of initial risks at requirement phase.

Phase six focuses towards use of matrices to be applied to measure risks. As described by X. Lin and D. Mingrong in [14], there are different methods to measure risks but accuracy is not possible from all of them. Therefore matrices must be

198

Fig. 2. Risk Assessment V-Model and its phases showing identification and evaluation of risks with risk tracking.

they can be understood by users, decision makers, engineers and parties involved in risk analysis.

B. Detail Process Analysis

In this phase, we do detailed analysis of business processes. As we know, the error occurs between process can lead to be failure of software project, therefore it is needed to identify risk elements within processes, so that they could be handled in future development. Sequence Diagram is considered to be best to visualize business processes.

We use "do sale" process sequence diagram for detail process analysis. Fig. 4 shows the sequence diagram of customer buying sale item. In this figure, we assume that those obstacles which can affect do sale process as risks. If we point out these threat points in sequence diagram, it could be helpful for developers and software engineers to deal with upcoming threats. In this figure, we use "TP" as threat point where there is a possibly of likelihood of occurrence. For example, threat point 3 refers to find an item in the stock. There is possibility of non estimated products in stock, out of date prices in stock, connection failure between prices API and stock database. These are some technical risks in sale process. Besides this, there are also performance risks like time taken in processing. As we know, there is internet connection involve for updating price between stocks and prices API. C. Risk Element Findings

In this phase, we identify risk aspects from threat points as we discussed in detail process analysis. For this purpose, we make checklist of the risks we find in sale process and other findings affecting process. Making risk checklist is one of modern ways to make assessments. C. Lopez and J. L. Salmeron [18] empathize on the risk strategies to reduce software risks. They gather data about risks in software projects based on average and make a checklist. They also focused on suitability of this strategy for managing each risk in effective way. M. Keil et al. in [19] also make investigation on different software projects, and they propose that risk checklist help to identify more risks than they would find without checklist strategy.

Fig. 3. Fig. 3: Use case Diagram of Sale Process

In [16], P. Luo and Yang Hu do analysis of system risk and identification using event based sequence diagram. A. Refsdal and K. Stolen also describes in [17] usefulness of sequence diagrams to make trust worthy risk analysis, because

199

Fig. 4.

Risk Assessment V-Model and its phases showing identification and evaluation of risks with risk tracking.

The general severity criteria for prioritizing risks are given in Table II.

The checklist given in Table I is a sample checklist for sale process. In this checklist, we also listed risk items related to performances, interfaces, compatibility measures as well as technical risks. We also mention some requirement mismatch risks compared to use case diagram in Fig 3. Because our model ensures traceability, also try to cover use case diagram risk points. TABLE T.

Rating

SAMPLE RISK CHECKLIST FOR SALE PROCESS Risk Checklist Sale Process risks check list

1

Non estimated products

2

Out of date prices

3

Authentication security

4

Connection availability

5

API response time

6

Process works as requirments

7

Failure to update stocks

8

Process works stable as requirements

9

Command failure

10

Vulnerability in process execution

RATING CRIETERlA FOR SEVERTY

TABLE II.

E.

Description

Severity of Effect

5

Critical

give customer loss

4

High

Function loss

3

Moderate

Overall performance degradation

2

Low

Reduced performance

1

None

Failure wouldn't noticeable

Risk Solution Difficulty

This section refers to effort required to avoid risks. Some risk are so twisted, they are difficult to fmd and solve because they occurred frequently. For example, in sale process, there are more chances of command failure due to high data transfer and internet communication which make system stress less. TABLE Ill.

Rating

RATING CRlTERAIA FROM PROABABILlY

Description

Probability Estimate

5

Almost certain

26%to 99%

D. Priortization ofRisks

4

Likely

II%t025%

Risks are prioritizing according to some defined criteria. In this section, we use severity scales for risk prioritization. Severity refers to the potential effect of failure over the process. Mostly rating scales are used for finding severity of risks. Risk severity is one of the modern ways to prioritize risk.

3

Occasionaly

6%to 10%

2

Unlikely

l%t05%

I

Seldom