Projeto e Gestão de Redes de Computadores

Projeto e Gestão de Redes de Computadores

Mapping of Risk Management in PMBOK, RUP and CMMI-SW

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.

• 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.

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.

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.

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)

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.

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.

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

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:

 288
· 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.

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.
· 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

Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP

Mapeamento do Gerenciamento de Riscos

no PMBOK, CMMI-SW e RUP

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.

As the uncertainty is inherent to this kind of problem, risk management has become

more notable in this knowledge area. This paper presents a risk management map

in three models: PMBOK, CMMI e RUP, with the objective of investigate the

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.

Resumo. O desenvolvimento de software é uma atividade complexa, envolvendo

inúmeros fatores, muitas vezes imprevisíveis e difíceis de controlar. Esta

complexidade faz com que grande parte dos projetos de software exceda o prazo e

o orçamento previstos, além de não atender às expectativas do cliente em termos de

funcionalidade e qualidade. Neste contexto, um gerenciamento eficaz é

fundamental para o sucesso de projetos de software. Como a incerteza é inerente a

este tipo de projeto, o gerenciamento de riscos vem-se tornando cada vez mais

relevante nesta área de conhecimento. Este trabalho apresenta um mapeamento do

gerenciamento de riscos descritos em três modelos: PMBOK, CMMI e RUP,

objetivando investigar as similaridades e as divergências entre as abordagens

desses modelos para projetos de software, no sentido de robustecer o processo de

desenvolvimento software.

Palavras-chave: PMBOK, CMMI, RUP, gerenciamento de riscos, qualidade de

software.

1. Introdução

O desenvolvimento de software é uma atividade complexa, envolvendo inúmeros fatores que

não raro são imprevisíveis e de difícil controle, como inovações tecnológicas e mudanças

constantes nos requisitos do cliente, dentre muitos outros. Esta complexidade faz com que

grande parte dos projetos de desenvolvimento de software exceda o prazo e o orçamento

previstos, além de não atender às expectativas do cliente em termos de funcionalidades e

qualidade. Diante deste cenário, um gerenciamento eficaz tem-se evidenciado como de

fundamental importância para o sucesso de projetos de software. Uma vez que a incerteza é

280

inerente a este tipo de projeto, o gerenciamento de riscos vem se tornando cada vez mais

relevante neste contexto.

O gerenciamento de riscos trabalha justamente com a incerteza, visando a

identificação de problemas potenciais e de oportunidades antes que ocorram com o objetivo

de eliminar ou reduzir a probabilidade de ocorrência e o impacto de eventos negativos para os

objetivos do projeto, além de potencializar os efeitos da ocorrência de eventos positivos.

O gerenciamento de riscos é abordado por vários modelos dentre os quais o PMBOK

(2000), o CMMI (2002), e o RUP (2003). O PMBOK (A Guide to the Project Management

Body of Knowledge) trata do gerenciamento de projetos de uma forma ampla, não sendo

específico para software. O CMMI (Capability Maturity Model Integration for Software)

provê um framework para a implantação e melhoria do processo de software das

organizações. O RUP (Rational Unified Process) é um processo baseado em melhores

práticas de engenharia de software.

Este trabalho apresenta um mapeamento do gerenciamento de riscos a partir dos três

modelos citados, objetivando investigar as similaridades e as divergências entre as abordagens

dos mesmos para projetos de software, no sentido de robustecer e melhorar o processo de

desenvolvimento software.

Este trabalho está organizado como se segue. Na seção 2, é apresentada a gerência de

risco do PMBOK; na seção 3, é mostrada a gerência de risco do CMMI; na seção 4, é

delineada a abordagem de gerenciamento de riscos do RUP. Na seção 5, é elaborado o

mapeamento do processo de gerenciamento de risco do PMBOK , CMMI e RUP. Na seção 6,

apresenta-se a conclusão do trabalho.

2. O Gerenciamento de Riscos no PMBOK

O PMBOK (2000) descreve o conhecimento e as melhores práticas em gerenciamento de

projetos. De acordo com o PMBOK, o conhecimento necessário para gerenciar projetos está

dividido em nove áreas: Gerência de Integração, Gerência de Escopo, Gerência de Tempo,

Gerência de Custo, Gerência de Qualidade, Gerência de Recursos Humanos, Gerência de

Comunicação, Gerência de Riscos e Gerência de Aquisições.

A gerência de riscos do projeto inclui os processos referentes ao planejamento da

gerência de riscos, à identificação, à análise, ao planejamento das respostas e ao controle e à

monitoração dos riscos em um projeto. Esses processos interagem entre si e com os processos

das outras áreas do conhecimento. Os objetivos da gerência de risco são aumentar a

probabilidade de ocorrência e os impactos de eventos positivos e diminuir a probabilidade e

os impactos dos eventos adversos aos objetivos do projeto. Os processos da gerência de risco

são [PMBOK, 2000]:

· Planejamento da gerência de riscos: planejar as atividades de gerência de risco a

serem realizadas para o projeto.

· Identificação dos riscos: identificar os riscos que podem afetar o projeto,

documentando suas características.

· Análise qualitativa dos riscos: analisar qualitativamente os riscos, priorizando

seus efeitos no projeto.

281

· Análise quantitativa dos riscos: mensurar a probabilidade de ocorrência dos riscos

e suas conseqüências e estimar as implicações no projeto.

· Planejamento da resposta aos riscos: gerar procedimentos e técnicas para avaliar

oportunidades, objetivando mitigar as ameaças no projeto.

· Monitoração e controle dos riscos: monitorar os riscos residuais, identificar novos

riscos, executar os planos de mitigação de riscos e avaliar sua efetividade durante

todo o cliclo de vida do projeto.

3. O Gerenciamento de Riscos no CMMI-SW

O CMMI-SW (Capability Maturity Model Integration for Software) foi criado para integrar os

diversos modelos CMM, que atendem às várias atividades relacionadas ao desenvolvimento de

software, e ainda torná-lo compatível com a ISO/IEC 15504 (2003). O propósito desta integração é

guiar a avaliação e a melhoria dos processos das organizações e a habilidade para gerenciar o

desenvolvimento, a aquisição e a manutenção de produtos ou serviços.

O CMMI-SW contém duas representações: (i) por estágios, e (ii) contínua. A

representação por estágios, objeto deste trabalho, trata do nível de maturidade da organização

como um todo, contendo cinco níveis de maturidade: inicial, gerenciado, definido,

gerenciado quantitativamente e em otimização. Cada nível é constituído por um conjunto de

áreas de processos, compostas por objetivos específicos e objetivos genéricos. Cada objetivo

específico pode ser composto por um conjunto de práticas específicas.

Um objetivo específico (SG) descreve as características que devem estar presentes

para satisfazer uma área de processo. Uma prática específica (SP) é a descrição de uma

atividade que é considerada importante para se alcançar o objetivo específico a ela associado.

A problemática do risco é abordada nas áreas de processo Planejamento do Projeto,

Monitoração e Controle do Projeto, e Gerência de Risco. As duas primeiras áreas de

processo estão no nível 2 e a última está no nível 3 do CMMI-SW. No Planejamento do

Projeto, tem-se o SG Desenvolvimento do Plano do Projeto com a SP Identificar os Riscos do

Projeto, que consiste na identificação e na análise dos riscos para se determinar o impacto, a

probabilidade de ocorrência e o período em que podem ocorrer, para que os riscos possam ser

priorizados. Na Monitoração e Controle do Projeto, tem-se o SG Monitorar o Projeto de

Acordo com o Plano, onde está inserida a SP Monitorar os Riscos do Projeto.

A Gerência de Risco tem por finalidade identificar potenciais problemas antes que

ocorram, de forma que as atividades de administração desses riscos possam ser planejadas e

realizadas, de acordo com suas necessidades, ao longo do ciclo de vida do produto ou projeto,

para mitigar possíveis impactos adversos. A Tabela 1 apresenta o relacionamento dos

objetivos específicos com suas respectivas práticas específicas para a Gerência de risco.

282

Tabela 1. Relacionamento das SG e SP da Gerência de Risco do CMMI-SW

SG 1 Preparar-se para a Gerência de Riscos

SP 1.1 Determinar Fontes e Categorias de Riscos

SP 1.2 Definir Parâmetros de Riscos

SP 1.3 Estabelecer uma Estratégia para a Gerência de Risco

SG 2 Identificar e Analisar Risco

SP 2.1 Identificar Riscos

SP 2.2 Avaliar, Categorizar, e Priorizar Riscos

SG 3 Mitigar Riscos

SP 3.1 Desenvolver Planos de Mitigação de Riscos

SP 3.2 Implementar Planos de Mitigação de Riscos

As áreas de processo Planejamento do Projeto, e Monitoração e Controle do Projeto,

nível 2, tratam o gerenciamento de riscos de uma forma reativa, focando simplesmente na

identificação dos riscos para a conscientização, e reação à medida que ocorram. Já a área de

processo Gerência de Risco, nível 3, trata o gerenciamento de riscos de uma forma proativa,

descrevendo a evolução das práticas específicas para sistematicamente planejar, antecipar, e

mitigar riscos com o objetivo de minimizar proativamente seu impacto no projeto.

4. O Gerenciamento de Riscos no RUP

O RUP (2003) é um processo de engenharia de software baseado em melhores práticas de

desenvolvimento e em princípios fundamentais, dentre os quais ser direcionado a casos de

uso, centrado na arquitetura, direcionado a riscos e ser iterativo.

Segundo o RUP (2003), os riscos devem ser identificados e atacados o quanto antes

no ciclo de vida do projeto, sempre objetivando a garantia da produção de software de alta

qualidade, de acordo com as necessidades dos usuários e produzidos no tempo e prazo

previstos. Todo projeto tem um conjunto de riscos envolvidos e muitos deles não são

descobertos até que a integração do sistema seja realizada.

Riscos não identificados significam que se pode estar investindo em uma arquitetura

falha ou em um conjunto não otimizado de requisitos. Além disto, a totalidade dos riscos

envolvidos está diretamente relacionada à diferença entre a estimativa de quanto tempo vai

demorar para que o projeto seja concluído. Para se obter estimativas acuradas é necessário

identificar e tratar os riscos antecipadamente.

O RUP possui duas dimensões. A primeira é a dimensão estática que representa a

estrutura estática do processo, descrevendo como os elementos do processo são agrupados

logicamente em disciplinas. Disciplinas são agrupamentos lógicos de papéis, atividades,

artefatos e outros guias para a descrição de um processo, e são representadas por um fluxo de

trabalho. A segunda é a dimensão dinâmica que é representada pelo tempo e expressa o

processo por meio de ciclos, decompostos em fases, que são divididas em iterações com

marcos de conclusão.

O processo de desenvolvimento de software do RUP é iterativo, onde uma iteração

incorpora um conjunto de atividades em modelagem de negócios, requisitos, análise e projeto,

implementação, testes e implantação, em várias proporções, dependendo de onde a iteração

esteja localizada no ciclo de desenvolvimento. Um dos principais benefícios da abordagem

iterativa é a identificação e o tratamento dos principais riscos do projeto em tempo hábil.

283

O gerenciamento de riscos no RUP está inserido na disciplina de Gerenciamento de

Projeto, que se propõe a balancear objetivos concorrentes, gerenciar riscos e restrições, para

que a entrega do produto satisfaça a seus clientes e usuários. Essa disciplina provê um

framework onde o projeto é criado e gerenciado.

O gerenciamento de riscos está integrado ao processo de desenvolvimento, onde as

iterações são planejadas e estão baseadas nos riscos de maior prioridade. Em uma abordagem

iterativa, os riscos são mitigados mais cedo, porque os elementos são integrados progressivamente.

Um vez que cada iteração exercita muitos aspectos do projeto, torna-se mais fácil descobrir até que

ponto os riscos percebidos estão se materializando, como também descobrir novos e insuspeitos

riscos, à medida que os riscos sejam mais fáceis serem localizados e os custos envolvidos são

menores.

No RUP, o ciclo de vida é iterativo e dividido em quatro fases, que enfocam a

problemática do risco de uma maneira cooperativa:

· Concepção: foco no tratamento dos riscos relacionados aos casos de negócio.

· Elaboração: foco principalmente nos riscos técnicos, examinando-se os riscos de

arquitetura e, se necessário, revisando-se o escopo do projeto à medida que seus

requisitos tornam-se melhor compreendidos.

· Construção: foco nos riscos de “logística” e na obtenção da conclusão da maior

parte do trabalho.

· Transição: foco nos riscos associados com a logística de entrega do produto a seu

usuário.

O papel envolvido com o gerenciamento de riscos no RUP é o do gerente do projeto,

que executa as atividades Desenvolver o Plano de Gerenciamento de Riscos, Identificar e

Avaliar Riscos, e Monitorar o Status do Projeto, que têm como entrada ou saída os artefatos

Visão Geral (documento de requisitos), Planos de Gerenciamento de Riscos, e Lista de Riscos.

5. Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP

Esta seção apresenta o mapeamento entre as abordagens de gerenciamento de riscos do

PMBOK (2000), CMMI-SW (2002) e RUP (2003), tendo-se em vista o processo de

desenvolvimento de software, conforme a Tabela 2. Este mapeamento também foi baseado

em Gusmão et al. (2003) e Reinehr et al. (2003). Em seguida, será apresentada uma análise

do relacionamento entre estes modelos.

O PMBOK será usado como base para este mapeamento, através da área de

conhecimento Gerência de Risco, por ser um modelo largamente utilizado, contendo as

melhores práticas para gerenciamento de projetos em geral. Para o CMMI-SW, será utilizada

a área de processo Gerência de Risco, nível 3, com seus objetivos específicos (SG) e práticas

específicas (SP) correspondentes Para o RUP, serão utilizados fluxos de trabalho (workflows)

detalhados (com suas atividades correspondes), pertencentes à disciplina Gerenciamento de

Projeto.

284

Tabela 2. Processos de Gerenciamento de Riscos do PMBOK x CMMI-SW x RUP

PMBOK CMMI-SW RUP

Área:

Gerência de Risco

Área de Processo:

Gerência de Risco

Disciplina:

Gerência de Projetos

Planejamento da

Gerência de Riscos

Preparar-se para a Gerência dos Riscos (SG 1):

· Determinar Fontes e Categorias de Riscos (SP

1.1)

· Definir Parâmetros de Riscos (SP 1.2)

· Estabelecer uma Estratégia para Gerência de

Risco (SP 1.3)

Planejamento do Projeto

· Desenvolver o Plano de

Gerenciamento de Riscos

Identificação dos

Riscos

Identificar e Analisar Risco (SG 2)

· Identificar Riscos (SP 2.1)

Avaliar o Escopo do Projeto e

os Riscos

· Identificar e Avaliar os

Riscos

Análise Qualitativa

dos Riscos

Identificar e Analisar Risco (SG 2)

· Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

Avaliar o Escopo do Projeto e

os Riscos

· Identificar e Avaliar os

Riscos

Análise Quantitativa

dos Riscos

Identificar e Analisar Risco (SG 2)

· Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

Avaliar o Escopo do Projeto e

os Riscos

· Identificar e Avaliar os

Riscos

Planejamento das

Respostas aos Riscos

Mitigar Riscos (SG 3)

· Desenvolver Planos de Mitigação de Riscos

(SP 3.1)

Avaliar o Escopo do Projeto e

os Riscos

· Identificar e Avaliar os

Riscos

Monitoração e

Controle dos Riscos

Mitigar Riscos (SG 3)

· Implementar os Planos de Mitigação de Riscos

(SP 3.2)

Monitorar e Controlar o Projeto

· Monitorar o Status do

Projeto

5.1. Planejamento da Gerência de Riscos

O Planejamento da Gerência de Riscos no PMBOK é o processo de decidir como abordar e

conduzir as atividades da gerência de riscos para um projeto. Isto é importante para assegurar

que o nível, o tipo e a visibilidade da gerência de riscos sejam proporcionais ao risco e à

importância do projeto para a organização. Isto garantirá também recursos e prazos

suficientes para as atividades da gerência de risco, estabelecendo uma base consensual para a

avaliação dos riscos. O resultado desse processo é o Plano de Gerenciamento de Riscos, que

descreve como o gerenciamento deverá ser estruturado e executado no projeto.

No CMMI-SW, a preparação para a Gerência de Riscos é conduzida através do

estabelecimento e da manutenção de uma estratégia para identificar, analisar e mitigar riscos.

Normalmente, isto é documentado em um Plano de Gerenciamento de Riscos. A estratégia da

gerência de risco refere-se às ações específicas e à abordagem gerencial usadas para aplicar e

controlar o programa da gerência de risco. Isto inclui identificar as fontes do risco, o esquema

usado para categorizar riscos, e os parâmetros usados para avaliar, limitar e controlar riscos

para uma manipulação eficaz.

No RUP, o Plano de Gerenciamento de Riscos é um artefato de saída da atividade

Desenvolver o Plano de Gerenciamento de Riscos, que pertence ao fluxo de trabalho

detalhado Planejamento do Projeto. Essa atividade tem como objetivo criar um plano

documentado para identificação, análise e priorização dos riscos e identificar as estratégias de

gerenciamento para os riscos mais relevantes do projeto.

285

As três abordagens apontam para a necessidade de se planejar o gerenciamento dos

riscos de forma semelhante. No entanto, o RUP trata o gerenciamento de riscos como

essencial apenas para projetos maiores ou de alto risco, e o coloca como opcional para

projetos menores, onde seria suficiente a apenas elaboração da Lista de Riscos.

5.2. Identificação dos Riscos

A Identificação de Riscos no PMBOK envolve a determinação de quais riscos podem ocorrer

em um projeto em particular, determinar quais deles podem afetar esse projeto e documentar

suas características. Trata-se de um processo iterativo, porque novos riscos podem surgir

durante o ciclo de vida do projeto. A freqüência das iterações e de quem deve participar de

cada ciclo varia caso a caso. A equipe do projeto deve estar envolvida de forma a desenvolver

um senso de responsabilidade pelos riscos e tomar as ações necessárias.

O processo de Identificação de Riscos relaciona-se bastante com o processo de

Análise Qualitativa dos Riscos. Alternativamente, esse processo pode-se relacionar

diretamente com o processo de Análise Quantitativa dos Riscos, quando conduzido por um

gerente com experiência em riscos. Em alguns casos a simples identificação do risco já sugere

respostas a estes, e que devem ser registradas para posterior análise e implementação no

processo de Planejamento das Respostas aos Riscos.

Para o CMMI-SW, a identificação de potenciais situações, perigos, ameaças e

vulnerabilidades, que poderiam afetar negativamente os esforços ou planos de trabalho, é a

base para a gerência de risco bem sucedida. Os riscos devem ser identificados e

documentados em uma linguagem concisa, que inclua o contexto, as condições e as

conseqüências de sua ocorrência, para que possam ser analisados e controlados corretamente.

O uso de categorias e parâmetros desenvolvidos na estratégia de gerenciamento dos riscos,

juntamente com as fontes identificadas de risco, pode fornecer disciplina e otimização

apropriadas à identificação do risco.

Os riscos identificados formam uma base para o inicio das atividades de

gerenciamento de riscos. A lista dos riscos deve ser revista periodicamente, para que se

identifiquem novas possíveis fontes de riscos e de mudanças nos riscos identificados

anteriormente, ou mesmo riscos que foram negligenciados ou não existiam quando a

estratégia da gerência de risco foi elaborada. O produto da prática específica Identificar

Riscos, pertencente ao objetivo específico Identificar e Analisar Risco, é a lista dos riscos

identificados, incluindo o contexto, as condições e as conseqüências da ocorrência do risco.

A atividade Identificar e Avaliar Riscos do RUP tem o propósito de identificar,

analisar e priorizar os riscos para o projeto e determinar as estratégias apropriadas de

gerenciamento de riscos. Os seguintes passos dessa atividade estão diretamente ligados com a

identificação dos riscos:

· Identificar Riscos Potenciais: tem o objetivo de criar e manter atualizada a lista de

riscos.

· Rever Riscos durante a Iteração: tem o objetivo de verificar o que mudou.

· Rever Riscos no Final de uma Iteração: objetiva eliminar riscos que tenham sido

totalmente mitigados e introduzir riscos recentemente descobertos.

A lista de Riscos, que é o produto da atividade Identificar e Avaliar Risco, é um

artefato fundamental para o RUP, pois serve como um ponto focal para as atividades do

286

projeto e é a base em torno da qual as iterações são organizadas. O risco direciona os planos

das iterações, que são voltadas para o tratamento de riscos específicos, tentando eliminá-los

ou reduzi-los. A lista de riscos deve ser revista periodicamente, para avaliar a eficácia das

estratégias de mitigação do risco, que, por sua vez, conduzem a revisões do plano do projeto e

dos planos das iterações subseqüentes.

Verifica-se que as três abordagens mantêm uma forte sintonia no que se refere ao

processo de identificação dos riscos. Todas enfatizam que a identificação dos riscos deve ser

feita de forma iterativa durante o ciclo de vida do projeto, que deve haver o envolvimento da

equipe do projeto e que é um processo fundamental para o gerenciamento do projeto como

um todo. A lista de risco é o produto do processo em todas as abordagens em questão,

enfatizando a importância de mantê-la sempre atualizada.

5.3. Análise Qualitativa dos Riscos

A Análise Qualitativa dos Riscos no PMBOK é geralmente um meio rápido de estabelecer

prioridades para o planejamento da resposta do risco, além de fornecer a base para a análise

quantitativa do risco, se esta for requerida. Esse processo avalia a prioridade dos riscos

identificados, usando sua probabilidade de ocorrência e o impacto correspondente nos

objetivos do projeto, se os riscos ocorrerem.

As definições dos níveis de probabilidade e de impacto, as entrevistas com peritos e a

avaliação da qualidade da informação disponível no projeto podem ajudar a corrigir as

polarizações, que estão freqüentemente presentes nos dados usados neste processo. A análise

qualitativa do risco deve ser revista durante o ciclo de vida do projeto, para ficar atualizada de

acordo com as mudanças nos riscos do projeto.

No CMMI-SW, a análise qualitativa dos riscos está especificada na prática específica

Avaliar, Categorizar e Priorizar Riscos, que pertence ao objetivo específico Identificar e

Analisar Risco. A avaliação e a categorização de cada risco identificado é feita utilizando-se

as categorias e os parâmetros de riscos e, a seguir, sua prioridade é determinada. Os

parâmetros de riscos definidos podem incluir a probabilidade, a conseqüência (severidade ou

impacto) e os limites. Os valores de parâmetro atribuídos ao risco podem ser integrados para

produzir medidas adicionais, tais como a exposição ao risco, que pode ser usada para priorizar

os riscos.

A avaliação dos riscos é necessária para se determinar a importância relativa de cada

risco identificado, sendo usada na determinação de quando a atenção apropriada da gerência é

requerida. O produto de trabalho desta prática é a lista de riscos com sua respectiva

prioridade.

A atividade Identificar e Avaliar Riscos do RUP tem o propósito de identificar,

analisar e priorizar os riscos para o projeto e determinar as estratégias apropriadas de

gerenciamento de riscos. Os seguintes passos dessa atividade estão diretamente ligados com a

análise dos riscos:

· Analisar e Priorizar Riscos: consiste em combinar riscos similares (para reduzir o

tamanho da Lista de riscos) e em classificá-los em termos de seu impacto no

projeto.

287

· Rever Riscos durante a Iteração: objetiva garantir que a lista de riscos é mantida

atualizada no decorrer do projeto, inclusive no que se refere à priorização dos

riscos.

· Rever Riscos no Final de uma Iteração: reavalia a magnitude e reordena os riscos

após a eliminação dos riscos mitigados, e também introduz novos riscos à lista de

riscos.

Uma vez mais é verificado que as três abordagens mantêm uma alta sinergia no que

se refere ao processo de Análise Qualitativa dos Riscos. Todas ressaltam a importância de se

determinar a probabilidade e o impacto da ocorrência do risco, a categorização desses riscos e

a atualização contínua da lista de riscos. Porém, deve-se observar que o PMBOK divide a

análise dos riscos em análise qualitativa e análise quantitativa, enquanto as outras abordagens

não fazem esta distinção. Sendo assim, o PMBOK dá um tratamento mais elaborado à análise

de riscos.

5.4. Análise Quantitativa dos Riscos

A Análise Quantitativa dos Riscos no PMBOK objetiva analisar numericamente a

probabilidade de cada risco identificado e sua conseqüência para os objetivos do projeto.

Apresenta também uma abordagem quantitativa para a tomada de decisões na presença da

incerteza, utilizando técnicas tais como a análise da árvore de decisão e a simulação de Monte

Carlo (PMBOK, 2000).

Este processo geralmente segue-se à análise qualitativa dos riscos, embora gerentes

com experiência em riscos tendem, às vezes, a executá-lo diretamente após a identificação do

risco. Em alguns casos, a análise quantitativa do risco pode não ser requerida para

desenvolver respostas efetivas ao risco. A disponibilidade de tempo e de orçamento e a

necessidade de declarações qualitativa ou quantitativa sobre o risco e seus impactos

determinarão quais métodos devem ser usados para um projeto particular.

No CMMI-SW, a análise quantitativa dos riscos é referenciada na prática específica

Avaliar, Categorizar e Priorizar Riscos, na subprática Avaliar os Riscos Identificados,

utilizando os parâmetros definidos, que requerem que cada risco seja avaliado e receba uma

atribuição de valores, segundo parâmetros definidos para o mesmo. Esses parâmetros podem

ser agregados e produzirem medidas adicionais, tais como a exposição ao risco, que pode ser

usada para priorizá-los.

Geralmente, uma escala com três a cinco valores é usada para avaliar a probabilidade

e a conseqüência do risco. Valores prováveis são usados freqüentemente para quantificar a

probabilidade. As conseqüências são relacionadas geralmente ao custo, ao cronograma, ao

impacto ambiental ou às medidas humanas (tais como as horas de trabalho perdidas e a

severidade do dano). Esta avaliação é freqüentemente uma tarefa difícil, e que consome

tempo. Especialidades ou técnicas específicas do grupo podem ser necessárias para avaliar os

riscos e ganhar a confiança no momento de priorizá-los.

No RUP, a análise quantitativa dos riscos é referenciada também na atividade

Identificar e Avaliar Riscos onde é enfatizado que os riscos sejam priorizados de acordo com

a exposição geral que o mesmo representa para o projeto de software. Para determinar a

exposição de cada risco deve haver a estimativa das seguintes informações:

288

· Impacto do risco: desvios do planejamento referentes a cronograma, esforço ou

custos, caso o risco ocorra.

· Probabilidade de ocorrência: probabilidade de que o risco realmente ocorra

(geralmente expressa como porcentagem)

· Exposição ao risco: produto do impacto pela probabilidade de ocorrência.

No processo de Análise Qualitativa dos Riscos, nota-se que o PMBOK é mais

completo, especificando vários itens a serem quantificados, ferramentas e técnicas a serem

utilizadas, prevendo a atualização da lista de riscos contendo os seguintes itens:

· análise probabilística do projeto;

· probabilidade de alcançar os objetivos de custo e tempo;

· lista priorizada de riscos quantificados;

· tendências nos resultados da análise quantitativa dos riscos.

5.5. Planejamento das Respostas aos Riscos

O Planejamento das Respostas aos Riscos é o processo de desenvolver opções e de

determinar ações para ampliar oportunidades e reduzir ameaças aos objetivos do projeto.

Segue os processos de Análise Qualitativa dos Riscos e Análise Quantitativa dos Riscos.

Inclui a identificação e a atribuição dos indivíduos ou grupos que irão se responsabilizar por

cada resposta ao risco planejada e insere recursos e tarefas no orçamento, no cronograma e no

plano de gerenciamento do projeto, se necessário.

Este processo deve ser apropriado à gravidade do risco, pesar os custos com relação

aos desafios enfrentados, considerar a oportunidade de ter êxito, ser realístico dentro do

contexto do projeto e ser aceito por todas as partes envolvidas. Às vezes, é necessário

selecionar a melhor resposta ao risco de diversas opções disponíveis.

Para o CMMI-SW, as etapas do tratamento de riscos incluem desenvolver opções de

tratamento de riscos, monitoração de riscos e execução das atividades de tratamento, quando

os limites definidos forem excedidos. Os planos de mitigação de riscos são desenvolvidos e

executados, para que o impacto potencial da ocorrência dos riscos selecionados sejam

proativamente reduzidos. Isto pode também incluir planos de contingência, para tratar do

impacto dos riscos selecionados, que podem ocorrer apesar das tentativas de mitigá-los.

Os parâmetros usados para disparar as atividades de tratamento do risco são definidos

pela estratégia da gerência de risco. O plano de mitigação para um risco inclui técnicas e

métodos usados para evitar, reduzir e controlar a probabilidade de sua ocorrência, e a

extensão dos danos causados caso ocorra (plano de contingência). Os planos de mitigação e

de contingência do risco freqüentemente são gerados somente para os riscos selecionados,

onde as conseqüências dos riscos são determinadas como elevadas ou inaceitáveis. Outros

riscos podem ser aceitos e simplesmente monitorados. As opções para o tratamento de riscos

normalmente incluem alternativas como:

· Anulação de riscos: mudar ou baixar requisitos enquanto ainda atender as

necessidades dos usuários.

· Controle de riscos: tomar atitudes para minimizar riscos.

· Transferência de riscos: rever os requisitos de projeto para baixar riscos.

289

· Monitoração de riscos: periodicamente reavaliar os riscos para identificar

possíveis mudanças nos parâmetros atribuídos aos riscos.

A atividade Identificar e Avaliar Riscos no RUP tem o propósito de identificar,

analisar e priorizar os riscos para o projeto e determinar as estratégias apropriadas de

gerenciamento de riscos. Os seguintes passos dessa atividade estão diretamente ligados com o

planejamento da resposta aos riscos:

· Identificar Estratégias para Evitar Riscos: tem o propósito de reorganizar o

projeto para eliminar riscos.

· Identificar Estratégias para Mitigar Riscos: desenvolve planos de mitigação do

risco para reduzir o impacto dos riscos.

· Identificar Estratégias de Contingência: gera planos alternativos, que devem

conter o indicador do risco e ação a ser tomada caso ele ocorra.

Todas as abordagens têm uma grande similaridade no que se refere ao processo de

Planejamento das Respostas aos Riscos. Todas tratam das estratégias para lidar com o risco

através de sua eliminação, aceitação ou transferência, da elaboração do plano de mitigação e

do plano de contingência. Em todas as abordagens, há a atualização da lista de riscos com a

inclusão dos planos, dos responsáveis pelo risco, dos sinais de aviso de que o risco irá ocorrer

e a atualização do plano do projeto em função das respostas selecionadas.

5.6. Monitoração e Controle dos Riscos

A Monitoração e Controle dos Riscos é o processo de identificar, analisar e planejar os novos

riscos que surgem, acompanhando os riscos identificados e aqueles na lista de observação,

monitorando as “condições de disparo” dos planos de contingência, monitorando riscos

residuais e revendo a execução da resposta ao risco ao avaliar sua eficácia.

Este processo aplica novas ferramentas, tais como a análise de variação e tendência,

que requerem o uso de dados de desempenho gerados durante a execução do projeto. Este

processo pode envolver a escolha de estratégias alternativas, a implementação de um plano de

contingência ou emergência, a tomada de ações corretivas ou o replanejamento do projeto.

Inclui também, a inclusão de lições aprendidas nas bases de dados do projeto e modelos da

gerência de risco para o benefício dos projetos futuros.

O CMMI-SW determina que para controlar e gerenciar eficazmente os riscos durante

o esforço de trabalho, deve ser seguido um programa proativo para monitorar regularmente os

riscos e o status, além dos resultados das ações de acompanhamento dos riscos. A estratégia

da gerência de riscos define os intervalos em que o status do risco deve ser revisado. Isto pode

resultar na descoberta de novos riscos ou de novas opções de manipulação, que podem

requerer o re-planejamento e a reavaliação. Em ambos os eventos, os limites de aceitação

associados com o risco devem ser comparados com o status, para determinar a necessidade de

execução do plano de mitigação de riscos. A prática específica de que trata esta monitoração é

Implementar Planos de Mitigação de Riscos.

No RUP, a atividade Monitorar o Status do Projeto é composta dos seguintes passos:

· Capturar o Status do Trabalho: coleta informações de qualidade e progresso do

projeto para avaliação do status atual.

· Derivar Indicadores de Progresso: avalia apropriadamente o progresso do projeto

com relação aos planos.

290

· Derivar Indicadores de Qualidade: usa métricas de qualidade.

· Avaliar Indicadores x Planos: compara o estado esperado do projeto de acordo

com o que foi definido no Plano de Desenvolvimento e no Plano da Iteração.

Todas as abordagens indicam fortemente que os riscos devem ser monitorados e

controlados durante todo o ciclo de vida do projeto através da reavaliação dos riscos e do

acompanhamento dos indicadores.

6. Conclusão

Este trabalho apresentou um mapeamento do gerenciamento de riscos a partir do PMBOK,

CMMI, e RUP, com o objetivo de investigar similaridades e divergências entre as abordagens

dos mesmos para projetos de software.

A partir desse mapeamento, verificou-se que o gerenciamento de riscos nesses

modelos está em consonância em seus aspectos essenciais, não havendo nenhuma

incompatibilidade fundamental entre eles. Isto comprova a importância da gerência de riscos

para os projetos de software, particularmente por dar um tratamento adequado às incertezas, e

promover a melhoria dos processos de software.

Apenas o processo de Análise Quantitativa dos Riscos do PMBOK não é descrito

separadamente no CMMI ou no RUP. Como no PMBOK esta prática é tratada como um

processo, há uma maior clareza sobre como ela deve ser conduzida. Além disto, são sugeridos

elementos a serem incluídos na lista de riscos, que não são considerados nos demais modelos.

Como o foco do PMBOK é especificamente o gerenciamento de projetos, ele oferece

um maior detalhamento no que se refere às descrições das entradas, ferramentas e técnicas

sugeridas e saídas. Porém, como não se trata de um modelo específico para software, falta a

ligação explícita com as especificidades ao longo do processo de desenvolvimento de

software.

Referências

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.

Gusmão, 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., Balduino, R., Machado, C. A. F., Pessoa, M. S. 2003. Implementing ISO/IEC

12207 Standard using Rational Unified Process. Software Engineering Research and

Practice.

RUP. 2003. Rational Unified Process, Version 2003.06.00.65, CD-ROM. Rational Software

Corporation, Cupertino, California, 2003.