a framework for software product risk management based on quality ...

A FRAMEWORK FOR SOFTWARE PRODUCT RISK MANAGEMENT BASED ON QUALITY ATTRIBUTES AND OPERATIONAL LIFE CYCLE (SPRMQ) HALIMA M. MOFLEH AND AMMAR ZAHARY

The Arab Academy for Financial and Banking Sciences, Sana'a Branch Department of Computer Information Systems E-mails: [email protected], [email protected] ABSTRACT This paper presents our framework that tries to improve software product risk management by applying some sequential processes during operational life cycle of the product. The framework is called SPRMQ (a framework for Software Product Risk Management based on Quality attributes and operational life cycle) which attempts to manage software product risk. SPRMQ consists of four processes used to manage risk of software product: identifying risk factors, analyzing risk probabilities and its effects on product quality, risk mitigation, and risk monitoring. SPRMQ uses brainstorming to identify risk factors and probability/impact approach with some modifications to analyze risk based on quality attributes: Functionality, Reliability, Performance, Efficiency, and Maintainability. To mitigate risk, SPRMQ uses three strategies: avoidance, minimization, and contingency. If risk cannot be acceptable SPRMQ framework uses avoidance strategy. If risk can be acceptable and can be reduced, SPRMQ uses minimization strategy, but if risk cannot be reduced, SPRMQ uses contingency strategy. SPRMQ framework is applied to Admission and Registration System (ARS) of University of Science and Technology (UST). Testing results show that using SPRMQ, project/risk manager can effectively manage a software product by measuring the impact of risks that may happen in three risk levels: high, medium, or low. Keywords: Software Product Risk Management (SPRMQ), Risk Probabilities, Identifying Risk Factors, Risk Mitigation, Software Product Quality, Risk Monitoring, Mitigation Strategies.

I. INTRODUCTION Software development project is often plagued with unanticipated problems which cause the project to miss deadlines, exceed budgets, and/or deliver products with less quality [1]. Therefore, the software industry is a high-risk business with increasing software complexity and growing demand for large-scaled and faster product with better performance. When the risk is not managed well by the project team, the project may be left vulnerable to factors that can cause major rework, major cost, schedule over-runs, and/or complete project failure. Applying software risk management processes has become an essential step to effectively manage software during its development maintenance lifecycle [2]. Risk in software products can be defined in general as the probability of suffering loss while pursuing goals due to unpredictable factors [1]. Software risk management is an essential concept in project management. When the product is being developed, there are many expected risks that may affect the project schedule, resources, or quality of the product [3]. There are three types of risk addressed in literatures. First type is "Business Risk" which affects organization developing or procuring software due to insufficient budget or less support by top management. Second type is "Project Risk" which affects project schedule or resources. A simple example of a project risk is the schedule risk by which all things should be considered. The Project Manager (PM) should keep a watchful eye on such risk. PM regularly judges the progress, forecasts schedule risk, and initiates proper actions to overcome this risk. Third type is "Product Risk" which affects

quality or performance of the software being developed [1][3]. Risk factor is an event or a situation that increases the occurrence possibility of a risk incident. Risk factor should always be given in the context of a risk incident and it is referred to as the risk factor of the risk incident [4]. Risk management is the set of activities used to manage risks. Risk management usually consists of four basic processes: Risk Identification, Risk Analysis, Risk Planning/Mitigation, and finally Risk Monitoring and Controlling [3]. Many software products fail to deliver an acceptable quality and performance during the operational life cycle of the product. Most approaches of software product risk management emphasize only on risks that may happen during project development life cycle regardless the operational life risks. In addition, there is a lack in frameworks that can manage software product risk based on quality attributes such as Functionality, Reliability, Performance, Efficiency, and Maintainability [5][6][7][8]. This paper conducts our framework that called Software Product Risk Management based on Quality attributes (SPRMQ) and operational life cycle of the product. Our framework tries to improve software product risk management by applying four sequential processes during operational life cycle of the product. These processes are identifying risk factors, analyzing risk probabilities and effects on the product quality, risk mitigation, and risk monitoring. To identify risk factors, SPRMQ framework uses brainstorming technique. To analyze risk, SPRMQ framework uses probability/impact approaches with

some modifications that concern in the five quality attributes mentioned above. To mitigate a risk, SPRMQ framework uses one of three strategies: Avoidance Strategy, Minimization Strategy, or Contingency Strategy [3]. If the risk cannot be acceptable, SPRMQ framework uses avoidance strategy. If the risk can be acceptable and can be reduced at the same time, SPRMQ uses minimization strategy. If the risk can be acceptable but cannot be reduced, SPRMQ uses contingency strategy. To monitor a risk, SPRMQ framework introduces some processes which will be shown later in section 3. SPRMQ framework is applied to Admission and Registration System (ARS) of University of Science and Technology (UST). To mange a software product, testing results show that, using SPRMQ framework, a project or risk manager can effectively measure the impact of risks on the software product's operational life cycle in three risk levels: high, medium, and low using SPRMQ processes and strategies depend on quality attributes.

approach. In order to identify risks in the process of software project development, the risk identification process utilizes GA to search the rules of risk identification based on historical data of the software project. As shown by related work, the existing frameworks mainly emphasize on the risks that may happen during project development life cycle regardless the operational life. This means these frameworks essentially focus on the process risks. In literatures, there is a lack in frameworks that are basically developed to manage software product risk. Through our search in several literatures related to software product risk management, it was difficult to find out a standard framework for managing and analyzing software product risk, or a framework that could analyze risk from qualitative perspective. In addition, there is a lack in frameworks that are basically developed to analyze product risk depending on the characteristics/attributes of quality which are mentioned early in this paper: Functionality, Reliability, Performance, Efficiency, and Maintainability.

2. RELATED WORK

3. SPRMQ FRAMEWORK

There are many literatures present several existing frameworks used to manage software project risk. Most of these frameworks usually define the most common processes to manage a risk between two and seven processes which is different from a framework to another. From our perspective, these processes can be four processes at least to guarantee a satisfactory risk management for a software product. These processes are identifying risk factors, analyzing risk probabilities and effects on the product quality, risk mitigation, and risk monitoring [9][10][11][12]. Some related approaches will be presented briefly in the following paragraphs. Authors in [9] defined two basic processes to manage software product risk. The first and primary step is risk assessment which involves risk identification, risk analysis, and risk prioritization. The second step is risk control which involves planning of risk management, risk resolution, and risk monitoring. In [10], author presented seven sequential steps to manage software product risk. These steps are: identifying risk factors, assessing risk probabilities and its effects on the project, developing strategies to mitigate the identified risks, monitoring risk factors, invoking a contingency plan, manage the crisis, and recovering from a crisis. IEEE-SA standard for software life cycle processesrisk management [13] introduced six processes to manage risk. These processes are: plan and implement risk management, manage project risk profile, perform risk analysis, perform risk monitoring, perform risk treatment, and evaluate risk management process. In [14], author introduced a management framework called ProRisk to manage software product risk. ProRisk is built on hierarchical model structure along with the lines and quires of the following activities: stakeholder identification, risk factor identification, calibrating the model, estimating risk event probabilities, computing combined risk values, developing action plans, and monitoring progress. In [15], a software project risk identification process has been developed based on Genetic Algorithms (GA)

This paper tries to overcome the shortcomings of the existing frameworks of software risk management by conducting our framework SPRMQ that attempts to improve software product risk management by applying four sequential processes depending on quality attributes and during operational life cycle of the product. SPRMQ framework consists of four processes applied sequentially to manage software product risk. The four processes are identifying risk factors, analyzing risk probabilities and effects on product quality, developing a strategy to mitigate risk, and finally risk monitoring. SPRMQ framework is developed basically depending on the five characteristics/attributes of software product quality: Functionality, Reliability, Performance, Efficiency, and Maintainability. This section presents the mechanism and processes of SPRMQ framework as shown by Figure 1. Identify Risk Factors

Analyze risk probabilities and effects on the product quality

Risk Mitigation

Risk Monitoring Figure 1: SPRMQ framework mechanism and processes

A.

Identifying risk factors This process aims to identify all possible risks of a software product, especially the risk that may affect quality of the product. There are many techniques can be used to identify risk factors. These techniques are Brainstorming, Delphi, Checklist, Time a fact-finding, and Diagrams technique [5]. In this paper, we use brainstorming technique to identify product risk factors. Brainstorming technique is a technique by which a

group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously without judgment [5]. Stakeholders perform brainstorming session Generate all risk factors Document all risk factors Generate solution for risks Document all suggested solution Figure 2: Brainstorming session activities

List of risks

List of suggested solution

Risk1: Risk2: Risk3: Risk4: Risk5:

Figure 3: Risk identification document

The main advantages of brainstorming technique can be summarized as short duration, prompt effects, flexible scope of detail, and keeping product users concerned about risk [5] [11]. To identify risk factors, stakeholders group (all people who are related to the product being developed) attempts to identify all possible risk factors that may affect the software product. Also, stakeholders should find a solution for each risk effect [3]. Figure 2 illustrates brainstorming session activities. All risk factors that are generated in a brainstorming session and the corresponding solutions should be documented. Figure 3 illustrates an example of a brainstorming session document. B. Analyzing risk probabilities/effects on product quality SPRMQ framework analyzes risk probabilities and effects on product quality from qualitative perspective. SPRMQ framework uses probability/impact approach to analyze risk taking into account the main five attributes of software product quality: Functionality, Reliability, Safety, Performance, and Maintainability. Functionality attribute reflects the degree to which the software satisfies customer needs as indicated by attributes such as suitability, accuracy, security, and compliance. Reliability attribute reflects the ability of the system to deliver services as specified by the customer. Safety attribute reflects the ability of a system to operate without threats to users or work environment. Performance attribute reflects the speedy and responsiveness of the system. Maintainability attribute reflects the ease of system repairing after discovering a

failure or changing the system to add new features [3][5][11]. As shown by Table1,an example of probability/impact approach lists probability and impact of each risk on the corresponding quality attribute. The probability can be very low, low, moderate, high, or very high. Each risk is labelled as being high, medium, or low in terms of its probability. Table 1. The modified probability/ impact approach Quality Attribute

Risk

Probability

Impact

Functionality

Risk 5

Low

High

Reliability

Risk 4

High

Medium

Safety

High

Low

Performance

Risk 3 Risk 1

Low

High

Maintainability

Risk 2

Low

Medium

C. Risk Mitigation After using various risk identification techniques, risk manager needs to consider each risk and develop a strategy to manage that risk. Figure 4 shows different strategies for risk mitigation. To mitigate risks, risk manager needs to decide which strategy should be used. There are three strategies that are usually used to mitigate a risk: Avoidance strategy which means reducing the probability of the risk occurrence, Minimization strategy which means reducing the impact of the risk, and Contingency plans which means the user is prepared for the worst and has a strategy in place to deal with it [3]. Table 2. Example of risk mitigation document Quality Attribute

Risk

Prob.

Impact

Mitigation Strategy

Functionality Reliability Safety Performance Maintainability

Risk 1 Risk 4 Risk 3 Risk 5 Risk 2

Low High High Low Low

High Medium Low High Medium

Avoidance Contingency Avoidance Minimization Contingency

Figure 4 illustrates how the risk manager can choose the strategy to deal with the risk. If the risk is too big for the manager to be willing to accept, he/she can avoid the risk by changing requirements, specifications, or practices. Also, the manager can deal with the risk by changing the product strategies and tactics to choose a less risky alternate or may decide not to produce this product at all. If he/she decided to attack the risk directly, the manager typically starts with creating a list of possible risk reduction actions that can be taken for the risk (Minimization Strategy). Two major types of risk reduction actions should be considered by the risk manager. Firstly, the actions those reduce the likelihood of the risk to occur. Secondly, the actions those reduce the impact of the risk that will likely occur. If the immediate actions of risk reduction are not taken into account or if those actions can reduce but cannot eliminate the risk, it may be appropriate to develop risk contingency plans [2]. Contingency plan is defined as the predefined actions the project team will take if an identified risk event occurs [5]. Typically, contingency plans are

treated as passive documents. They are waiting for some problem to occur before taking the action. An important point for contingency plan is that it may contain some active contingencies [4]. This can happen when the risk manager is proactive so that he/she executes an active contingency before the anticipated problem even occurs. After choosing strategy, risk manager needs to document this process. Table 2 illustrates an example of mitigation strategy document. Begin

Risks

Avoidance Strategy

No

Yes

Choose other alternatives

Yes

Accept

risk? Yes

Have alternative ?

Can reduce risk?

Yes

Minimization Strategy

No No Change goals

Contingency plan

End

D. Risk monitoring The risk monitoring process is a continuous process so that it can continuously monitor status of the product and status of the risk management processes. It provides information that can assist in identifying the new risks. Risk monitoring process is activated after identify risk factors, analyzing probability and impact of them, and developing a strategy to deal with them. To monitor risk, SPRMQ framework introduces some processes for the risk manger as the following steps: • Make "testing copy" of the product. • Give the "testing copy" to users and take feedback from them. • Assess each identified risks regularly to decide whether or not it is becoming less or more probable. • Assess whether the effects of the risk have changed. • Assess whether the strategy to mitigate risk useful. Feedback

Assess strategy

Document results

Figure 5: Risk monitoring process

Table 3. Example of risk monitoring document Quality Attribute Function ality Reliabilit y Safety Performa nce Maintain ability

Risk

Prob.

Impact

Mitigation Strategy

Risk Status

Risk 1

Low

High

Avoidance

Useful

Risk 3

High

Medium

Contingency

Not useful

Risk 4

High

Low

Minimization

Useful

Risk 5

Low

High

Avoidance

Useful

Risk 2

low

Medium

Contingency

Useful

4. FEATURES AND PROCESSES OF AN EXISTING SYSTEM This section presents features and core processes of an existing system in order to apply SPRMQ framework to this system in the next section. This system is Administration and Registration System (ARS) which is a part of University of Science and Technology (UST) software system [16].

4.1 ARS FEATURES

Figure 4: Strategies of risk mitigation

Testing copy of the product

• Document the result of the monitoring. Figure 5 illustrates an example of risk monitoring process document. Then, the document is submitted to the stakeholders group and it must be like the document shown in Table 3.

Assess each identified risk

Assess effect of the risk

The Admission and Registration Department at UST uses ARS to achieve its tasks. ARS at UST [16] allows user to accept a new student to one of the university programs. Student delivers his/her documents to the admission officer that checks the requirements fulfilment for the selected department, as the number of registered students who registered in this semester and if the department is available. For each department selected in the "add new enrolment operation", the number of enrolled students will automatically increase by one. Student fills in an application form and returns this form to the admission office. User enters student information to the system by a unique identification number for each student. Student information is the name, nationality, sex, and grade of higher school. The admission officer gives the student a student guide, an acceptance offer letter, and a receipt for student file. ARS allows user to enrol the accepted student by changing the student mode from under request to an acceptable student. Then, the system gives student an ID card. Then, the system user sends student information to the archive, accounting department, student affairs, and any other concerned body. ARS enables user to link a student with a program study plan by taking it from the related college deanship which the required department belongs to. The program study plan is displayed based on the department information. ARS enables user to add a new instructor to the university. User saves the instructor information such as instructor name, telephone number, certification, and an address to the instructor database of the system. After the operation of add new instructor is completed, the system gives a unique employment number to the instructor. The instructor determines the class section that he/she is going to teach for the next

semester. An instructor gives his/her selected class section to the registrar. The user of the system adds the instructor number to the class section information in the class section database. Then, the user checks instructor information. The instructor schedule is printed indicating which class section the instructor will teach for the next semester. After the initial enrolment period is completed, the instructor sends a request to provide his/her students' roster for each class section from the registrar. The system checks information of the instructor, department, and level. The system prints the list of students' names to the teacher. ARS allows user to delete an instructor record if the instructor applied a request to finish his/her contract. The system checks the instructor information before it deletes the instructor record. ARS also allows user to add a class section. Each department in the university sends information about all class sections that will be studied in the next semester. The information of class sections are class section number, course number, class section number, day, time, an instructor number, and number of enrolled. Then, the system saves the class section information in the class section database. The instructor can update teaching information and modify class section. He/she sends a request for this subject to the system which checks the information and then deletes the instructor number from the old class section record. After that, the system adds the instructor number to the new class section record. The registrar receives student marks at the end of each semester from the control office of examinations. The system checks that courses are found. The users of the ARS enter the marks into the database, and then the marks are checked for accuracy. After that, the marks are checked again to confirm. Finally, marks are advertised to students. ARS allows the head of a department to send information in order to delete/add a department course. The system checks information of department and courses, such as if the course is available in the database or not. The system deletes/adds the course record from/to the course database. ARS also allows the college deanship to send information of a new department to the registrar. The system checks the class sections from the class sections database. Then, the users of the system can enter the department information to the database, such as department number and name. A. Core processes of ARS In this part, we summarize the core processes of ARS at UST in twelve core processes with a short description of each process. • Add new student to the university 1. Student delivers the required documents to the admission officer. 2. Student fills in an application form and returns it to the admission officer. 3. Admission officer checks the fulfilment of the requirements for the selected department. 4. Admission officer enters student information to database.

5. 6.

System adds number of enrolled student which is automatically increased by one for each selected department. System produces for the student an acceptance offer letter and receipt for student file.

• Add new enrollment for an acceptable student 1. System checks if the student has an acceptance. 2. System changes the student mode from under request to acceptable mode. 3. System produces the ID card of the student. 4. Admission officer sends student information to the archive, accounting department, students' affairs, and any other concerned body. • Add new program study plan 1. College deanship sends information to the admission officer to add a new program study plan. 2. Admission officer enters the program study plan information to the database. 3. The program study plan is displayed to student. • Add new results (marks) for a student 1. System receives student marks from the control office of examinations. 2. System checks if the courses are found. 3. User enters the marks into the database. 4. User checks the marks that have been entered. 5. User checks again for the marks to ensure the correctness of entered marks. 6. Marks are finally advertised to student. • Delete /Add course to a program study plan 1. Head of the dept sends the course to be deleted or added. 2. System checks the course, department, level, course semester, and course type. 3. User deletes/adds the record of the course from/to the course database. • Add new department 1. College leadership sends a request to add information of new department. 2. System checks if the department is available in the department database. 3. User enters the department information to the database. • Add a new class section 1. Each department in the university sends information of all class sections that will be studied in the next semester. 2. System saves the class sections information in the database. 3. User saves the information of class sections, such as class section number, course number, classroom number, day, time, instructor number, and number of enrolled students. • Display student roster for instructor 1. Instructor sends a request to provide him/her with student roster for each selected class section. 2. System checks information of the instructor, students, program study plan, and class sections from the database.

3.

System prints student rosters for each class section and then they are submitted to the corresponding instructor.

• Add new instructor to the university 1. Instructor delivers his/her information to the registrar. 2. Registrar enters instructor information to the database. • Delete instructor from the university 1. Instructor applies a request to finish his/her contract in the university. 2. System checks the instructor information in the database. - System deletes the instructor record from the database. • Add new teaching information for instructor 1. Instructor sends his/her all class sections. 2. System checks the instructor information. 3. System adds the instructor number to class section record. • Update teaching information for instructor 1. Instructor sends a request to update teaching information and modify class section. 2. System checks the instructor information. 3. System deletes the instructor number from the old class section record. 4. System adds the instructor number to the new class section record.

5. APPLYING SPRMQ FRAMEWORK TO ARS In this section, the four processes of SPRMQ framework are applied to ARS. The processes are identifying risk factors, analyzing risk probabilities and effects on product quality, risk mitigation, and risk monitoring. A. Identifying risk factors From our interviews with stakeholders of UST, they have attempted to identify all possible risks that may affect ARS, and they have generated the ideas to find solutions for those risk factors. These factors can be summarized as follows: Risk factor 1: Inability to add new student. Risk factor 2: Inability to get result when search on some students. Risk factor 3: Slow speed of getting results when search on student information. Risk factor 4: Inability to display the program study plan to student. Risk factor 5: Inability to add new results (marks) of student. Risk factor 6: Unauthorized access database to browse the results (marks) or change marks of student. Risk factor 7: Slow speed of issuing some required reports. Risk factor 8: Inability to add new department. Risk factor 9: Inability to add new class section. Risk factor 10: Inability to display student roster for instructor. Risk factor 11: Inability to add new instructor to the university.

Risk factor 12: Inability to delete instructor from the university. Risk factor 13: Inability to add new teaching information for instructor. Risk factor14: Inability to update teaching information for instructor. After identifying risk factors, stakeholders have generated solutions for the risk factors and the solutions have been documented with risk factors. Table 4 shows risk identification document of ARS. Table 4. Risk identification document of ARS Risk RISK1: Inability to add new students RISK2: Inability to get result when search on some students RISK3: Slow speed of getting results when search on student's information. RISK4: Inability to display The program study plan to the students.

Suggested solution Sol1: Put strategy to prevent this failure. Sol2: Put some alternative ways such as search with name, number, and class. Sol3: Use some techniques to make the performance of the system faster. Sol4: Use some techniques to make the performance of the system faster.

RISK5: Inability to Add new results for the student.

Sol5: Write a powerful code to prevent this failure.

RISK6: Unauthorized access to results database and change results of student. RISK7: Slow speed of issuing some required reports.

Sol6: Use some techniques to prevent unauthorized access.

RISK8: Inability to Add new department

Sol8: Write a powerful code to prevent this failure

RISK9: Inability Add a new class section.


RISK10: Inability to Display student roster for instructor.


RISK11: Inability to Add new instructor to the university


RISK12: Inability to delete instructor from the university.


RISK13: Inability to add new teaching information for instructor.


RISK14: Inability to update teaching information for instructor.


Sol7: Keep memory space

B. Analyzing risk probabilities and effects on ARS quality This part presents risk analysis steps in terms of analyzing risks that affect ARS. For this purpose, we have utilized probability/impact approach. This approach explains the probability of risks and the impact of them with taking into account the main five attributes of quality, which are Functionality, Reliability, Safety, Performance, and Maintainability [5]. Risk 1: Inability to add new student, the occurring probability of this risk is low because the system is already designed to do this function, and if this risk happened, this means the system does not work properly due to existence of a critical malfunction. Thus, the impact of this risk is high when it occurred. This risk can

be classified as Functional Risk, and it can be also classified as Reliable Risk. Risk 2: Inability to get result when search on some students, the occurring probability of this risk is medium and the impact is also medium. This risk can be classified as Reliable Risk. Risk 3: Slow speed of getting results when search on students, the occurring probability of this risk is high, but the impact is moderate because SPRMQ gets results but slowly. This risk can be classified as Performance Risk. Risk 4: Inability to display the program study plan to student, the occurring probability of this risk is high but the impact is moderate because SPRM will get results but slowly. This risk can be classified as Performance Risk. Risk 5: Inability to add new results (marks) of student, the occurring probability of this risk is low, but the impact is very high because if this risk happened, that means that there is a critical malfunction due to the failure of a main function in ARS. Thus, this risk can be classified as Functional Risk, and it can be also classified as Reliable Risk. In addition, this risk can be classified as Maintainability Risk because (for example) if the ARS does not support the ability to add a new results (marks), the university needs to modify its administration and registration system to support this feature. Risk 6: Unauthorized access database to browse the results (marks) or change marks of student, the occurring probability of this risk is low, but the impact is high. This risk can be classified as Safety Risk because it threatens student database and this will lead to low security if it happened. Risk 7: Slow speed of issuing some required reports, the occurring probability of this risk is high but the impact is moderate because SPRM will get results but slowly. This risk can be classified as Performance Risk. Risk 8: Inability to add new department, the occurring probability of this risk is low but the impact is very high because if this risk happened that means one of the main functions of ARS failed. This risk can be classified as Functional Risk and Reliable Risk. In addition, this risk can be classified as Maintainability Risk because if the ARS does not have the ability to add new department, the university need to change its administration and registration system if it opens new department. Risk 9: Inability to add new class section, the occurring probability of this risk is low but the impact is very high because if this risk happened that means one of the main functions of ARS failed. This risk can be classified as Functional Risk and Reliable Risk. Risk 10: Inability to display student roster for instructor, the occurring probability of this risk is medium and the impact is also medium. This risk can be classified as Reliable Risk. . Risk 11: Inability to add new instructor to the university, the occurring probability of this risk is low but the impact is very high because if this risk happened that means one of the main functions of ARS failed. This risk can be classified as Functional Risk and Reliable Risk. Risk 12: Inability to delete instructor from the university, the occurring probability of this risk is low

but the impact is very high because if this risk happened that means one of the main functions of ARS failed. This risk can be classified as Functional Risk and Reliable Risk. Risk 13: Inability to add new teaching information for instructor, the occurring probability of this risk is low but the impact is very high because if this risk happened that means one of the main functions of ARS failed. This risk can be classified as Functional Risk, and Reliable Risk. Risk 14: Inability to update teaching information for instructor, the occurring probability of this risk is medium and the impact is also medium. This risk can be classified as Reliable Risk. Table 5 shows the risk analysis document of ARS. Table 5. Risk probability/impact of risk on ARS Quality Attribute

Risk Risk 1 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13 Risk 2 Risk 10 Risk 14 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13

Probability Low Low Low Low Low Low Low Medium Medium Medium Low Low Low Low Low Low

Impact High High High High High High High Medium Medium Medium High High High High High High

Safety

Risk 6

Low

High

Performance

Risk 3 Risk 4

High High

Medium Medium

Maintainability

Risk 8

Low

High

Functionality

Reliability

C. Risk Mitigation To mitigate risk that may threat ARS, SPRMQ uses one of three strategies: Avoidance, Minimization, or Contingency. Here we present the risk mitigation strategy used by SPRMQ for each risk factor in ARS. For risk 1: Inability to add new student, SPRMQ uses avoidance strategy which is applied here by adding "hint" next to all text fields in the interface. This hint describes the type of this field (e.g. number, text) to prevent wrong addition. For risk 2: Inability to get result when search on some students, SPRMQ uses minimization strategy which is applied here by providing ARS user different ways to search (e.g. by name, by number, or by class section). For risk 3: Slow speed of getting results when search on students, SPRMQ uses minimization strategy which is applied here by keeping space on free memory to make the system as faster as possible. For risk 4: Inability to display the program study plan to student, SPRMQ uses minimization strategy which is applied here by making an interface contains all possible reports. For risk 5: Inability to add new results (marks) of student, SPRMQ uses avoidance strategy which is

applied here by adding "hint" next to all text field in the interface. This hint describes the type of this field such as number, text, and a student number field "combobox" to prevent wrong addition. For risk 6: Unauthorized access database to browse the results (marks) or change marks of student, SPRM uses avoidance strategy which is applied here by applying password authentication to the interface of results (marks). For risk 7: Slow speed of issuing some required reports, SPRM uses minimization strategy with two steps: first, make one interface only for the reports and second, keep free space on memory as the system can be faster. For risk 8: Inability to add new department, SPRM uses avoidance strategy with two steps: first, make interface departments and second, add "hint" next to all text field in the interface. This hint describes the type of this field such as number and text to prevent wrong addition. For risk 9: Inability to add new class section", SPRM uses avoidance strategy with two steps: first, make interface to class sections and second, add "hint" next to all text field in the interface. This hint describes the type of this field such as number and text to prevent wrong addition. For risk 10: Inability to display student roster for instructor", SPRM uses minimization strategy with two steps: first, make one interface only for the reports and second, keep free space on memory as the system can be faster. For risk 11: Inability to add new instructor to the university, SPRM uses avoidance strategy with two steps: first, make interface for class sections and second, add "hint" next to all text field in the interface. This hint describes the type of this field such as number and text to prevent wrong addition. For risk 12: Inability to delete instructor from the university, SPRM uses avoidance strategy with three steps: first, make interface for instructors, second, make password for this interface, and third, make "delete button" and the code that will execute when the user click on "delete button" with some specific conditions related to the contract of instructor. Table 6. Risk mitigation document of ARS Quality Attribute

Functionality

Reliability Safety Performance Maintainability

Risk

Prob.

Impact

Risk 1 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13 Risk 2 Risk 10 Risk 14 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13 Risk 6 Risk 3 Risk 4 Risk 8

Low Low Low Low Low Low Low Medium Medium Medium Low Low Low Low Low Low Low High High High

High High High High High High High Medium Medium Medium High High High High High High High Medium Medium Low

Mitigation Strategy Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Minimization Minimization Minimization Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Minimization Minimization Avoidance

For risk 13: Inability to add new teaching information for instructor, SPRM uses avoidance strategy with two steps: first, make interface for instructors and second, add "hint" next to all text field in the interface. This hint describes the type of this field such as number and text to prevent wrong addition. For risk 14: Inability to update teaching information for instructor, SPRM uses avoidance strategy with two steps: first, make interface for instructors and second, make "update button" in this interface. Table 6 illustrates the document of risk monitoring for ARS. D. Risk Monitoring Table 7 shows the document of risk monitoring for ARS. To monitor risk on ARS, risk manger needs to do the following steps based on SPRMQ approach: • Make "testing copy" of the ARS. • Give the "testing copy" to users and take feedback from them. • Assess each identified risks regularly to decide whether or not it is becoming less or more probable. • Assess whether the effects of the risk have changed. • Assess whether the strategy to mitigate risk useful. Table 7. Risk monitoring document of ARS Quality Attribute

Risk

Prob.

Impact

Risk 1 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13 Risk 2 Risk 10 Risk 14 Risk 5 Risk 8 Risk 9 Risk 11 Risk 12 Risk 13

Low Low Low Low Low Low Low Med Med Med Low Low Low Low Low Low

High High High High High High High Med Med Med High High High High High High

Mitigation Strategy Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance Minimization Minimization Minimization Avoidance Avoidance Avoidance Avoidance Avoidance Avoidance

Safety

Risk 6

Low

High

Avoidance

Useful

Performance

Risk 3 Risk 4

High High

Med Med

Minimization Minimization

Useful Useful

Maintainability

Risk 8

High

Low

Avoidance

Not useful

Functionality

Reliability

Risk Status Useful Useful Useful Useful Useful Useful Useful Not useful Useful Useful Useful Useful Useful Useful Useful Useful

6. DISCUSSION SPRMQ framework is conducted in this paper to improve software product risk management, reduce risks that affect software product, and improve quality of software product. SPRMQ framework consists of four basic processes: identifying risk factors, analyzing risk probabilities and effects on the product quality, risk mitigation, and risk monitoring. These processes work in a sequence way to manage software product risk. SPRMQ framework is applied to Admission and Registration System (ARS) at University of Science and Technology. To mange a software product using SPRMQ framework, results show that project manager or risk

manager needs to measure the impact of risks that may happen in the risk level of high, medium, or low using SPRMQ processes and strategies depend on quality attributes. If the impact of the risk is high, and this risk will affect the ability of the system to deliver services as pre-specified, or will affect the main functions of the system, this means that the risk is not acceptable and the risk manager needs to apply avoidance strategy in order to prevent the risk. If the impact of risk is medium or low and the risk cannot be prevented, but at the same time, the risk manager can accept this risk, this means that the risk manager or project manager needs to do minimization strategy. If the impact of the risk is low, and the risk cannot be prevented, but at the same time, the risk manager can accept this risk and the risk can happen rarely, this means that the risk manager or project manager needs to apply a contingency strategy.

7. CONCLUSION There are many frameworks to mange software risks, but most of them focus on managing risks that affect projects generally. This paper tries to focus on risks that affect software product. This paper conducts our framework, SPRMQ, for software product risk management. SPRMQ tries to improve software product risk management, reduce risks that affect software product, and improve quality of software product. SPRMQ framework consists of four basic processes work in a sequence way to manage software product risk: identifying risk factors, analyzing risk probabilities and effects on the product quality, risk mitigation, and risk monitoring. SPRMQ framework is applied to Admission and Registration System (ARS) of University of Science and Technology. Results show that using SPRMQ, project manager or risk manager can manage a software product by measuring the impact of risks that may happen in three risk levels: high, medium, or low using SPRMQ processes and strategies depend on quality attributes. As a future work, a researcher can improve SPRMQ framework to manage all external risks that may affect the software product such as marketing risks, organizational risks. Another extension is to improve SPRMQ framework to manage risks that concern with people who work to develop software products. And finally, to the work can be extended by exploring and utilizing other techniques to identify and analyze risk.

REFERENCES

[1] C. Ravindranath Pandian, "Applied software Risk Management", Auerbach Publications, 3rd edition, 2007. [2] Linda Westfall, "Software Risk Management", International Conference on Software Quality, San Diego, California, February 8-10, 2011. [3] Ian Summerville, "Software Engineering", Addison Wesley, 7th Edition, 2007. [4] Jakub Miler, "A Method of Software Project Risk Identification and Analysis", PhD Thesis, Faculty of Electronics, Telecommunications and Informatics, GDAŃSK University of Technology, 2005.

[5]

Wei Xiang, "Software Engineering Project Management", Study Book, Published by University of Southern Queensland, Austalia, 2nd Edition, 2007. [6] BSSC, "Guide to Software Project Management", ESA Board for Software Standardisation and Control (BSSC), ESA Publications Division, ESA PSS-05-08 Issue 1 Revision 1, March 1995. [7] Javeria Samad, Naveed Ikram, "Managing the Risks: An Evaluation of Risk Management Processes", Multitopic Conference INMIC 06 IEEE, pp. 281287, 2006. [8] Office of Management, "Risk Management Guide", U.S. Department of Energy, Washington, D.C. 20585, 2008. Available online at: http://www.directives.doe.gov. [9] Barry W. Boehm, "Software Risk Management: Principles and Practices", Journal IEEE Software, Volume 8, Issue 1, pp. 32-41, January 1991. [10] Richard Fairley, "Risk Management for Software Projects", Journal IEEE Software, Volume 11 Issue 3, pp. 57 – 67, May 1994. [11] Guoping Jiang, Yingwu Chenk, "Coordinate Metrics and Process Model to Manage Software Project Risk", IEEE International Proceedings on Engineering Management Conference, Singapore, pp. 865 - 869 Vol.2, 21-21 October 2004. [12] Y.H. Kwak, J. Stoddard, "Project Risk Management: Lessons Learned from Software Development Environment", Elsevier Sience, Journal Technovation 24, pp. 915 - 920, 2004. [13] IEEE-SA Standards Board, "IEEE Standard for Software Life Cycle Processes-Risk Management", Software Engineering Standards Committee of the IEEE Computer Society, IEEE-SA Standards Board, pp. i – 24, March 2001. [14] Geoffrey G. Roy, "A Risk Management Framework for Software Engineering Practice", IEEE Proceedings, ASWEC '04 Proceedings of the 2004 Australian Software Engineering Conference, pp. 60 - 67 2004. [15] Nan Feng, Jing Xie, "A Method for Software Project Risk Identification Based on GA", IEEE Proceedings, 16th International Conference on Industrial Engineering and Engineering Management, IE&EM '09, pp. 618 – 621, 21-23 Oct. 2009. [16] Khadijah Al-Hidabi, "Administration and Registration System", Master Thesis, The Arab Academy for Banking and Financial Sciences, Computer Information Systems Department, 2008.