Postagens
Abstract. Software development is a complex activity, Involving Several factors "
Which are Sometimes unpredictable and hard to control. This complexity Causes
schedule delays, cost overruns, quality problems and missing functionality. In this
context, an effective management is fundamental to the success of software projects.
The Uncertainty is the Inherent to this kind of problem, risk management has Become
more notable in this knowledge area. This paper presents the risk management map
in three models: PMBOK, CMMI and RUP, with the Objectives of the Investigate
Similarities and differences Among Them to software projects in order to make the
software development more robust.
Keywords: PMBOK, CMMI, RUP, risk management, software quality.
Abstract. Software development is a complex activity involving numerous factors, often unpredictable and difficult to control. This complexity means that most software projects exceed the time limit and the budget, and it does not meet customer expectations in terms of functionality and quality. In this context, effective management is fundamental to the success of software projects. As uncertainty is inherent in
this type of project, risk management is becoming increasingly relevant in this field. This paper presents a mapping risk management described in three models: PMBOK, CMMI and RUP, to investigate the similarities and differences between approaches
these models for software projects, to strengthen the process of software development.
Keywords: PMBOK, CMMI, RUP, risk management, quality software.
1. Introduction
Software development is a complex activity involving many factors that are often unpredictable and difficult to control, such as technological innovations and changes
listed on customer requirements, among many others. This complexity makes large part of software development projects exceeds the deadline and budget provided, and do not meet customer expectations in terms of features and quality. Given this scenario, effective management has been marked as fundamental importance to the success of software projects. Once the uncertainty is 280 inherent in this type of project, risk management is becoming increasingly relevant here. Risk management works just with the uncertainty in order to identifying potential problems and opportunities before they occur in order to eliminate or reduce the likelihood and impact of negative events for
project objectives, potentiate the effects of the occurrence of positive events. Risk management is addressed by several models among which the PMBOK (2000), CMMI (2002), and RUP (2003). The PMBOK Guide (A Guide to the Project Management
Body of Knowledge) deals with project management in a comprehensive way, not being
specific software. The CMMI (Capability Maturity Model Integration for Software)
provides a framework for the implementation and improvement of software process
organizations. RUP (Rational Unified Process) is a process based on best
software engineering practices. This paper presents a mapping of risk management from the three mentioned models, to investigate the similarities and differences between approaches the same for software projects, to strengthen and improve the process of
software development.
This paper is organized as follows. In section 2, is presented to management risk of PMBOK, Section 3, we show the risk management of CMMI; Section 4, is outlined the approach to risk management of RUP. In Section 5, is prepared to mapping of the risk management process in the PMBOK, CMMI and RUP. In section 6, presents the conclusion of the work. 2. Risk Management in PMBOK
The PMBOK (2000) describes the knowledge and best practices in managing projects. According to the PMBOK, the knowledge needed to manage projects is divided into nine areas: Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management, Management
Communication, Risk Management and Procurement Management.
The project risk management includes the processes related to planning risk anagement, identification, analysis, planning and responses to the control and monitoring of risks in a project. These processes interact with processes and other areas of knowledge. The objectives of risk management are to increase likelihood and impact of positive events and minimize the likelihood and the impact of adverse events to project objectives. The processes of risk management are [PMBOK, 2000]:
• Planning for risk management: planning activities of the risk management be completed for the project.
Which are Sometimes unpredictable and hard to control. This complexity Causes
schedule delays, cost overruns, quality problems and missing functionality. In this
context, an effective management is fundamental to the success of software projects.
The Uncertainty is the Inherent to this kind of problem, risk management has Become
more notable in this knowledge area. This paper presents the risk management map
in three models: PMBOK, CMMI and RUP, with the Objectives of the Investigate
Similarities and differences Among Them to software projects in order to make the
software development more robust.
Keywords: PMBOK, CMMI, RUP, risk management, software quality.
Abstract. Software development is a complex activity involving numerous factors, often unpredictable and difficult to control. This complexity means that most software projects exceed the time limit and the budget, and it does not meet customer expectations in terms of functionality and quality. In this context, effective management is fundamental to the success of software projects. As uncertainty is inherent in
this type of project, risk management is becoming increasingly relevant in this field. This paper presents a mapping risk management described in three models: PMBOK, CMMI and RUP, to investigate the similarities and differences between approaches
these models for software projects, to strengthen the process of software development.
Keywords: PMBOK, CMMI, RUP, risk management, quality software.
1. Introduction
Software development is a complex activity involving many factors that are often unpredictable and difficult to control, such as technological innovations and changes
listed on customer requirements, among many others. This complexity makes large part of software development projects exceeds the deadline and budget provided, and do not meet customer expectations in terms of features and quality. Given this scenario, effective management has been marked as fundamental importance to the success of software projects. Once the uncertainty is 280 inherent in this type of project, risk management is becoming increasingly relevant here. Risk management works just with the uncertainty in order to identifying potential problems and opportunities before they occur in order to eliminate or reduce the likelihood and impact of negative events for
project objectives, potentiate the effects of the occurrence of positive events. Risk management is addressed by several models among which the PMBOK (2000), CMMI (2002), and RUP (2003). The PMBOK Guide (A Guide to the Project Management
Body of Knowledge) deals with project management in a comprehensive way, not being
specific software. The CMMI (Capability Maturity Model Integration for Software)
provides a framework for the implementation and improvement of software process
organizations. RUP (Rational Unified Process) is a process based on best
software engineering practices. This paper presents a mapping of risk management from the three mentioned models, to investigate the similarities and differences between approaches the same for software projects, to strengthen and improve the process of
software development.
This paper is organized as follows. In section 2, is presented to management risk of PMBOK, Section 3, we show the risk management of CMMI; Section 4, is outlined the approach to risk management of RUP. In Section 5, is prepared to mapping of the risk management process in the PMBOK, CMMI and RUP. In section 6, presents the conclusion of the work. 2. Risk Management in PMBOK
The PMBOK (2000) describes the knowledge and best practices in managing projects. According to the PMBOK, the knowledge needed to manage projects is divided into nine areas: Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management, Management
Communication, Risk Management and Procurement Management.
The project risk management includes the processes related to planning risk anagement, identification, analysis, planning and responses to the control and monitoring of risks in a project. These processes interact with processes and other areas of knowledge. The objectives of risk management are to increase likelihood and impact of positive events and minimize the likelihood and the impact of adverse events to project objectives. The processes of risk management are [PMBOK, 2000]:
• Planning for risk management: planning activities of the risk management be completed for the project.
• Identification of risks: identifying the risks that may affect the project, documenting their characteristics.
• Analysis of qualitative risk: qualitatively analyze the risks, prioritizing its effects on the project.
• Analysis of quantitative risk: measuring the probability of risks and its consequences and implications for estimating the project.
• Planning the response to risk: creating procedures and techniques to assess opportunities, in order to mitigate the threats to the project.
• Monitoring and controlling the risks, monitoring residual risks, identifying new
risks, implement plans to mitigate risks and evaluate its effectiveness during cliclos entire project life.
3. Risk Management in CMMI-SW CMMI-SW (Capability Maturity Model Integration for Software) is designed to integrate CMM several models that meet the various activities related to developing software, and still make it compatible with ISO / IEC 15504 (2003). The purpose of this integration is guide the assessment and improvement of processes and the ability of organizations to manage the development, acquisition and maintenance of products or services.
CMMI-SW has two representations: (i) by stages, and (ii) continuous. The representation in stages, objects of this work is the maturity level of the organization
as a whole, containing five maturity levels: initial, managed, defined, quantitatively managed and optimizing. Each level consists of a set of process areas, consisting of specific objectives and overall goals. Each objective specific can be composed of a set of specific practices. A specific goal (SG) describes the characteristics that must be present to satisfy a process area. A specific practice (SP) is a description of a
activity that is considered important to achieve the specific goal associated with it.
The issue of risk is addressed in the areas of Project Planning process, Project Monitoring and Control and Risk Management. The first two areas process are at level 2 and the last is at level 3 of CMMI-SW. In Planning Project, we have the SG Plan Development Project with SP Identify Risks Project, which consists in the identification and risk analysis to determine the impact, probability of occurrence and the period that may occur, so that risks can be prioritized. In Monitoring and Control Project, has the SG Monitoring Project Under the Plan, which is inserted SP Monitor Project Risks.
The Risk Management aims to identify potential problems before occur, so that the activities of management of these risks can be planned and performed in accordance with their needs, throughout the life cycle of the product or project, to mitigate potential adverse impacts. Table 1 shows the relationship of specific objectives with their specific practices for the management of risk.
• Analysis of qualitative risk: qualitatively analyze the risks, prioritizing its effects on the project.
• Analysis of quantitative risk: measuring the probability of risks and its consequences and implications for estimating the project.
• Planning the response to risk: creating procedures and techniques to assess opportunities, in order to mitigate the threats to the project.
• Monitoring and controlling the risks, monitoring residual risks, identifying new
risks, implement plans to mitigate risks and evaluate its effectiveness during cliclos entire project life.
3. Risk Management in CMMI-SW CMMI-SW (Capability Maturity Model Integration for Software) is designed to integrate CMM several models that meet the various activities related to developing software, and still make it compatible with ISO / IEC 15504 (2003). The purpose of this integration is guide the assessment and improvement of processes and the ability of organizations to manage the development, acquisition and maintenance of products or services.
CMMI-SW has two representations: (i) by stages, and (ii) continuous. The representation in stages, objects of this work is the maturity level of the organization
as a whole, containing five maturity levels: initial, managed, defined, quantitatively managed and optimizing. Each level consists of a set of process areas, consisting of specific objectives and overall goals. Each objective specific can be composed of a set of specific practices. A specific goal (SG) describes the characteristics that must be present to satisfy a process area. A specific practice (SP) is a description of a
activity that is considered important to achieve the specific goal associated with it.
The issue of risk is addressed in the areas of Project Planning process, Project Monitoring and Control and Risk Management. The first two areas process are at level 2 and the last is at level 3 of CMMI-SW. In Planning Project, we have the SG Plan Development Project with SP Identify Risks Project, which consists in the identification and risk analysis to determine the impact, probability of occurrence and the period that may occur, so that risks can be prioritized. In Monitoring and Control Project, has the SG Monitoring Project Under the Plan, which is inserted SP Monitor Project Risks.
The Risk Management aims to identify potential problems before occur, so that the activities of management of these risks can be planned and performed in accordance with their needs, throughout the life cycle of the product or project, to mitigate potential adverse impacts. Table 1 shows the relationship of specific objectives with their specific practices for the management of risk.
282
Table 1. Relationship of the SG and SP of Risk Management in CMMI-SW
SG 1 Prepare for Risk Management
SP 1.1 Determine Risk Sources and Categories
SP 1.2 Define Risk Parameters
SP 1.3 Establish a Strategy for Risk Management
SG 2 Identify and Analyze Risk
SP 2.1 Identify Risks
SP 2.2 Evaluate, Categorize, and Prioritize Risks
SG 3 Mitigate Risks
SP 3.1 Develop Risk Mitigation Plans
SP 3.2 Implement Risk Mitigation Plans
The process areas of Project Planning and Project Monitoring and Control, Level 2, handle risk management in a reactive way, focusing simply on identification of risk awareness, and reaction as they occur. The area of Process Risk Management, Level 3, this risk management in a proactive, describing the evolution of specific practices to systematically plan, anticipate, and mitigate risk in order to proactively minimize their impact on the project.
Table 1. Relationship of the SG and SP of Risk Management in CMMI-SW
SG 1 Prepare for Risk Management
SP 1.1 Determine Risk Sources and Categories
SP 1.2 Define Risk Parameters
SP 1.3 Establish a Strategy for Risk Management
SG 2 Identify and Analyze Risk
SP 2.1 Identify Risks
SP 2.2 Evaluate, Categorize, and Prioritize Risks
SG 3 Mitigate Risks
SP 3.1 Develop Risk Mitigation Plans
SP 3.2 Implement Risk Mitigation Plans
The process areas of Project Planning and Project Monitoring and Control, Level 2, handle risk management in a reactive way, focusing simply on identification of risk awareness, and reaction as they occur. The area of Process Risk Management, Level 3, this risk management in a proactive, describing the evolution of specific practices to systematically plan, anticipate, and mitigate risk in order to proactively minimize their impact on the project.
4. Risk Management in RUP
RUP (2003) is a software engineering process based on best practices development and fundamental principles, among which are to be directed at cases of use, focusing on architecture, directed the risks and be iterative. According to the RUP (2003), the risks must be identified and attacked as soon as possible in the life cycle of the project, always aiming to guarantee the production of software High quality, according to users' needs and are produced on time and within provided. Every project has a number of risks involved and many are not discovered until system integration is performed.
Unidentified risks mean that you can be investing in an architecture failure or a non-optimized set of requirements. In addition, all risks involved is directly related to the difference between the estimate of how long it will long before the project is completed. To obtain accurate estimates is needed identify and address the risks beforehand.
The RUP has two dimensions. The first is the dimension that represents the static
static structure of the process, describing how the process elements are grouped
logically into subjects. Courses are logical groupings of roles, activities, artifacts and other guides to the description of a process, and are represented by a flow work. The second is the dynamic dimension that is represented by time and expressed the
process through cycles, broken down into stages, which are divided into iterations
milestones of completion. The software development process RUP is iterative, where an iteration incorporates a set of activities in business modeling, requirements analysis and design, implementation, testing and deployment in various proportions, depending on where the iteration is located in the development cycle. One of the main benefits of the approach iterative identification and treatment is the major project risks in a timely manner.
RUP (2003) is a software engineering process based on best practices development and fundamental principles, among which are to be directed at cases of use, focusing on architecture, directed the risks and be iterative. According to the RUP (2003), the risks must be identified and attacked as soon as possible in the life cycle of the project, always aiming to guarantee the production of software High quality, according to users' needs and are produced on time and within provided. Every project has a number of risks involved and many are not discovered until system integration is performed.
Unidentified risks mean that you can be investing in an architecture failure or a non-optimized set of requirements. In addition, all risks involved is directly related to the difference between the estimate of how long it will long before the project is completed. To obtain accurate estimates is needed identify and address the risks beforehand.
The RUP has two dimensions. The first is the dimension that represents the static
static structure of the process, describing how the process elements are grouped
logically into subjects. Courses are logical groupings of roles, activities, artifacts and other guides to the description of a process, and are represented by a flow work. The second is the dynamic dimension that is represented by time and expressed the
process through cycles, broken down into stages, which are divided into iterations
milestones of completion. The software development process RUP is iterative, where an iteration incorporates a set of activities in business modeling, requirements analysis and design, implementation, testing and deployment in various proportions, depending on where the iteration is located in the development cycle. One of the main benefits of the approach iterative identification and treatment is the major project risks in a timely manner.
283
Risk management in RUP is within the discipline of management Project, which aims to balance competing goals, manage risks and constraints to as the supply of product to satisfy your customers and users. This discipline provides a framework where the project is built and managed. Risk management is integrated into the development process, where iterations are planned and are based on the risks of higher priority. In one approach iterative, risks are mitigated earlier, because the elements are integrated progressively. Once each iteration exercises many aspects of the project, it becomes easier to find to what point the perceived risks are materializing, but also discover new and unsuspected risks, as risks are easier to locate and the costs involved are
minors. In RUP, the iterative life cycle is divided into four phases, which focus on
problem of risk of a cooperative manner:
· Design: focus on treatment of risks related to business affairs.
· Development: focus mainly on technical risks, examining the risks of architecture and, if necessary, revising the scope of the project as their requirements become better understood.
• Construction: focus on the risks of "logistics" and in obtaining the completion of major part of the job.
· Transition: focus on the risks associated with the logistics of product delivery to your
user. The role involved with risk management in RUP is the project manager,
performing activities Develop Risk Management Plan, identify and
Assess Risks and Monitor Project Status, which have as input or output artifacts
Overview (requirements document), Risk Management Plans, and Risk List.
5. Mapping of Risk Management in PMBOK, RUP and CMMI-SW
This section presents the mapping between the approaches of risk management
PMBOK (2000), CMMI-SW (2002) and RUP (2003), keeping in view the process of
software development, according to Table 2. This mapping was also based
in Gusmão et al. (2003) and Reinehr et al. (2003). Then an analysis will be presented
the relationship between these models.
The PMBOK is used as the basis for this mapping through the area Risk Management knowledge, being a widely used model, containing best practices for project management in general. To CMMI-SW, will be used the area of Risk Management process, Level 3, with their specific goals (SG) and practical specific (SP) corresponding to the RUP, will be used workflows (workflows) detailed (with their corresponding activities), belonging to the Management discipline Project.
284
Table 2. Process Risk Management PMBOK x x RUP CMMI-SW PMBOK RUP CMMI-SW
Area:
Risk Management
Process Area:
Risk Management
Discipline:
Project Management
Planning
Risk Management
Prepare for Risk Management (SG 1):
• Determine Risk Sources and Categories (SP1.1)
• Define Risk Parameters (SP 1.2)
• Establish a Strategy for Management Risk (SP 1.3) Project Planning Develop Plan Risk Management
Identification of Risks
Identify and Analyse Risk (SG 2)
Identify Risks (SP 2.1)
Assessing the Scope of the Project and
Risks Identify and Evaluate
Risks Qualitative Analysis
Risk Identify and Analyse Risk (SG 2)
Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Quantitative Analysis Risk
Identify and Analyse Risk (SG 2) Evaluate, Categorize and Prioritize Risks (SP 2.2)
Risk management in RUP is within the discipline of management Project, which aims to balance competing goals, manage risks and constraints to as the supply of product to satisfy your customers and users. This discipline provides a framework where the project is built and managed. Risk management is integrated into the development process, where iterations are planned and are based on the risks of higher priority. In one approach iterative, risks are mitigated earlier, because the elements are integrated progressively. Once each iteration exercises many aspects of the project, it becomes easier to find to what point the perceived risks are materializing, but also discover new and unsuspected risks, as risks are easier to locate and the costs involved are
minors. In RUP, the iterative life cycle is divided into four phases, which focus on
problem of risk of a cooperative manner:
· Design: focus on treatment of risks related to business affairs.
· Development: focus mainly on technical risks, examining the risks of architecture and, if necessary, revising the scope of the project as their requirements become better understood.
• Construction: focus on the risks of "logistics" and in obtaining the completion of major part of the job.
· Transition: focus on the risks associated with the logistics of product delivery to your
user. The role involved with risk management in RUP is the project manager,
performing activities Develop Risk Management Plan, identify and
Assess Risks and Monitor Project Status, which have as input or output artifacts
Overview (requirements document), Risk Management Plans, and Risk List.
5. Mapping of Risk Management in PMBOK, RUP and CMMI-SW
This section presents the mapping between the approaches of risk management
PMBOK (2000), CMMI-SW (2002) and RUP (2003), keeping in view the process of
software development, according to Table 2. This mapping was also based
in Gusmão et al. (2003) and Reinehr et al. (2003). Then an analysis will be presented
the relationship between these models.
The PMBOK is used as the basis for this mapping through the area Risk Management knowledge, being a widely used model, containing best practices for project management in general. To CMMI-SW, will be used the area of Risk Management process, Level 3, with their specific goals (SG) and practical specific (SP) corresponding to the RUP, will be used workflows (workflows) detailed (with their corresponding activities), belonging to the Management discipline Project.
284
Table 2. Process Risk Management PMBOK x x RUP CMMI-SW PMBOK RUP CMMI-SW
Area:
Risk Management
Process Area:
Risk Management
Discipline:
Project Management
Planning
Risk Management
Prepare for Risk Management (SG 1):
• Determine Risk Sources and Categories (SP1.1)
• Define Risk Parameters (SP 1.2)
• Establish a Strategy for Management Risk (SP 1.3) Project Planning Develop Plan Risk Management
Identification of Risks
Identify and Analyse Risk (SG 2)
Identify Risks (SP 2.1)
Assessing the Scope of the Project and
Risks Identify and Evaluate
Risks Qualitative Analysis
Risk Identify and Analyse Risk (SG 2)
Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Quantitative Analysis Risk
Identify and Analyse Risk (SG 2) Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks Planning Risk Response Mitigating Risks (SG 3)
Develop Risk Mitigation Plans (SP 3.1)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Monitoring and Control Risks
Mitigating Risks (SG 3)
Implement the Risk Mitigation Plans (SP 3.2)
Monitor and Control Project
• Track the Status of Project
5.1. Risk Management Planning The Risk Management Planning in the PMBOK is the process of deciding how to approach and conduct risk management activities for a project. This is important to ensure the level, type and visibility of risk management are commensurate with the risk and importance of the project for the organization. This will also ensure resources and deadlines sufficient for the activities of risk management, establishing a consensual basis for risk assessment. The result of this process is the Risk Management Plan, which describes how management should be structured and executed the project.
In CMMI-SW, preparing for Risk Management is conducted through the establishment and maintenance of a strategy to identify, analyze and mitigate risks. Typically, this is documented in a Risk Management Plan. The strategy of Risk management refers to specific actions and management approach used to implement and control the risk management program. This includes identifying the sources of risk, the scheme
used to categorize risks, and the parameters used to assess, limit and control risks for an effective manipulation. In RUP, the Risk Management Plan is an artifact of the output activity Develop Risk Management Plan, which belongs to the workflow
Detailed Project Planning. This activity aims to create a plan documented process for identifying, analyzing and prioritizing risks and identify strategies management to the most relevant risks of the project.
Identify and Evaluate Risks Planning Risk Response Mitigating Risks (SG 3)
Develop Risk Mitigation Plans (SP 3.1)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Monitoring and Control Risks
Mitigating Risks (SG 3)
Implement the Risk Mitigation Plans (SP 3.2)
Monitor and Control Project
• Track the Status of Project
5.1. Risk Management Planning The Risk Management Planning in the PMBOK is the process of deciding how to approach and conduct risk management activities for a project. This is important to ensure the level, type and visibility of risk management are commensurate with the risk and importance of the project for the organization. This will also ensure resources and deadlines sufficient for the activities of risk management, establishing a consensual basis for risk assessment. The result of this process is the Risk Management Plan, which describes how management should be structured and executed the project.
In CMMI-SW, preparing for Risk Management is conducted through the establishment and maintenance of a strategy to identify, analyze and mitigate risks. Typically, this is documented in a Risk Management Plan. The strategy of Risk management refers to specific actions and management approach used to implement and control the risk management program. This includes identifying the sources of risk, the scheme
used to categorize risks, and the parameters used to assess, limit and control risks for an effective manipulation. In RUP, the Risk Management Plan is an artifact of the output activity Develop Risk Management Plan, which belongs to the workflow
Detailed Project Planning. This activity aims to create a plan documented process for identifying, analyzing and prioritizing risks and identify strategies management to the most relevant risks of the project.
285
The three approaches point to the need to plan the management of risks similarly. However, RUP is risk management as essential only for larger projects or high risk, and places it as an option for smaller projects, which would be enough to just drawing up the Risk List.
The three approaches point to the need to plan the management of risks similarly. However, RUP is risk management as essential only for larger projects or high risk, and places it as an option for smaller projects, which would be enough to just drawing up the Risk List.
5.2. Risk Identification
The Risk Identification in the PMBOK involves determining what risks may occur in a particular project, determine which ones may affect this project and document characteristics. This is an iterative process because new risks may arise during the life cycle of the project. The frequency of iterations and who should attend each cycle varies case by case basis. The project team should be involved in order to develop a sense of responsibility for the risks and take necessary actions. The process of Risk Identification is related rather to the process of Qualitative Risk Analysis. Alternatively, this may be related directly with the process of Quantitative Risk Analysis, when driven by a
manager with experience in risk. In some cases the mere identification of risk have suggested answers to these, and that should be recorded for later analysis and implementation in process of Risk Response Planning. To CMMI-SW, the identification of potential situations, dangers, threats and vulnerabilities that could negatively affect efforts or plans of work, is the basis for successful risk management. Risks must be identified and documented in a concise language, including the context, conditions and
consequences of its occurrence, so they can be analyzed and managed properly.
The use of categories and parameters developed in the strategy of risk management,
together with the identified sources of risk, can provide discipline and optimization
appropriate to risk identification.
The identified risks form a basis for the beginning of activities of risk management. The list of risks should be reviewed periodically so that if identify possible new sources of risk and changes in the risks identified earlier, or even risks that were overlooked or did not exist when risk management strategy was drafted. The product of the specific practice Identify Risks, belonging to the specific objective to identify and analyze risk, is the list of risks identified, including the context, conditions and consequences of the risk occurring.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to Identification of risks:
Identify potential risks: aims to create and keep updated the list of risks.
Risks "to review during the Iteration: aims to check what has changed.
"To review risks at the End of an Iteration: aims to eliminate risks which have been
fully mitigated and introduce newly discovered risks. The list of risks, which is the product of the activity Identify and Assess Risk, is a artifact fundamental to the RUP, it serves as a focal point for activities
The Risk Identification in the PMBOK involves determining what risks may occur in a particular project, determine which ones may affect this project and document characteristics. This is an iterative process because new risks may arise during the life cycle of the project. The frequency of iterations and who should attend each cycle varies case by case basis. The project team should be involved in order to develop a sense of responsibility for the risks and take necessary actions. The process of Risk Identification is related rather to the process of Qualitative Risk Analysis. Alternatively, this may be related directly with the process of Quantitative Risk Analysis, when driven by a
manager with experience in risk. In some cases the mere identification of risk have suggested answers to these, and that should be recorded for later analysis and implementation in process of Risk Response Planning. To CMMI-SW, the identification of potential situations, dangers, threats and vulnerabilities that could negatively affect efforts or plans of work, is the basis for successful risk management. Risks must be identified and documented in a concise language, including the context, conditions and
consequences of its occurrence, so they can be analyzed and managed properly.
The use of categories and parameters developed in the strategy of risk management,
together with the identified sources of risk, can provide discipline and optimization
appropriate to risk identification.
The identified risks form a basis for the beginning of activities of risk management. The list of risks should be reviewed periodically so that if identify possible new sources of risk and changes in the risks identified earlier, or even risks that were overlooked or did not exist when risk management strategy was drafted. The product of the specific practice Identify Risks, belonging to the specific objective to identify and analyze risk, is the list of risks identified, including the context, conditions and consequences of the risk occurring.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to Identification of risks:
Identify potential risks: aims to create and keep updated the list of risks.
Risks "to review during the Iteration: aims to check what has changed.
"To review risks at the End of an Iteration: aims to eliminate risks which have been
fully mitigated and introduce newly discovered risks. The list of risks, which is the product of the activity Identify and Assess Risk, is a artifact fundamental to the RUP, it serves as a focal point for activities
286
project and is the basis around which iterations are organized. The risk directs plans of iterations, which are geared to the treatment of specific risks, trying to eliminate them
or reduce them. The list of risks should be reviewed periodically to assess the effectiveness of risk mitigation strategies, which in turn lead to revisions of the project plan and subsequent iterations of the plans.
It appears that all three approaches have a strong line with regard to process of identifying risks. All emphasize that risk identification should be done iteratively during the project life cycle, there must be involvement of project team and that is a fundamental process for managing the project as a whole. The list of risk is the product of the process in all approaches concerned emphasizing the importance of keeping it updated often.
5.3. Qualitative Risk Analysis
A Qualitative Analysis of Risks in the PMBOK is generally a quick way to establish
priorities for planning the response of the risk and provide the basis for analysis
Quantitative risk, if this is required. This process evaluates the priority of risk
identified using their probability of occurrence and its impact on project objectives if the risks occur. Definitions of the levels of probability and impact, interviews with experts and assessing the quality of information available in the project can help correct the polarizations, which are often present in the data used in this process. The analysis
qualitative risk should be reviewed during the lifecycle of the project to be updated
according to changes in project risks. In CMMI-SW, a qualitative analysis of risks is specified in the specific practice Evaluate, Categorize and Prioritize Risks, which belongs to the specific objective to identify and Analyze Risk. The assessment and categorization of each identified risk is done using categories and parameters of risk and then, its priority is determined. The defined risk parameters may include likelihood, consequence (severity or impact) and limits. The parameter values assigned to the risk can be integrated to produce additional measures, such as exposure to risk, which can be used to prioritize risks.
The risk assessment is needed to determine the relative importance of each
identified risk, being used in the determination of when appropriate management attention is required. The work product of this practice is the list of risks with their respective priority.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to risk analysis:
· Analyse and Prioritize Risks: Match similar risks (to reduce the
List size of risks) and to classify them in terms of its impact on project.
287
Risks "to review during the Iteration: objective guarantee that the list of risks is maintained
updated throughout the project, including with regard to the prioritization of risks.
"To review risks at the End of an Iteration: reassesses the magnitude and reordering the risks
After the elimination of risks mitigated, and also introduces new risks to the list of risks.
Once again it is found that the three approaches maintain a high synergy in refers to the process of Qualitative Risk Analysis. All emphasize the importance of determine the likelihood and impact of the risk, the categorization of these risks and the continuous updating of the risk list. However, it should be noted that the PMBOK divides risk analysis in qualitative and quantitative analysis, while the other approaches do not make this distinction. Thus, the PMBOK provides a more elaborate analysis risks.
5.4. Quantitative Risk Analysis
The Quantitative Risk Analysis in the PMBOK aims to analyze numerically
probability of each identified risk and its consequence to the project objectives.
It also presents a quantitative approach to decision making in the presence of uncertainty, using techniques such as decision tree analysis and Monte Carlo simulation
Carlo (PMBOK, 2000).
This process usually follows the qualitative analysis of risks, although managers
with experience in risk tend sometimes to run it directly after the identification of
risk. In some cases, the quantitative analysis of the risk may not be required to
develop effective responses to risk. The availability of time and budget and the
need for qualitative or quantitative statements about risk and its impacts determine which methods should be used for a particular project. In CMMI-SW, the quantitative analysis of risks is referenced in the specific practice Evaluate, Categorize and Prioritize Risks in sub-practice Evaluate the Risks Identified, using defined parameters, which require that each risk is evaluated and receives a assignment of values according to parameters defined for it. These parameters can be aggregated and produce additional measures, such as exposure to risk, which can be used to prioritize them.
Generally, a scale with three to five values is used to evaluate the probability and the consequence of risk. Probable values are often used to quantify the probability. Consequences are generally related to cost, schedule, the environmental or human measures (such as time lost from work and severity of injury). This assessment is often a difficult task and it consumes time. Technical specialties or specific group may be necessary to evaluate risks and gain confidence in time to prioritize them.
In RUP, the quantitative analysis of risks is also referenced in the activity Identify and assess risks where it is emphasized that the risks are prioritized according to general exposure that it poses to the software project. To determine the exposure of each risk should be the estimation of the following information:
project and is the basis around which iterations are organized. The risk directs plans of iterations, which are geared to the treatment of specific risks, trying to eliminate them
or reduce them. The list of risks should be reviewed periodically to assess the effectiveness of risk mitigation strategies, which in turn lead to revisions of the project plan and subsequent iterations of the plans.
It appears that all three approaches have a strong line with regard to process of identifying risks. All emphasize that risk identification should be done iteratively during the project life cycle, there must be involvement of project team and that is a fundamental process for managing the project as a whole. The list of risk is the product of the process in all approaches concerned emphasizing the importance of keeping it updated often.
5.3. Qualitative Risk Analysis
A Qualitative Analysis of Risks in the PMBOK is generally a quick way to establish
priorities for planning the response of the risk and provide the basis for analysis
Quantitative risk, if this is required. This process evaluates the priority of risk
identified using their probability of occurrence and its impact on project objectives if the risks occur. Definitions of the levels of probability and impact, interviews with experts and assessing the quality of information available in the project can help correct the polarizations, which are often present in the data used in this process. The analysis
qualitative risk should be reviewed during the lifecycle of the project to be updated
according to changes in project risks. In CMMI-SW, a qualitative analysis of risks is specified in the specific practice Evaluate, Categorize and Prioritize Risks, which belongs to the specific objective to identify and Analyze Risk. The assessment and categorization of each identified risk is done using categories and parameters of risk and then, its priority is determined. The defined risk parameters may include likelihood, consequence (severity or impact) and limits. The parameter values assigned to the risk can be integrated to produce additional measures, such as exposure to risk, which can be used to prioritize risks.
The risk assessment is needed to determine the relative importance of each
identified risk, being used in the determination of when appropriate management attention is required. The work product of this practice is the list of risks with their respective priority.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to risk analysis:
· Analyse and Prioritize Risks: Match similar risks (to reduce the
List size of risks) and to classify them in terms of its impact on project.
287
Risks "to review during the Iteration: objective guarantee that the list of risks is maintained
updated throughout the project, including with regard to the prioritization of risks.
"To review risks at the End of an Iteration: reassesses the magnitude and reordering the risks
After the elimination of risks mitigated, and also introduces new risks to the list of risks.
Once again it is found that the three approaches maintain a high synergy in refers to the process of Qualitative Risk Analysis. All emphasize the importance of determine the likelihood and impact of the risk, the categorization of these risks and the continuous updating of the risk list. However, it should be noted that the PMBOK divides risk analysis in qualitative and quantitative analysis, while the other approaches do not make this distinction. Thus, the PMBOK provides a more elaborate analysis risks.
5.4. Quantitative Risk Analysis
The Quantitative Risk Analysis in the PMBOK aims to analyze numerically
probability of each identified risk and its consequence to the project objectives.
It also presents a quantitative approach to decision making in the presence of uncertainty, using techniques such as decision tree analysis and Monte Carlo simulation
Carlo (PMBOK, 2000).
This process usually follows the qualitative analysis of risks, although managers
with experience in risk tend sometimes to run it directly after the identification of
risk. In some cases, the quantitative analysis of the risk may not be required to
develop effective responses to risk. The availability of time and budget and the
need for qualitative or quantitative statements about risk and its impacts determine which methods should be used for a particular project. In CMMI-SW, the quantitative analysis of risks is referenced in the specific practice Evaluate, Categorize and Prioritize Risks in sub-practice Evaluate the Risks Identified, using defined parameters, which require that each risk is evaluated and receives a assignment of values according to parameters defined for it. These parameters can be aggregated and produce additional measures, such as exposure to risk, which can be used to prioritize them.
Generally, a scale with three to five values is used to evaluate the probability and the consequence of risk. Probable values are often used to quantify the probability. Consequences are generally related to cost, schedule, the environmental or human measures (such as time lost from work and severity of injury). This assessment is often a difficult task and it consumes time. Technical specialties or specific group may be necessary to evaluate risks and gain confidence in time to prioritize them.
In RUP, the quantitative analysis of risks is also referenced in the activity Identify and assess risks where it is emphasized that the risks are prioritized according to general exposure that it poses to the software project. To determine the exposure of each risk should be the estimation of the following information:
288
· Impact of risk: deviations related to the planning schedule, effort or costs if the risk occurs.
· Impact of risk: deviations related to the planning schedule, effort or costs if the risk occurs.
· Probability of occurrence: the probability that the risk actually occurs (Usually expressed as a percentage)
· Exposure to risk: the impact of product probability.
In the process of Qualitative Risk Analysis, note that the PMBOK is more complete, specifying various items to be quantified, tools and techniques to be used, providing the update of the risk list containing the following items:
• analyze probabilistic design;
· Probability of achieving the goals of cost and time;
• List of prioritized risks quantified;
· Trends in the results of quantitative risk analysis.
5.5. Risk Response Planning
The Risk Response Planning is the process of developing options and determine actions to expand opportunities and reduce threats to project objectives.
Follows the process of Qualitative Risk Analysis and Quantitative Risk Analysis.
It includes the identification and assignment of individuals or groups who will be responsible for each risk response plan and insert resources and tasks on budget, on schedule and on project management plan, if necessary.
This process should be appropriate to the seriousness of the risk, weighing the costs with respect the challenges faced, considering the opportunity to succeed, be realistic within the context of the project and be accepted by all parties involved. Sometimes it is necessary select the best answer to the risk of several options available.
To CMMI-SW, the steps include developing risk treatment options risk treatment, monitoring and implementing risk treatment activities, when the limits are exceeded. The risk mitigation plans are developed and run so that the potential impact of risk occurrence are selected proactively reduced. This may also include contingency plans to deal with impact of selected risks that may occur despite attempts to mitigate them.
The parameters used to trigger the activities of the treatment of risk are defined
the strategy of risk management. The mitigation plan for a risk includes techniques and
methods used to prevent, reduce and control the probability of its occurrence, and extent of damage if it occurs (contingency plan). Mitigation plans and contingency risk are often generated only for selected risks, where the consequences of certain risks are as high or unacceptable. Other risks can be accepted and simply monitored. The options for the treatment of risks typically include alternatives such as:
· Cancellation of risks: changing or downloading while still meeting the requirements
users' needs.
• Control of risks: take action to minimize risks.
· Transfer of risk: review the design requirements to lower risks.
289
• Monitoring risk: periodically reassess risks to identify possible changes in the parameters assigned to the risks.
The activity Identify and Assess Risks in RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked with the Risk response planning:
Identify Strategies for Preventing Risks: aims to reorganize the project to eliminate risks.
Identify Strategies to Mitigate Risks: develop plans for mitigating the risk to reduce the impact of risks.
Identify Contingency Strategies: generates alternative plans, which must contain the indicator of the risk and action to take if it occurs.
All approaches have a great similarity with regard to the process of Risk Response Planning. All deal with strategies for dealing with risk through disposal, transfer or acceptance, development and the mitigation plan contingency plan. In all approaches, there is an update of the list of risks with inclusion of plans, responsible for risk, the warning signs that the risk will occur and updating the project plan according to feedback selected.
· Exposure to risk: the impact of product probability.
In the process of Qualitative Risk Analysis, note that the PMBOK is more complete, specifying various items to be quantified, tools and techniques to be used, providing the update of the risk list containing the following items:
• analyze probabilistic design;
· Probability of achieving the goals of cost and time;
• List of prioritized risks quantified;
· Trends in the results of quantitative risk analysis.
5.5. Risk Response Planning
The Risk Response Planning is the process of developing options and determine actions to expand opportunities and reduce threats to project objectives.
Follows the process of Qualitative Risk Analysis and Quantitative Risk Analysis.
It includes the identification and assignment of individuals or groups who will be responsible for each risk response plan and insert resources and tasks on budget, on schedule and on project management plan, if necessary.
This process should be appropriate to the seriousness of the risk, weighing the costs with respect the challenges faced, considering the opportunity to succeed, be realistic within the context of the project and be accepted by all parties involved. Sometimes it is necessary select the best answer to the risk of several options available.
To CMMI-SW, the steps include developing risk treatment options risk treatment, monitoring and implementing risk treatment activities, when the limits are exceeded. The risk mitigation plans are developed and run so that the potential impact of risk occurrence are selected proactively reduced. This may also include contingency plans to deal with impact of selected risks that may occur despite attempts to mitigate them.
The parameters used to trigger the activities of the treatment of risk are defined
the strategy of risk management. The mitigation plan for a risk includes techniques and
methods used to prevent, reduce and control the probability of its occurrence, and extent of damage if it occurs (contingency plan). Mitigation plans and contingency risk are often generated only for selected risks, where the consequences of certain risks are as high or unacceptable. Other risks can be accepted and simply monitored. The options for the treatment of risks typically include alternatives such as:
· Cancellation of risks: changing or downloading while still meeting the requirements
users' needs.
• Control of risks: take action to minimize risks.
· Transfer of risk: review the design requirements to lower risks.
289
• Monitoring risk: periodically reassess risks to identify possible changes in the parameters assigned to the risks.
The activity Identify and Assess Risks in RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked with the Risk response planning:
Identify Strategies for Preventing Risks: aims to reorganize the project to eliminate risks.
Identify Strategies to Mitigate Risks: develop plans for mitigating the risk to reduce the impact of risks.
Identify Contingency Strategies: generates alternative plans, which must contain the indicator of the risk and action to take if it occurs.
All approaches have a great similarity with regard to the process of Risk Response Planning. All deal with strategies for dealing with risk through disposal, transfer or acceptance, development and the mitigation plan contingency plan. In all approaches, there is an update of the list of risks with inclusion of plans, responsible for risk, the warning signs that the risk will occur and updating the project plan according to feedback selected.
5.6. Monitoring and Controlling Risk
The Monitor and Control Risks is the process of identifying, analyzing and planning the new risks that arise, monitoring the identified risks and those on the watch list, monitoring the "trigger conditions" contingency plans, monitoring risks
wastewater and reviewing the implementation of risk response to evaluate their effectiveness.
This process applies new tools, such as analysis of variance and trend requiring the use of performance data generated during the execution of the project. This process may involve choosing alternative strategies, implementing a plan contingency or emergency, taking corrective actions or redesign the project. It also includes the inclusion of lessons learned in the project databases and models Risk management for the benefit of future projects. CMMI-SW requires to effectively monitor and manage risks during work effort is to be followed a proactive program to regularly monitor the risks and status, and the results of follow-up actions of the risks. The strategy Risk management determines the intervals at which the risk status should be reviewed. This can result in the discovery of new risks and new options for handling, which may require re-planning and reassessment. At both events, the acceptance limits associated with the risk should be compared with the status, to determine the need for implementation of the plan for risk mitigation. The specific practice to which this monitoring is Implement Risk Mitigation Plans. In RUP, the activity Monitor the Status of the Project consists of the following:
· Capturing the Job Status: gathering information quality and progress of project to assess the current status. The Monitor and Control Risks is the process of identifying, analyzing and planning the new risks that arise, monitoring the identified risks and those on the watch list, monitoring the "trigger conditions" contingency plans, monitoring risks
wastewater and reviewing the implementation of risk response to evaluate their effectiveness.
This process applies new tools, such as analysis of variance and trend requiring the use of performance data generated during the execution of the project. This process may involve choosing alternative strategies, implementing a plan contingency or emergency, taking corrective actions or redesign the project. It also includes the inclusion of lessons learned in the project databases and models Risk management for the benefit of future projects. CMMI-SW requires to effectively monitor and manage risks during work effort is to be followed a proactive program to regularly monitor the risks and status, and the results of follow-up actions of the risks. The strategy Risk management determines the intervals at which the risk status should be reviewed. This can result in the discovery of new risks and new options for handling, which may require re-planning and reassessment. At both events, the acceptance limits associated with the risk should be compared with the status, to determine the need for implementation of the plan for risk mitigation. The specific practice to which this monitoring is Implement Risk Mitigation Plans. In RUP, the activity Monitor the Status of the Project consists of the following:
· Deriving Indicators of Progress: properly evaluate the project progress regarding plans.
290
· Derive Quality Indicators: using quality metrics.
Evaluate Indicators x Plans: compares the state expected the project according
with what was defined in the Development Plan and the Plan Iteration.
All approaches strongly indicate that the risks must be monitored and managed throughout the lifecycle of the project through the reassessment of risk and monitoring indicators.
6. Conclusion
This paper presented a mapping of risk management from the PMBOK, CMMI, and RUP, with the aim to investigate similarities and differences between the approaches
the same for software projects.
From this survey, it was found that these risk management models is consistent in all essentials, for no fundamental incompatibility between them. This demonstrates the importance of risk management for software projects, particularly by giving a proper treatment of uncertainties, and promoting the improvement of software processes.
Only the process of Quantitative Risk Analysis is not described in the PMBOK
separately in CMMI or RUP. As in the PMBOK this practice is treated as a process, there is greater clarity about how it should be conducted. Moreover, it suggests elements to be included in the list of risks, which are not considered in other models.
As the focus is specifically the PMBOK project management, it offers greater detail with regard to the descriptions of inputs, tools and techniques suggested and outputs. However, as this is not a specific model for software, missing explicit link with the specifics during the development process software.
References
CMMI Product Team. 2002. CMMI for Systems Engineering / Software Engineering, Version
1.1 Staged Representation (CMU/SEI-2002-TR-029, ESC-TR-2002-029). Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University.
Gusmao, C. M. G., Moura, P. H. 2003. ISO, CMMI, and PMBOK Risk Management: a
Comparative Analysis. The International Journal of Applied Management and
Technology, Volume 1, Number 1.
ISO / IEC 15504. 2003. Software Process Assessment.
PMBOK. 2000. PMI Standards Committee. A Guide to the Project Management Body of Knowledge, PMI Publishing Division, Philadelphia, USA.
Reinehr, S.S., Baldwin, R., Machado, C. A. F., Person, M. S. 2003. Implementing ISO / IEC Standard 12207 using Rational Unified Process. Software Engineering Research and Practice.
RUP. 2003. Rational Unified Process, Version 2003.06.00.65, CD-ROM. Rational Software Corporation, Cupert
Nenhum comentário:
Postar um comentário