Bin Fu, Student ID: c0275952, eMail: fubin@gmx.de, web: www.geocities.com/fubin_22527

University of Wolverhampton School of Computing and Information Technology

Assessment 1

Does the application of Risk management ensure systems quality?

Bin Fu C0275952 fubin@gmx.de Subject: MSc. Applied Computing Module: CP4019 Ensuring Systems Quality Module Leader: J.M.Roche Delivery date: 29.05.2003`1

Abstract

i

Abstract This paper intends to introduce the Boehm’s six basic steps of Software Risk Management (SRM), and argues if SRM ensures system quality. This paper begins with an introduction of software quality, software risk and Software Risk Management (SRM), and intends to reveal their relationships. The Boehm’s six basic steps for SRM are introduced by analyzing an application. There are weaknesses for SRM, and the third chapter compares the Spiral Model with the Agile Methodology in order to reveal SRM’s strength and weaknesses, as well as the schemes to improve its weaknesses. The last chapter summarizes what is discussed in this paper.

Index of Content

ii

Index of Content

1 INTRODUCTION OF SOFTWARE QUALITY, SOFTWARE RISK AND SOFTWARE RISK MANAGEMENT................................................................1

2 SIX BASIC STEPS OF SOFTWARE RISK MANAGEMENT ...................2

2.1 Identify Risk .....................................................................................................2

2.2 Analyze Risk.....................................................................................................2

2.3 Prioritize Risk...................................................................................................3

2.4 Plan Risk...........................................................................................................4

2.5 Trace Risk.........................................................................................................5

2.6 Resolve Risk......................................................................................................5

3 EVALUATION OF RISK MANAGEMENT FOR ENSURING SOFTWARE QUALITY .........................................................................................................6

3.1 Software Risk Management applied in the Spiral Model ............................6

3.2 Agile Methodology ...........................................................................................7

3.3 Spiral Model vs. Agile Methodology ..............................................................8

3.4 Suggestions to improve Software Risk Management ...................................8

SUMMARY ....................................................................................................10

REFERENCES ..............................................................................................11

Introduction of Software Quality, Software Risk and Software Risk Management

1

1 Introduction of Software Quality, Software Risk and Software Risk Management

What is Software Quality? The international Standard Quality Vocabulary (ISO 8402-1986) defines quality as: “The totality of features and characteristics of a product or service that bear on its ability to meet stated or implied needs.” (Sanders, J. et al, 1994, P.6) As software has become commercial product, software quality has been an important factor for software development. And in order to reach the requirements for ensuring quality, quality must be looked as the core of software production. You might ask, how to scale if it is a software product with good quality, on what does it depend? Certainly, there are criterions for good software. Darrel Ince’s (1995) defined 10 software quality factors, which are correctness, maintainability, portability, testability, usability, reliability, efficiency, integrity, reusability and interoperability. Obviously, Software Quality Assurance (SQA) is to ensure if these software quality factors are reached. What is Software Risk? Risk is defined in one dictionary as: ‘Hazard: chance of loss or injury’. (Taylor 2000, p.13). In a word, risk is loss of uncertainty, which means the possibility leading to loss is uncertain. We always have to face to the various different risks during software development, e.g. user requirements have to be changed, wrong plan and budget, inexperienced management etc. Obviously, these uncertain risk factors negatively influence software quality. There are different risks for software development, e.g. area risk, schedule risk, budget risk, technique risk, law risk, personnel risk, etc. Definitely, in case that these risks happen, cost and delivery time, as well as software quality will be negatively influenced. Halle (1998) defines software risk in other words: software risk is any factors that damage or negatively influence advanced plan and software quality. What is Software Risk Management? The appearance of Software Risk Management (SRM) brought a new software lifecycle process at the end of 80’s i.e. spiral model (Boehm, 1989) that is base on observation and analysis to the uncertain factors of software development, and is a methodology constituted to identify, analyze, trace and then finally resolve risk. Main task of SRM is to prevent software project from suffering various risks, but not every risk can absolutely be prevented because risk occurrence is uncertain, and sometimes it cannot be exactly predicted by human thinking. Therefore, SRM is planed in advance by experience and common sense of human, and then furthest restricts loss of risk in case of its occurrence. Now that software quality is strongly influenced by software risks and software risks can be restrained by SRM, does SRM ensure software quality then? To answer this question, we start with the Boehm’s six basic steps for SRM.

Six Basic Steps of Software Risk Management

2

2 Six Basic Steps of Software Risk Management A proper way of Software Risk Management (SRM) can ensure software quality. The destination of SRM is to identify, specify and finally remove any kind of risks before it happens so that the possibility of re-implementing software can be taken to the least. Boehm (1989) sums up six basic steps for SRM including the risk assessment steps, i.e. risk identification, risk analysis and risk prioritization, risk control steps, i.e. risk planning, risk monitoring and risk resolution.

2.1 Identify Risk Identifying risk is to systematically identify known and unknown but predictable risks, and to clearly list them on the paper. According to different risk contents, risk can be divided into following sorts:

• Size risk: risk concerns estimate of software size. • Commercial risk: influences the viability of software development. It includes

market risk, strategy risk, distribution risk, management risk and budget risk. • Customer character risk: concerns customer character and communication

between the developers and the customer. • Process risk: the risk concerns software development process. • Development environment risk: the risk concerns usability and quality of the

developing tool. • Technique risk: the risk concerns design, implementation, interface, validation,

and maintenance during software development. Technique risk threatens software quality and delivery date. If technique risk happens, software development will become very difficult even be impossible to implement.

• Personnel risk: concerns general technical level and the experience of developing team.

(Wen 2002) After possible risks concerning of progress are identified, they need be analyzed in the next step.

2.2 Analyze Risk The most important thing for risk analysis is to quantify the degree of the uncertainty and degree of loss when each risk happens. Risk analysis is to evaluate probability and consequence of the risk, so that risk priority can be assessed. In order to quantify the risks, there are three factors should be considered:

• Risk probability • Risk consequence • Risk controllability

Following a method of risk analysis will be introduced, i.e. Risk Exposure (RE). Risk can be seen as a kind of loss, therefore, the value of RE is defined as the product of risk probability times its corresponding loss, e.g. if the probability of 5 weeks delay is 40%, then RE = 5 week * 40% = 2 week. Because we only discuss progress risk, all the quantified values can be described with time. Figure 2 evaluates RE of the risks concerning progress. (Mo, 2002)

Six Basic Steps of Software Risk Management

3

Figure 1: Evaluation of RE for progress risks (Mo, 2002) In Figure 1, the value of general loss need be evaluated. Because RE for the whole project is not easy to be evaluated, it is divided according to different kind of risks and then RE is individually evaluated. The sum of all the individual RE are general RE for the whole project, value of 5.0 as sum of RE is evaluated in Figure 1. The value RE shows the predicted delay time. If the planned duration for this project is 10 weeks, and RE is evaluated as 5.0 weeks, then it is very necessary to thoroughly do SRM for removing progress risks.

2.3 Prioritize Risk After a RE table is established, according to the different value of RE they can be prioritized, so that pivot of SRM can be made clear, i.e. too many efforts on the inessential things are not necessary. It is easy to sort risk ascending in Figure 1 according to value of RE, then Figure 2 is got.

Figure 2: Evaluation of RE for progress risks after prioritization (Mo, 2002) Now it is known how important each risk item is for progress of RIS project. After prioritization, it is clear which risk should be invested more efforts to manage, and which risk should be invested less efforts to manage. We can see in Figure 2, if we emphasize to spend more effort for the first four risks, the value of RE can be decreased. Because of the cost of risk management, normally more efforts are spent on managing the risks that have high prioritization. But for some risk, whose occurring probability is few, but in case that it occurs, it will be fatal to a software project, so these risks must be noticed as well. All the values of RE are estimated, therefore, to get the prioritization of RE must be very carefully evaluated in order to make it close to the fact.

Risk Probability Loss (Week) RE (Week) Planning Risk 30% 4 1.2 Design Risk 10% 8 0.8

Requirement Risk 20% 10 2.0 Technique Risk 10% 5 0.5 Personnel Risk 5% 6 0.3 Customer Risk 2% 5 0.1 Facility Risk 5% 2 0.1

Sum 5.0

Risk Probability Loss RE Requirement Risk 20% 10 2.0

Planning Risk 30% 4 1.2 Design Risk 10% 8 0.8

Technique Risk 10% 5 0.5 Personnel Risk 5% 6 0.3 Customer Risk 2% 5 0.1 Facility Risk 5% 2 0.1

5.0

Six Basic Steps of Software Risk Management

4

After all risks that probably happens during software development are assessed, risk control is the way to mostly restrain consequence of the risk, which includes risk planning, risk monitoring and risk resolving.

2.4 Plan Risk Planning risk is to describe, define and plan the strategy for managing the risks that has higher prioritizations after prioritization of RE is sorted, e.g. consequence of risk happening, time, reason etc. For each of these risk items, these questions should be asked:

• Why? Risk item’s importance and influence to project objective. • What, when? What to do at a specific time. • Who, Where? Responsible person and department. • How? The way for resolution. • How much? Budget, schedule and so on. (Boehm, 1989)

We pick Requirement Risk in the risk item list, and make a risk plan as example: Requirement Risk Objectives (why?) Requirement influences final purpose of the software project. Deliverables and Milestones (what, when?) By week 3:

1) Evaluate what will be got following the current design 2) Meeting with customer to check if it is what they exactly want. 3) Analyze current difficulties to reach the requirements

By week 9: 4) Evaluate what will be got following the current implementation 5) Meeting with customer to check if it is what they exactly want.

Responsibility (who, where?) • System engineer: task 1 • Project Leader: task 2, 5 • All developers: task 3, 4

Way (how?) • Using software engineering tools e.g. Together • Meeting and discussion

Budget, Schedule (how much?) 1) 4 Person * 1 Day * 200 $ / (Person*Day) = 800 $ 2) 1 Person * 0.5 Day * 300 $ / (Person*Day) = 150 $ 3) 6 Person * 0.5 Day * 200 $ / (Person*Day) = 400 $ 4) 6 Person * 0.5 Day * 200 $ / (Person*Day) = 400 $ 5) 1 Person * 0.5 Day * 300 $ / (Person*Day) = 150 $

others = 100 $ SUM = 2,000 $

Figure 3: Risk plan for requirement risk of RIS project (Boehm, 1989)

Six Basic Steps of Software Risk Management

5

In Figure 3, you do not need to care what the exact content and amount in this example, but you must always ask yourself these questions while you are doing risk planning i.e. why, what, when, who, where, how and how much?

2.5 Trace Risk After risk management is planned, although risks still exist, it has already been controllable. Because the influence of risks would change during project development, the risks must be traced. Firstly, risk monitoring can predict risk consequence so that developers have preparation to solve it. Secondly, the list of risk can be updated by tracing, because new risk could come up and risk prioritization could also change. The most efforts should thrown to the risks that have higher prioritizations instead of all of them in order to reduce work load and cost. e.g. just take the first five risk items according to value of prioritization. After each stage of software lifecycle finishes e.g. requirements analysis, design etc, the risk checklist should be checked. Remember: risk plan and risk checklist should be periodically updated, and how often depends on duration of each stage the project. (Boehm, 1989)

2.6 Resolve Risk Before risks come up, there always should be resolution prepared. Two things need be done: (Mo, 2002)

• Decrease probability of risk happening, e.g. in order to avoid pivotal developer quitting, relevant allowance should be released.

• Decrease loss in case of risk occurrence, e.g. in order to decrease loss in case of pivotal developer quitting, the development team should offer more training for the developers and should often hold meeting for exchanging project information among developers.

Mo (2002) also suggests some ways to avoid the occurrence of risks,

• Do not do anything you are not familiar with. • Efficiently modulate each part of project, i.e. keep good communication

among developers. • Remove source of risk, e.g. re-write the code of problematic module as early

as possible. • Publish risks before happens, make each involved development member notice

all kinds risk as well as their possible consequences. These are Boehm’s (1989) six basic steps for SRM. As said, SRM is not omnipotent, because risk occurrence is uncertain, not all the risks can be estimated and predicted. In addition, SRM need experienced risk manager and costs a lot, these aspects of SRM will be detailed evaluated in the next chapter.

Evaluation of Risk Management for Ensuring Software Quality

6

3 Evaluation of Risk Management for Ensuring Software Quality

Our topic is if software risk management (SRM) can ensure software quality? Or it needs some other help from the other methods. In this chapter, the Spiral Model with SRM and the Agile Methodology will be introduced, and with the comparisons we will try to find weaknesses and strength of SRM, and also suggest the ways to remove the weaknesses of SRM.

3.1 Software Risk Management applied in the Spiral Model

Boehm (1989, p.26) notes that “This evolving risk-driven approach provides a new framework for guiding the software process”. This approach is the spiral model, whose process is shown in Figure 4.

Figure 4: Spiral model of the software process (Boehm 1989, p. 39) As shown in Figure 4, the Spiral Model executes strict SRM before each stage begins i.e. risk identification, risk analysis and risk control. Until it is ensured that risk is controllable, the next stage can start, otherwise, project is not allowed to continue. The author of this paper summarizes the advantages and disadvantage of SRM described as following:

Evaluation of Risk Management for Ensuring Software Quality

7

Advantages: • A strict risk management throughout software development, so the

possibilities of risks occurrence are mostly restricted. • A strict criterion for software quality in each development stage to ensure the

final quality. Disadvantages:

• SRM requires experienced risk manager. • High cost and a lot of time consumption for SRM. • No software measurements during the whole process. • Not suitable to apply for small projects with limited budget

We can find that the Spiral Model with SRM can ensure software quality because it requires strict quality verification in each development stage. But it is difficult to develop software on time and under budget with SRM, because SRM costs a lot and does not provide software measurement metrics to estimate software size and budget.

3.2 Agile Methodology Lin (2002) notes that there are two extremes existing in the software development.

• There is no or very little cost for project management, and all efforts are for producing software. This always leads to producing a low-quality software product.

• There are a lot of management activities during software development e.g. verification, validation, defect monitor etc. It can make software development more orderly, but will increase software cost as well. This decreases effectiveness and creativity of the development team. In some way, SRM is more like this extreme.

Agile Methodology is an eclectic methodology between both above extremes, and tries to find a balance point to develop high quality software with low cost. It has following advantages:

• Keep simple: keep the prototype as simple as possible • Allow change: project always can be changed during development, e.g.

personnel, requirements etc. Agile model allows project change. • Gradual improvement: project is gradually improved, as all needed

requirements are implemented one by one to the model. • Effective investment: stakeholder can choose the best way to invest for a

software project. • Purposefully establish model: before a model is established, it should be clear

what the purpose is. • Few documents. ( Fowler, 2002)

Agile Methodology has also disadvantages that it is not suggested to apply for software project with large size. Because development team needs a very good communication and flexible working principle for applying the Agile Methodology, it

Evaluation of Risk Management for Ensuring Software Quality

8

is obviously not suitable for a development team with more than 10 people. (Lin, 2002)

3.3 Spiral Model vs. Agile Methodology Figure 5 lists differences between the Spiral Model and the Agile Methodology.

Process Model Advantages Disadvantages Spiral Model • A strict risk management

• Strict criterion for software quality

• Experienced risk manager. • High cost and a lot of time

consumption for SRM. • No software measurements • Only suitable for large

projects Agile

Methodology • Simple • Allow change • Gradual improvement • Effective investment • Purposefully establish model • Few documents

• Only suitable for small projects

Figure 5: difference between the spiral model and the Agile Methodology From the table in Figure 5, we can see that generally the spiral model cost more and spend longer to develop software with a high quality, therefore it is not suitable to those projects with small size and limited budget. Agile methodology is a flexible and an effective way to solve project over schedule and over budget, it somehow offsets the weaknesses of SRM. But it is only suitable to those projects with small size.

3.4 Suggestions to improve Software Risk Management Both of the Spiral Model (SM) and the Agile Methodology (AM) have their own features, can their strength and weaknesses offset with each other? Suggestion 1: flexibly using other processes with risk management For SRM in spiral model, in order to decrease cost for SRM, only if it is ensured that all risks are controllable, strict SRM can be ignored in the remaining stages of lifecycle, the other suitable lifecycle modes can also be used, e.g. the Agile Methodology. Therefore, it is a good way to use the Agile Methodology in the Spiral Model after risks are ensured in order to decrease cost and time consumption. Suggestion 2: using software measurement with risk management Obviously, SRM does not provide software measurement. Software measurement helps software developer quantify software size by using some measurement metrics e.g. Source Line of Code (SLOC), Function Point (FP) etc. (Different measurement metrics depends on different measurement methods). It makes more accurate

Evaluation of Risk Management for Ensuring Software Quality

9

estimate of software size and budget, so that it help software risk management ensure software quality. Some measurement methods are suggested e.g. Cosmic (Roche, 2003), CoCoMo II (Roche, 2003a). Generally, SRM can ensure software quality, but it costs too much. The Agile Methodology is suggested to help SRM decrease development cost, but we cannot apply SRM directly in the Agile Methodology, because SRM and the Agile Methodology has different principles i.e. SRM requires predictability but the Agile Methodology requires adjustability. SRM is static development but the Agile Methodology is dynamic development. In addition, some software measurement methods are also suggested to help SRM estimate software size more accurately, so that software quality can further ensured.

Summary

10

Summary Risk is loss of uncertainty, which means the possibility leading to loss is uncertain. Software development is a process full of risks and uncertainties e.g. user requirements changed, wrong plan and budget underestimated, inexperienced management etc. These risk factors will lead to delivery delay and overspending, which always damage software quality. Software Risk Management (SRM) is base on observation and analysis to the uncertain factors of software development. Boehm (1989) sums up six basic steps for SRM including risk assessment and risk control. Risk Assessment includes three steps:

• Risk identification: finds out the risk factor influencing success of the project. • Risk analysis: checks probability of each risk factor occurrence and possibility

to decrease probability of risk occurrence • Risk prioritization: ensures and analyzes all kinds of risk factors and sorts

them with specific priority. Risk Control includes another three steps:

• Risk planning: plans the ways to solve risks. • Risk monitoring: traces the influence and the trend of the risks. • Risk resolution: removes and resolves the risks in each stage.

The appearance of SRM generated the Spiral Model, and by comparing the Spiral Model with the Agile Methodology, following conclusions can be got:

• Spiral model imports strict SRM so it mostly ensures software quality. But strict SRM increases cost and consumes time, and it also requires sophisticated development experiences. Therefore, spiral model is suitable for those large-scale project which requests high quality.

• Agile methodology is a new way to develop software project that advocates flexibility and efficiency. It is suitable for developing small-scale project e.g. project team less than 10 people, and it is impossible to use SRM in agile methodology because agile methodology emphasizes adaptability and flexibility but not predictability.

• SRM of spiral model can be flexibly used, e.g. when risk is definitely known and controllable, SRM can be ignored in the remaining stages, then some other models can be supplied to spiral model e.g. agile methodology, so that high cost and time consumption of SRM can be decreased.

• Software measurement methods are suggested to use with SRM e.g. CoCoMo II, Cosmic, so that an accurate estimate of software size and software budget can be got and further improve software quality.

Generally, SRM can ensure system quality, but it costs too much and consumes too much time, therefore it needs help of some other software techniques e.g. the Agile Methodology, CoCoMo II, etc.

References

11

References BOEHM, B. (1989) Software Risk Management, New York: IEEE Computer Society Press. FOWLER, M (2002) The New Methodology, (updated June 2002, accessed 19 March 2003). HALL, E. (1998) Managing Risk: Methods for Software Systems Development, California: Addison Wesley Longman, Inc. INCE, D. (1995) Software Quality Assurance – A Student Introduction, Cambridge: McGRAW-HILL Book Company Europe. LIN, X. (2002) Agile Thinking – Methodology in Architecture Design, China: IBM Corp. < http://www-900.ibm.com/developerWorks/cn/linux/software_engineering/Methodology/part1/index.shtml> (accessed 19 March 2003). MO, X. (2002) Risk management for software projects process. Computer and Information Technologies 4, pp.67-70. PFLEEGER, S (2001) Software Engineering Theory and Practice Second Edition, USA: Prentice-Hall, Inc. ROCHE, J.M. (2003) The Importance of the Size of Software Requirements, CP4019 Ensuring Systems Quality, Week 4, University of Wolverhampton. ROCHE, J.M. (2003a) An Overview of the COCOMO 2.0 Software Cost Model, CP4019 Ensuring Systems Quality, Week 3, University of Wolverhampton. SANDERS, J. et al (1994) Software Quality – A Framework for Success in Software Development and Support, Addison-Wesley Publishing Company. TAYLOR, M (2000) Avoiding Claims in Building Design -- Risk Management in Practice Cambridge: The University Press, Cambridge. WEN, Y. (2002) Software projects risk management. Applications of the Computer System pp.32-34.