Rational Unified Process

Rational Unified Process

O Valor do Software O software é um parte indispensável no mundo moderno Faz com que as sociedades se conectem melhor Nos ajuda a criar, acessar e visualizar informação em formas e modos não concebíveis anteriormente. Boa notícia A economia mundial depende cada vez mais de software. Notícia ruim O pessoal qualificado não consegue acompanhar o mesmo ritmo da demanda. Softwares estão crescendo em importância, tamanho, complexidade e distribuição. Resultado A construção e manutenção de software são difíceis.

Sintomas e Origem das Causas de Problemas de Desenvolvimento de Software
Entendimento impreciso das necessidades dos usuários Falta de habilidade de lidar com a necessidade de mudanças Uma descoberta tardia de uma séria falha de projeto Software com baixa qualidade Um processo não confiável de construção Arquitetura frágil Testes insuficientes Falha no ataque aos riscos

Processo de Engenharia
Define quem irá fazer o que, quando, e como será alcançado o objetivo. Processo de Engenharia de Software Requisitos novos ou alterados Sistema novo ou melhorado

Processo Regras Prover um guia para as atividades
Especificar que artefatos e quando devem ser desenvolvidos Direcionar as tarefas dos grupos e indivíduos Oferecer um critério para monitorar e medir o processo

Melhores Práticas Desenvolver software iterativamente
Gerenciar requisitos Usar arquiteturas baseadas em componentes Modelar o software visualmente Verificar continuamente a qualidade do software Controlar as alterações no software

Best Practices

RUP Um processo de engenharia de software
Um framework para outros processos Utiliza as 6 melhores práticas de desenvolvimento de software

RUP RUP é uma abordagem dirigida por caso de uso (use-case driven)
Casos de uso dirigem inumerosas atividades Criação e validação dos modelos de projeto Definição dos casos de teste no modelo de teste Planejamento de iterações Criação do manual do usuário Processo centrado na arquitetura

Histórico 2000 1999 1998 1997 1996 1995 Rational Unified Process 2000
UML 1.3 Rational Unified Process 5.0 1998 UML 1.2 Rational Objectory Process 4.1 1997 UML 1.1 Rational Objectory Process 4.0 1996 UML 0.8 Rational Approach Objectory Process 3.8 1995

RUP End_user Functionality Programmers Software Management Implemation
View Logical View Use-Case View Analysts/Tester Behavior Deployment View Process View System Integrator Performance Scalability Throughput System Engineering System Topology Delivery, Installation Communication

Visão Geral Concepção – onde são estabelecidos lógica do domínio da aplicação e escopo do projeto Elaboração – coleta de requisitos mais detalhados, análise e plano para construção do sistema Construção – consiste de várias iterações Transição – teste, ajuste de performance e treinamento de usuário

RUP - Melhores Práticas
Desenvolvimento Iterativo Gerência de Requisitos Arquitetura Baseada em Componentes Modelagem Visual Verificação Contínua da Qualidade Gerência de Mudanças

Desenvolvimento Iterativo
O que é desenvolvimento iterativo Desenvolvimento em Cascata Desenvolvimento Iterativo A project using iterative development has a lifecycle consisting of several iterations. An iteration incorporates a loosely sequential set of activities in business modeling, requirements, analysis and design, implementation, test, and deployment, in various proportions depending on where in the development cycle the iteration is located. Iterations in the inception and elaboration phases focus on management, requirements, and design activities; iterations in the construction phase focus on design, implementation, and test; and iterations in the transition phase focus on test and deployment. Iterations should be managed in a timeboxed fashion, that is, the schedule for an iteration should be regarded as fixed, and the scope of the iteration's content actively managed to meet that schedule. An initial design is likely to be flawed with respect to its key requirements. Late discovery of design defects results in costly over-runs and, in some cases, even project cancellation. All projects have a set of risks involved. The earlier in the lifecycle you can verify that you've avoided a risk, the more accurate you can make your plans. Many risks are not even discovered until you've attempted to integrate the system. You will never be able to predict all risks regardless of how experienced the development team is.

Teste Requisitos Análise & Projeto Modelagem de Negócio Implementação Deployment Avaliação Teste

Vantagens Os riscos são atacados mais cedo Mudanças nos requisitos Refinamento de arquitetura Aprendizado e aprimoramento Aumento do reuso Mitigating risks An iterative approach lets you mitigate risks earlier, because many risks are only addressed and discovered during integration. As you unroll the early iteration, you go through all disciplines, exercising many aspects of the project: tools, off-the-shelf software, people skills, and so on. Perceived risks may prove not to be risks, and new, unsuspected risks will show up. Integration is not one "big bang" at the end—elements are incorporated progressively. In reality, the iterative approach is an almost continuous integration. What used to be a long, uncertain, and difficult time—taking up to 40% of the total effort at the end of a project—and what was hard to plan accurately, is divided into six to nine smaller integrations that start with far fewer elements to integrate. Accommodating changes The iterative approach lets you take into account changing requirements as they will normally change along the way. Changes in requirements and requirements "creep" have always been primary sources of trouble for a project, leading to late delivery, missed schedules, unsatisfied customers, and frustrated developers. Twenty-five years ago, Fred Brooks wrote: "Plan to throw one away, you will anyhow." Users will change their mind along the way. This is human nature. Forcing users to accept the system as they originally imagined it is wrong. They change their minds because the context is changing—they learn more about the environment and the technology, and they see intermediate demonstration of the product as it's being developed. An iterative lifecycle provides management with a way of making tactical changes to the product. For example, to compete with existing products, you may decide to release a reduced-functionality product earlier to counter a move by a competitor, or you may adopt another vendor for a given technology. Iteration also allows for technological changes along the way. If some technology changes or becomes a standard as new technology appears, the project can take advantage of it. This is particularly the case for platform changes and lower-level infrastructure changes. Reaching higher quality An iterative approach results in a more robust architecture because errors are corrected over several iterations. Early flaws are detected as the product matures during the early iterations. Performance bottlenecks are discovered and can be reduced, as opposed to being discovered on the eve of delivery. Developing iteratively, as opposed to running tests once toward the end of the project, results in a more thoroughly tested product. Critical functions have had many opportunities to be tested over several iterations, and the tests themselves, and any test software, have had time to mature. Learning and improving Developers can learn along the way, and the various competencies and specialties are more fully employed during the whole lifecycle. Rather than waiting a long time just making plans and honing their skills, testers start testing early, technical writing starts early, and so on. The need for additional training or external help can be detected in the early iteration assessment reviews. The process itself can be improved and refined as it develops. The assessment at the end of an iteration not only looks at the status of the project from a product-schedule perspective, but also analyzes what needs to be changed in the organization and the process to perform better in the next iteration. Increasing reuse An iterative lifecycle facilitates reuse. It's easier to identify common parts as they are partially designed or implemented, compared to having to identify all commonality up front. Identifying and developing reusable parts is difficult. Design reviews in early iterations allow software architects to identify unsuspected, potential reuse, and subsequent iterations allow them to further develop and mature this common code. Using an iterative approach makes it easier to take advantage of commercial-off-the-shelf products. You have several iterations to select them, integrate them, and validate that they fit with the architecture.

Gerência de Requisitos
Dificuldades Requisitos não são óbvios Requisitos não são sempre facilmente epresso em palavras Existem vários tipos de requisitos em diferentes níveis de detalhes O número de requisitos pode explodir Requisitos estão interligados Existem várias pessoas interessadas nos requisitos Requisitos mudam.

Gerência de Requisitos
Atacando Analisando o problema Entendendo as necessidades dos “stakeholders” Definindo o sistema Gerenciando o escopo do projeto Refinando a definição do sistema Gerenciando mudança de requisitos Analyzing the problem Problems are analyzed to understand problems and initial stakeholder needs, and to propose high-level solutions. It's an act of reasoning and analysis to find "the problem behind the problem". During problem analysis, agreement is gained on what the real problems are and on who the stakeholders are. From a business perspective you also define the boundaries of the solution and any business constraints on the solution. The business case for the project must also be analyzed so there is a good understanding of what return is expected on the investment made in the system being built. Understanding stakeholder needs Requirements come from many sources; for example, customers, partners, end users, and domain experts. You need to know how to determine what the best sources should be, how to access those sources, and how to elicit information from them most effectively. The individuals who provide the primary sources for this information are referred to as stakeholders in the project. If you’re developing an information system to be used internally within your company, you may include people with end-user experience and business domain expertise in your development team. Very often you will start the discussions at a business model level rather than at a system level. If you’re developing a product to be sold to a specific marketplace, you may make extensive use of your marketing people to better understand the needs of customers in that market. Elicitation activities may occur using techniques such as interviews, brainstorming, conceptual prototyping, questionnaires, and competitive analysis. The result of the elicitation is a list of requests or needs that are described textually and graphically, and that have been given priority relative to one another. Defining the system Defining the system means translating and organizing the understanding of stakeholder needs into a meaningful description of the system to be built. Early in system definition, decisions are made about what constitutes a requirement, documentation format, language formality, degree of requirements specificity (how many and in what detail), request priority and estimated effort (two very different valuations usually determined by different people in separate exercises), technical and management risks, and initial scope. Part of this activity may include early prototypes and design models directly related to the most important stakeholder requests. The outcome of system definition is a description of the system that uses both natural language and graphical representations. Managing the scope of the project To efficiently run a project, you need to carefully prioritize the requirements based on input from all stakeholders and manage its scope. Too many projects suffer from developers working on so called "Easter eggs" (features the developer finds interesting and challenging), rather than early focusing on tasks that mitigate a risk to the project or stabilize the architecture of the application. Make sure that you resolve or mitigate risks in a project as early as possible, by developing your system incrementally, carefully choosing requirements for each increment that mitigates known risks in the project. This means you need to negotiate the scope of each iteration with the project's stakeholders. Typically this requires good skills in managing expectations of the output from the project in its different phases. You also need to control the sources of the requirements, how the deliverables of the project look, as well as the development process itself. Refining the system definition The detailed definition of the system needs to be presented in such a way that your stakeholders can understand, agree to, and sign off on them. It needs to cover not only functionality, but also compliance with any legal or regulatory requirements, usability, reliability, performance, supportability, and maintainability. A frequent error is believing that what you feel is complex to build, needs to have a complex definition. This leads to difficulties in explaining the purpose of the project and the system. People may be impressed, but they will not give good input because they don’t understand. Special attention needs to be given to understanding the audience for whom the artifacts are being produced; often, different kinds of description are needed for different audiences. We have seen that the use-case methodology, often in combination with simple visual prototypes, is a very efficient way of communicating the purpose and defining the details of the system. Use cases help put requirements into a context; they tell a story of how the system will be used. Another component of the detailed definition of the system is to state how the system should be tested. Test plans and definitions of what tests to perform tell us what system capabilities will be verified. Managing changing requirements No matter how carefully you've defined your requirements, there will always be things that change. What makes changing requirements complex to manage is not only that a changed requirement means that time has to be spent on implementing a particular new feature, but also that a change to one requirement may have an impact on other requirements. You need to make sure that you give your requirements a structure that is resilient to changes, and you need to use traceability links to represent dependencies between requirements and other artifacts of the development lifecycle. Managing change includes such activities as establishing a baseline, determining which dependencies are important to trace, establishing traceability between related items, and implementing change control.

Arquitetura Baseada em Componentes
Desenvolvimento Baseado em Componentes Definem uma arquitetura modular Desenvolvidos para reuso Arquiteturas e componentes prontos

Suporte ao Desenvolvimento Baseado em Componentes Com o processo itrativo Baseado na arquitetura Através da UML - com pacotes, camadas e subsistemas Testes graduais A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, all of which fulfill a clear function, have a clear boundary, and can be integrated in a well-defined architecture. It's the physical realization of an abstraction in your design. Components come from different places: In defining a very modular architecture, you identify, isolate, design, develop, and test well-formed components. These components can be individually tested and gradually integrated to form the whole system. Furthermore, some of these components can be developed to be reusable, especially the components that provide common solutions to a wide range of common problems. These reusable components, which may be larger than just collections of utilities or class libraries, form the basis of reuse within an organization, increasing overall software productivity and quality. More recently, the advent of commercially successful, component infrastructures—such as CORBA, the Internet, ActiveX, and JavaBeans—trigger a whole industry of off-the-shelf components for various domains, allowing you to buy and integrate components rather than developing them all in-house. The first point in the preceding list exploits the old concepts of modularity and encapsulation, bringing those concepts underlying object-oriented technology a step further. The last two points in the list shift software development from programming software a line at time, to composing software by assembling components. The RUP supports component-based development in these ways: The iterative approach allows you to progressively identify components, and decide which ones to develop, which ones to reuse, and which ones to buy. The focus on software architecture allows you to articulate the structure—the components and the ways in which they integrate—which include the fundamental mechanisms and patterns by which they interact. Concepts, such as packages, subsystems, and layers, are used during Analysis & Design to organize components and to specify interfaces. Testing is first organized around components, then gradually around larger sets of integrated components.

Modelagem Visual

Modelagem Visual Ajuda a entender sistemas complexos
Explora e compara alterntivas a um preço baixo Forma uma base para a implementação Facilita a captura dos requisitos Comunica as decisões sem ambiguidades Aiding understanding of complex systems The importance of models increases as systems become more complex. For example, a doghouse can be constructed without blueprints. However, as one progresses to houses, and then to skyscrapers, the need for blueprints becomes pronounced. Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an e-commerce system with tens of thousands of source lines of code (SLOCs)—or an air traffic control system with hundreds of thousands of SLOCs—can no longer be easily understood by one person. Constructing models allows a developer to focus on the big picture, understand how components interact, and identify fatal flaws. Exploring and comparing design alternatives at a low cost Simple models can be created and modified at a low cost to explore design alternatives. Innovative ideas can be captured and reviewed by other developers before investing in costly code development. When coupled with iterative development, visual modeling helps developers to assess design changes and communicate these changes to the entire development team. Forming a foundation for implementation Today many projects employ object-oriented programming languages to obtain reusable, change-tolerant, and stable systems. To obtain these benefits, it's even more important to use object technology in design. The Rational Unified Process (RUP) produces an object-oriented design model that is the basis for implementation. With the support of appropriate tools, a design model can be used to generate an initial set of code for implementation. This is referred to as "forward engineering" or "code generation". Design models may also be enhanced to include enough information to build the system. Reverse engineering may also be applied to generate design models from existing implementations. This may be used to evaluate existing implementations. "Round trip engineering" combines both forward and reverse engineering techniques to ensure consistent design and code. Combined with an iterative process, and the right tools, round-trip engineering allows design and code to be synchronized during each iteration. Capturing requirements precisely Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements. A model that separates the external behavior of the system from the implementation helps you focus on the intended use of the system, without getting bogged down in implementation details. Communicating decisions unambiguously The RUP uses the Unified Modeling Language (UML), a consistent notation that can be applied for system engineering as well as business engineering.

Verificação Contínua da Qualidade

O que é qualidade? "...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements—as measured by agreed-on measures and criteria—and that is produced by an agreed-on process."

O que é qualidade? Onde está a qualidade? Gerência da qualidade no RUP Identificar metricas Identificar medidas Identificar os pontos que afetam a qualidade o quanto antes Definition of Quality The definition of quality, taken from The American Heritage Dictionary of the English Language, 3rd Edition, Houghton Mifflin Co.,© 1992, 1996, is: Quality (kwol'i-te) n., pl. -ties. Abbr. qlty. 1.a. An inherent or distinguishing characteristic; a property. b. A personal trait, especially a character trait. 2. Essential character; nature. 3.a. Superiority of kind. b. Degree or grade of excellence. As demonstrated by this definition, quality is not a single dimension, but many. To use the definition and apply it to software development, the definition must be refined. Therefore, for the purposes of the Rational Unified Process (RUP), quality is defined as: "...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements—as measured by agreed-on measures and criteria—and that is produced by an agreed-on process." Achieving quality is not simply "meeting requirements", or producing a product that meets user needs and expectations. Rather, quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process has achieved the desired degree of quality, and can be repeated and managed. Who Owns Quality? A common misconception is that quality is owned by, or is the responsibility of, one group. This myth is often perpetuated by creating a group, sometimes called Quality Assurance—other names include Test, Quality Control, and Quality Engineering—and giving them the charter and the responsibility for quality. Quality is, and should be, the responsibility of everyone. Achieving quality must be integral to almost all process activities, instead of a separate discipline, thereby making everyone responsible for the quality of the products (or artifacts) they produce and for the implementation of the process in which they are involved. Each role contributes to the achievement of quality in the following ways: Product quality—the contribution to the overall achievement of quality in each artifact being produced. Process quality—the achievement of quality in the process activities for which they are involved. Everyone shares in the responsibility and glory for achieving a high-quality product, or in the shame of a low-quality product. But only those directly involved in a specific process component are responsible for the glory, or shame, for the quality of those process components (and the artifacts). Someone, however, must take the responsibility for managing quality; that is, providing the supervision to ensure that quality is being managed, measured, and achieved. The role responsible for managing quality is the Project Manager. Management of Quality in the RUP Managing quality is done for these purposes: To identify appropriate indicators (metrics) of acceptable quality To identify appropriate measures to be used in evaluating and assessing quality To identify and appropriately address issues affecting quality as early and effectively as possible Managing quality is implemented throughout all disciplines, workflows, phases, and iterations in the RUP. In general, managing quality throughout the lifecycle means you implement, measure, and assess both process quality and product quality. Some of the efforts expended to manage quality in each discipline are highlighted in the following list: Managing quality in the Requirements discipline includes analyzing the requirements artifact set for consistency (between artifact standards and other artifacts), clarity (clearly communicates information to all shareholders, stakeholders, and other roles), and precision (the appropriate level of detail and accuracy). In the Analysis & Design discipline, managing quality includes assessing the design artifact set, including the consistency of the design model, its translation from the requirements artifacts, and its translation into the implementation artifacts. In the Implementation discipline, managing quality includes assessing the implementation artifacts and evaluating the source code or executable artifacts against the appropriate requirements, design, and test artifacts. The Test discipline is highly focused toward managing quality, as most of the efforts expended in this discipline address the three purposes of managing quality, identified previously. The Environment discipline, like the Test discipline, includes many efforts addressing the purposes of managing quality. Here you can find guidance on how to best configure your process to meet your needs. Managing quality in the Deployment discipline includes assessing the implementation and deployment artifacts, and evaluating the executable and deployment artifacts against the appropriate requirements, design, and test artifacts needed to deliver the product to your customer. The Project Management discipline includes an overview of many efforts for managing quality, including the reviews and audits required to assess the implementation, adherence, and progress of the development process.

Gerência de Mudanças

Gerência de Mudanças Coordenação das Atividades e Artefatos
Coordenação das Iterações e Releases Controlando Mudanças de Software Workspaces isolados reduzem interferências Estatísticas provêem boas métricas Mudanças podem ser confinadas e as propagações medidas Coordinating the Activities and Artifacts Coordinating the activities and artifacts of developers and teams involves establishing repeatable procedures for managing changes to software and other development artifacts. This coordination allows a better allocation of resources based on the project's priorities and risks, and it actively manages the work on those changes across iterations. Coupled with developing your software iteratively, this practice lets you continuously monitor changes so that you can actively discover, and then react to problems. Coordinating Iterations and Releases Coordinating iterations and releases involves establishing and releasing a tested baseline at the completion of each iteration. Maintaining traceability among the elements of each release and among elements across multiple, parallel releases is essential for assessing and actively managing the impact of change. Controlling Changes to Software Controlling changes to software offers a number of solutions to the root causes of software development problems: The workflow of requirements change is defined and repeatable. Change requests facilitate clear communications. Isolated workspaces reduce interference among team members working in parallel. Change rate statistics provide good metrics for objectively assessing project status. Workspaces contain all artifacts, which facilitates consistency. Change propagation is assessable and controlled. Changes can be maintained in a robust, customizable system.

Conceitos Chave

Elementos do RUP Workflow Workers ou Papel Atividades Artefatos
A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule. Like other workflows, a discipline's workflow is a semi-ordered sequence of activities which are performed to achieve a particular result. The "semi-ordered" nature of discipline workflows emphasizes that the discipline workflows cannot present the real nuances of scheduling "real work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have value as a way for us to understand the process by breaking it into smaller 'areas of concern'. Each 'area of concern' or discipline has associated with it one or more 'models', which are in turn composed of associated artifacts. The most important artifacts are the models that each discipline yields: use-case model, design model, implementation model and test suite.

Descrever um Caso de Uso
Elementos do RUP Unidade de trabalho Papel desempenhado por um indivíduo ou grupo Atividade Worker Descrever um Caso de Uso Analista A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule. Like other workflows, a discipline's workflow is a semi-ordered sequence of activities which are performed to achieve a particular result. The "semi-ordered" nature of discipline workflows emphasizes that the discipline workflows cannot present the real nuances of scheduling "real work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have value as a way for us to understand the process by breaking it into smaller 'areas of concern'. Each 'area of concern' or discipline has associated with it one or more 'models', which are in turn composed of associated artifacts. The most important artifacts are the models that each discipline yields: use-case model, design model, implementation model and test suite. Responsável por Artefato Informação que é produzida, modificada, ou usada pelo processo Caso de Uso Pacote de Caso de Uso

Disciplina Workflow de atividades correlatas
Alguns elementos, como risco e testes, são introduzidos em diferentes disciplinas Relação entre disciplina e modelos A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule. Like other workflows, a discipline's workflow is a semi-ordered sequence of activities which are performed to achieve a particular result. The "semi-ordered" nature of discipline workflows emphasizes that the discipline workflows cannot present the real nuances of scheduling "real work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have value as a way for us to understand the process by breaking it into smaller 'areas of concern'. Each 'area of concern' or discipline has associated with it one or more 'models', which are in turn composed of associated artifacts. The most important artifacts are the models that each discipline yields: use-case model, design model, implementation model and test suite.

Disciplina

Workflow Sequência de atividades que produzem um resultado de valor observável Geralmente expresso em um diagrama de atividade Organização Disciplinas Detalhes do Workflow A mere enumeration of all roles, activities and artifacts does not constitute a process; we need a way to describe meaningful sequences of activities that produce some valuable result, and to show interactions between roles. A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagrams in the RUP. For each discipline, an activity diagram is presented. This diagram shows the workflow, expressed in terms of workflow details.

Workflow Workflows essenciais (Core Workflows): Engenharia: Suporte:
Modelagem de Negócio Requisitos Análise & Projeto Implementação Teste Deployment Suporte: Gerência do Projeto Gerência de Configuração Ambiente A mere enumeration of all roles, activities and artifacts does not constitute a process; we need a way to describe meaningful sequences of activities that produce some valuable result, and to show interactions between roles. A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagrams in the RUP. For each discipline, an activity diagram is presented. This diagram shows the workflow, expressed in terms of workflow details.

Workflow Modelagem de Negócio Requisitos Análise & Projeto
Modelo de Negócio Requisitos realizado pelo Modelo de Caso de Uso Análise & Projeto implementado pelo Modelo de Projeto Implementação verificado pelo Modelo de Implementação Teste Modelo de Teste

Workflow

Workflow Details As atividades não são feitas em sequência
Mostra os artefatos necessários e os gerados Agrupa atividades relacionadas de outras disciplinas For most of the disciplines, you will also find workflow detail diagrams, which show groupings of activities that often are performed "together". These diagrams show roles involved, input and output artifacts, and activities performed. The workflow detail diagrams are there for the following reasons: The activities of a workflow are neither performed in sequence, nor done all at once. The workflow detail diagram shows how you often will work in workshops or team meetings while performing a workflow. You typically work in parallel on more than one activity, and look at more than one artifact while doing that. There are several workflow detail diagrams for a discipline. It becomes too complex to show input and output artifacts for all activities of a discipline in one diagram. The workflow detail diagram allows us to show you activities and artifacts together, for one part of a workflow at a time. The disciplines are not completely independent of one another. For example, integration occurs in both the implementation and test disciplines, and in reality you never really do one without the other. The workflow detail diagram can show a group of activities and artifacts in the discipline, together with closely related activities in another discipline.

Workflow Details

Workers - Papel Define o comportamento e as responsabilidades de um indivíduo um uma equipe Exercidos por pessoal interno ou externo à equipe de desenvolvimento The most central concept in the Process is that of a role. A role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization. The Roles Overview provides additional information on roles. Note that roles are not individuals; instead, they describe how individuals should behave in the business and the responsibilities of an individual. Individual members of the software development organization will wear different hats, or perform different roles. The mapping from individual to role, performed by the project manager when planning and staffing the project, allows different individuals to act as several different roles, and for a role to be played by several individuals.

Workers - Papel Exemplos: Analista de Sistemas Revisor de Projeto
Testador de desempenho The most central concept in the Process is that of a role. A role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization. The Roles Overview provides additional information on roles. Note that roles are not individuals; instead, they describe how individuals should behave in the business and the responsibilities of an individual. Individual members of the software development organization will wear different hats, or perform different roles. The mapping from individual to role, performed by the project manager when planning and staffing the project, allows different individuals to act as several different roles, and for a role to be played by several individuals.

Workers - Papel

Atividade Unidade de trabalho com um propósito claro
Utilizado para planejamento e verificação de progresso Passos Planejando Executando Revisando An activity is a unit of work that an individual playing the described role may be asked to perform. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, a class, a plan. Every activity is assigned to a specific role. The granularity of an activity is generally a few hours to a few days, it usually involves one role, and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have to be expressed in terms of an activity’s parts. Activities may be repeated several times on the same artifact, especially when going from one iteration to another, refining and expanding the system, by the same role, but not necessarily the same individual. Steps Activities are broken down into steps. Steps fall into three main categories: Thinking steps: where the individual performing the role understands the nature of the task, gathers and examines the input artifacts, and formulates the outcome. Performing steps: where the individual performing the role creates or updates some artifacts. Reviewing steps: where the individual performing the role inspects the results against some criteria.

Atividade Exemplos: Identificar casos de uso e atores
Worker: Analista de Sistemas Revisar o projeto Worker: Revisor de Projeto Executar teste de desempenho Worker: Testador de desempenho An activity is a unit of work that an individual playing the described role may be asked to perform. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, a class, a plan. Every activity is assigned to a specific role. The granularity of an activity is generally a few hours to a few days, it usually involves one role, and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have to be expressed in terms of an activity’s parts. Activities may be repeated several times on the same artifact, especially when going from one iteration to another, refining and expanding the system, by the same role, but not necessarily the same individual. Steps Activities are broken down into steps. Steps fall into three main categories: Thinking steps: where the individual performing the role understands the nature of the task, gathers and examines the input artifacts, and formulates the outcome. Performing steps: where the individual performing the role creates or updates some artifacts. Reviewing steps: where the individual performing the role inspects the results against some criteria.

Atividade

Atividade A atividade Find use case and actors se decompõe nos passos:
Identificar os atores Identificar os casos de uso Descrever a interação entre os atores e uc Organizar em pacotes Apresentar o modelo em um diagrama Avaliar os resultados

Artefatos Unidade produzida por um atividade Pode assumir as formas:
Modelo (UC Model) Elemento de Modelo (Ator) Documento (Visão) Código (Componente) Activities have input and output artifacts. An artifact is a work product of the process: roles use artifacts to perform activities, and produce artifacts in the course of performing activities. Artifacts are the responsibility of a single role and promote the idea that every piece of information in the process must be the responsibility of a specific person. Even though one person may "own" the artifact, many other people may use the artifact, perhaps even updating it if they have been given permission.

Artefatos

Artefatos Mantidos por controle de versão
Artefatos geralmente não estão na forma de documentos O artefato esta sempre atualizado Guias e checkpoints Fornecem uma referência de como fazer Permitem verificar a qualidade do artefato Note that "artifact" is the term used in the RUP. Other processes use terms such as work product, work unit, and so on, to denote the same thing. Deliverables are only the subset of all artifacts that end up in the hands of the customers and end-users. Artifacts are most likely to be subject to version control and configuration management. This is sometimes only achieved by versioning the container artifact, when it is not possible to do it for the elementary, contained artifacts. For example, you may control the versions of a whole design model, or design package, and not of individual classes they contain. Artifacts are typically not documents. Many processes have an excessive focus on documents, and in particular on paper documents. The RUP discourages the systematic production of paper documents. The most efficient and pragmatic approach to managing project artifacts is to maintain the artifacts within the appropriate tool used to create and manage them. When necessary, you may generate documents (snapshots) from these tools, on a just-in-time basis. You should also consider delivering artifacts to the interested parties inside and together with the tool, rather than on paper. This approach ensures that the information is always up-to-date and based on actual project work, and it shouldn’t require any additional effort to produce. Examples of artifacts: A design model stored in Rational Rose. A project plan stored in Microsoft Project. A defect stored in Rational ClearQuest. A project requirements database in Rational RequisitePro. However, there are still artifacts which have to be plain text documents, as in the case of external input to the project, or in some cases where it is simply the best means of presenting descriptive information. Artifact Guidelines and Checkpoints Artifacts typically have associated guidelines and checkpoints which present information on how to develop, evaluate and use the artifacts. Much of the substance of the Process is contained in the artifact guidelines; the activity descriptions try to capture the essence of what is done, while the artifact guidelines capture the essence of doing the work. The checkpoints provide a quick reference to help you assess the quality of the artifact. Both guidelines and checkpoints are useful in a number of contexts: they help you decide what to do, they help you to do it, and they help you to decide if you've done a good job when you're done.

Artefatos Templates Exemplos Documento de visão (MS Word)
Modelo (Modelo de Caso de Uso, de Projeto, etc) Documento (Documento da Arquitetura do Software) Código-Fonte Executáveis Templates are "models," or prototypes, of artifacts. Associated with the artifact description are one or more templates that can be used to create the corresponding artifacts. Templates are linked to the tool that is to be used. For example: Microsoft Word templates would be used for artifacts that are documents, and for some reports. Rational SoDA templates for Microsoft Word or FrameMaker would extract information from tools such as Rational Rose, Rational RequisitePro, or Rational TeamTest. Microsoft FrontPage templates for the various elements of the process. Microsoft Project template for the project plan. As with guidelines, organizations may want to customize the templates prior to using them by adding the company logo, some project identification, or information specific to the type of project. Templates are organized in the treebrowser beneath their associated artifact. They are also summarized in a separate treebrowser entry showing all templates. Models and model elements, may have reports associated with them. A report extracts information about models and model elements from a tool. For example, a report presents an artifact or a set of artifacts for a review. Unlike regular artifacts, reports are not subject to version control. They can be reproduced at any time by going back to the artifacts that generated them. Reports are organized in the treebrowser beneath the artifact on which they report.

Documentos Documentos de Visão Documentos de Risco
Documentos de Análise de Negócio (Processo) Activities, steps, and associated guidelines provide general guidance to the practitioner. To go one step further, tool mentors are an additional means of providing guidance by showing how to perform the steps using a specific software tool. Tool mentors are provided in the RUP, linking its activities with tools such as Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational Suite TestStudio. The tool mentors almost completely encapsulate the dependencies of the process on the tool set, keeping the activities free from tool details. An organization can extend the concept of tool mentor to provide guidance for other tools.

Tool Mentors Guiam a execução das atividades em uma ferramenta Ex:
Documenting the Deployment Model Using Rational Rose Activities, steps, and associated guidelines provide general guidance to the practitioner. To go one step further, tool mentors are an additional means of providing guidance by showing how to perform the steps using a specific software tool. Tool mentors are provided in the RUP, linking its activities with tools such as Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational Suite TestStudio. The tool mentors almost completely encapsulate the dependencies of the process on the tool set, keeping the activities free from tool details. An organization can extend the concept of tool mentor to provide guidance for other tools.

Fundamentos

Visão Concordar com o problema a ser resolvido
Identificar os stakeholders Definir os limites do sistema Identificar as restrições Políticas Econômicas Ambientais Praticabilidade Sistema In particular, developing a clear Vision is key to developing a product that meets your stakeholders’ real needs”. In RUP, the Vision artifact captures very high-level requirements and design constraints, to give the reader an understanding of the system to be developed. It provides input to the project-approval process, and is therefore intimately related to the Business Case. It communicates the fundamental "why's and what's" related to the project and is a gauge against which all future decisions should be validated. Identify Stakeholders Depending on the domain expertise of the development team, identifying the stakeholders may be a trivial or a nontrivial step. Often, this simply involves interviewing decision-makers, potential users and other interested parties. The following questions are helpful: Who are the users of the system? Who is the economic buyer for the system? Who else will be affected by the outputs that the system produces? Who will evaluate and bless the system when it is delivered and deployed? Are there any other internal or external users of the system whose needs must be addressed? Who will maintain the new system? Is there anyone else? Okay, is there anyone else? Start to develop profiles of potential (or actual) users of the system. These will map to the roles of the human actors of the system being developed. Initial information on key users and their environment should be documented in the Vision document. If Business Modeling is being done as part of this project, or as a precursor to this project, the Business Use-Case Model and Business Object Model will provide valuable information in this area. Define the System Boundaries The system boundary defines the border between the solution and the real world that surrounds the solution. In other words, the system boundary describes an envelope in which the solution system is contained. Information, in the form of inputs and outputs, is passed back and forth from the system to the users that live outside of the system. All interactions with the system occur via interfaces between the system and the external world. In many cases, the boundaries of the system are obvious. For example, the boundaries of a single user, shrink-wrap personal contact manager that runs on Microsoft Windows® are relatively well defined. There is only one user and one platform. The interfaces between the user and the application consist of the user interface dialogs that the user accesses to enter information into the system, and any output reports and communication paths that the system uses to document or transmit the resulting information. It is usually very effective to use actors to define and describe the boundaries of the system. See Activity: Find Actors and Use Cases. Again, the Business Use-Case Model and Business Object Model may provide valuable information in this area if Business Modeling has been done. Identify Constraints to be Imposed on the System There are a variety of sources of constraints to be considered. Much of this information may be documented in the Business Rules artifact. Following is a list of potential sources and questions to ask: Political: Are there internal or external political issues that affect potential solutions? Interdepartmental? Economic: Which financial or budgetary constraints are applicable? Are there costs of goods sold, or product pricing considerations? Are there any licensing issues? Environmental: Are there environmental or regulatory constraints? Legal? Other standards we are restricted by? Technical: Are we restricted in our choice of technologies? Are we constrained to work within existing platforms or technologies? Are we prohibited from any new technologies? Feasibility: Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we expand resources? Temporary? Permanent? System: Is the solution to be built on our existing systems? Must we maintain compatibility with existing solutions? Which operating systems and environments must be supported? The information gathered here will be the initial input to the design constraints defined in the Supplementary Specifications.

Visão Formular a expressão do problema
O problema <descrição do problema> Afeta <os stakeholders afetados> O impacto deste é <qual é o impacto do problema> Uma solução adequada poderia <lista de beneficios> Formulate Problem Statement With the whole group, work on easel charts and fill in the following template for each problem you have identified: The problem of <describe the problem> affects <the stakeholders affected by the problem>. The impact of which is <what is the impact of the problem>. A successful solution would <list some key benefits of a successful solution>. The purpose of this template is to help you distinguish solutions/answers from problems/questions. Example: The problem of: untimely and improper resolution of customer service issues affects: our customers, customer support reps and service technicians. The impact of which is: customer dissatisfaction, perceived lack of quality, unhappy employees and loss of revenue. A successful solution would: provide real-time access to a trouble-shooting database by support reps and facilitate dispatch of service technicians, in a timely manner, only to those locations which genuinely need their assistance. Define Features of the System Based on the benefits listed in your problems statements, develop a list of features you want in the system. Describe them briefly, and give them attributes to help define their general state and priority in the project (for more on attributes, see Activity: Manage Dependencies). Evaluate Your Results You should check the Vision at this stage to verify that your work is on track, but not review it in detail. Consider the checkpoints for the Vision document in Activity: Review Requirements.

Planejamento Software development plan
Bom entendimento do que vai ser criado Plano da Fase: granularidade alta Plano de Iteração: granularidade baixa Conceiving a new project; evaluating scope and risk; monitoring and controlling the project; planning for and evaluating each iteration and phase - these are the “essence” of the Project Management discipline. The Software Development Plan (SDP) gathers all information required to manage the project. It may enclose a number of separate artifacts developed during the Inception phase and is maintained throughout the project. The SDP is used to plan the project schedule and resource needs, and to track progress against the schedule. It addresses such areas as: Project Organization, Schedule (Project Plan, Iteration Plan, Resources, Tools), Requirements Management Plan, Configuration Management Plan, Problem Resolution Plan, QA Plan, Test Plan, Test Cases, Evaluation Plan, and Product Acceptance Plan. For a small project, these do not have to be maintained as separate artifacts. They could be addressed as merely a section -- or even a paragraph -- in the SDP. In a simple project, these may include only one or two sentences each. For example a CM Plan may simply state: “At the end of each day, the contents of the project directory structure will be zipped, copied onto a dated, labeled zip disk, marked with a version number and placed in the central filing cabinet.” The format of the Software Development Plan itself is not as important as the activity and thought that go into producing it. It doesn't matter what it looks like – or what tools you use to build it. As Dwight D. Eisenhower said, “The plan is nothing; the planning is everything.” “The product is only as good as the plan for the product” Charles Fishman “The plan is nothing; the planning is everything.” Dwight D. Eisenhowe

Riscos Definição: é uma variavel que pode obter um valor que dificulte ou até mesmo torne o desenv. inviável Tipos Risco direto Risco indireto Atributos Probabilidade de ocorrência Impacto no projeto

Riscos Investigando e avaliando riscos Identificar os riscos
Analisar e priorizar os riscos Definir estratégias de evasão Definir estratégias de ataque Definir estratégias de contingência Indicadores “Plano B” Rever os ricos durante a iteração Rever os riscos no final da iteração Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Tipos de Riscos Riscos de Requisitos Riscos Tecnológicos
Riscos de Habilidades Riscos Políticos Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Riscos de Requisitos Ponto inicial do processo de desenvolvimento: Casos de Uso (interação típica que o usuário tem com o sistema) Esboçar esqueleto do modelo conceitual do domínio – Modelo de domínio. Fornece muita compreensão. Ponto inicial para construção de classes Encontrar detalhes importantes e se concentrar neles Construção de Protótipo Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Riscos Tecnológicos Construir um protótipo que experimente as partes da tecnologia que você está pensando em utilizar Como os componentes do projeto se encaixam Dificuldade de serem modificados Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Riscos de Habilidades Treinamento é um bom modo de evitar erros
Bom instrutor Treinamento em pequenas porções Se não puder ter consultores, faça revisões de tempo em tempo Leitura e grupos de estudo Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Riscos Políticos Política Corporativa Planos de governo
Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Riscos “Quem estiver primeiro no campo de batalha e esperar a aparição do inimigo estará descansado para o combate; quem vier depois e tiver de apressar-se, chegará exausto.” Sun Tzu Identify Potential Risks Purpose To make an inventory of ‘what can go wrong’ with the project. To initiate the risk list (in the inception phase): Gather the project team together (which at this point should be quite small; if there are more than five to seven people on the project team, limit the risk assessment process to the activity leaders). When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so that we can reduce or eliminate them. For more information, see Guidelines: Risk List. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver the project with the right features, the requisite level of quality, on time and within budget. Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be identified. Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large mix. Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will identify any risks (or the risks they do raise will be trivial). To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps people to identify more. To update the risk list (in later phases): You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be identified by the team members, and captured at the regular project Status Assessment. See Activity: Assess Iteration. Analyze and Prioritize Risks To combine similar risks (to reduce the size of the risk list) To rank the risks in terms of their impact on the project. When no more risks are being found, look at the risk list as a group to see if there are any natural groupings (occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the more fundamental risk. Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the risk represents to the project. To determine the exposure for each risk the group should estimate the following information: Impact of riskThe deviations of schedule, effort, or costs from plan if the risk occurs Likelihood of OccurrenceThe probability that the risk will actually occur (usually expressed as a percentage) Risk ExposureCalculated by multiplying the Impact by the Likelihood of Occurrence As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as columns in a tabular Risk List. It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that will have the most significant affect on project delivery. Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create your "top 10" Risks List. Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger ‘risk target’ and as a result have a larger number of relevant risks. In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five categories is sufficient: High Significant Moderate Minor Low Document the risks and circulate them among the project team members. Identify Risk Avoidance Strategies To reorganize the project to eliminate risks While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources (including time) to do the work. In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control). Finally risk can be transferred to other organizations. Identify Risk Mitigation Strategies To develop plans to mitigate risks, that is to reduce their impact of the risks. For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further the reduce the uncertainty. There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the risks as early as possible. if a risk is in the form "X may not work?", then plan to try X as soon as possible. Examples: To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is successful. To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application. To reduce the risk that test tool Z will not be able to effectively regression test the application, we will acquire and use it during the upcoming iteration. The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies). Identify Contingency Strategies To develop alternate plans For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement. The contingency plan should consider: Risk What is the risk? Indicator How will you know that the risk has become a reality? How is the 'loss event' recognized? Action What should be done to address the 'loss event' (how can you stop the "bleeding"?) Identify Risk Indicators Some risks can be monitored using project metrics, looking at trends and threshold; for example: Rework remaining too high Breakage remaining too high Actual expenditure far above plans Some risks can be monitored based on project requirements and test results; for example: Response times one order of magnitude above requirement. Some risks are associated to specific event; for example: Software component not delivered in time by third party. There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom. Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction. Identify "Loss" Actions, or "Plan B" For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one. For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words. Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence. Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on. Revisit Risks During the Iteration To ensure that the risk list is kept current throughout the project. Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the project. At minimum, you should: Revisit your list weekly to see what has changed. Make the top ten items visible to the whole project and insist on action being taken on them. Often you would attach the current risk list to your Status Assessment reports. Revisit Risks at the End of Iteration At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically: Eliminate risks that have been fully mitigated. Introduce new risks recently discovered. Reassess the magnitude and reorder the risk list (see Analyze and Prioritize Risks). Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As project members do the work, they realize that something they thought was trivial actually contains risks. As you begin doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your system is too complex, or impossible to build in a systematic and predictable fashion.

Business Case Plano econômico para realizar a Visão, isto é, saber se o projeto vale a pena. Avaliação do ROI (Return On Investment) Template

Arquitetura Artefato: Software Architecture Document
Quais são os componentes? Como os componentes se encaixam? Existe algum framework? Visões arquiteturais

Visão de Implementação
Arquitetura Usuário final Funcionalidade Programadores Gerenciamento de Software Visão Lógica Visão de Implementação Visão de Casos de Uso Visão de Processo Visão de “Deployment” Integradores Performance Escalabilidade Engenharia Topologia Instalação

Prototipagem Iterativamente e incrementalmente criar versões do sistema. Verificação dos requisitos Redução de riscos

Avaliação Regular Foco nos problemas no processo e os problemas no produto

Mudanças Artefato: Change Request
Provê um histórico das mudanças e das decisões tomadas Gerenciar o escopo do projeto Avaliar o impacto das decisões

Suporte do Usuário Criar um produto utilizável
Manuais, ajuda e treinamento

Processo Adotar um processo que se encaixa ao projeto
A produção de artefatos varia de projeto a projeto

Conclusões Sem visão? Sem processo? Sem planejamento?
O projeto pode perder escopo ou desviar do propósito Sem processo? A equipe pode perder a visão de quem esta fazendo o que e quando Sem planejamento? Você perde a capacidade de rastrear o progresso

Conclusões Sem controle de riscos? Sem Business Case? Sem arquitetura?
Você pode focar no ponto errado e pisar em “minas” Sem Business Case? Você corre-se o risco de jogar tempo e investimento fora Sem arquitetura? Podem ocorrer problemas com escalabilidade, falso reuso e performance

Conclusões Sem prototipagem? Sem avaliação? Sem Change Request?
Como você e o usuário saberão que o sistema funciona? Sem avaliação? Tenha coragem e enfrente a verdade! Sem Change Request? Como rastrear, priorizar os pedidos do cliente Sem suporte do usuário? Como o usuário vai obter informação sobre o sistema?

Fases Inception Elaboration Construction Transition tempo

Fases e Iterações Versões Inception Elaboration Construction
Transition Iteração Prelim. Iteração #1 Iteração #n Iteração #n+1 Iteração #m Iteração #m+1 … … … Versões

Milestone tempo Inception Elaboration Construction Transition Lifecycle Objectives Lifecycle Architecture Initial Operational Capability Cada fase deve ser concluída com um Milestone (Major Milestone)

Concepção Estabelecer o escopo e os limites, com critérios de aceitação bem definidos Discriminar os casos de usos críticos Exibir uma arquitetura candidata “Adivinhar” o custo e o calendário Preparar o ambiente do projeto

Concepção - Milestone Examina os objetivos e decide seguir ou cancelar o projeto - Viabilidade Critério de avaliação Entendimento e acordo com os requisitos Credibilidade do custo/tempo Acerto das prioridades

Concepção - Milestone Produtos: Visão geral dos requisitos do projeto:
Modelo de Caso de Uso inicial (10-20%) Estimativa dos recursos necessários Mini Mundo

Elaboração Assegurar que os requisitos e planos estão estáveis
Estabelecer uma arquitetura Provar que a arquitetura funciona Produzir um protótipo evolucionário Estabelecer um ambiente

Elaboração Deve terminar em torno de um quinto do tempo do projeto
Desenvolvedores já sentem a vontade para dar estimativas de tempo Todos os riscos significativos foram identificados

Elaboração - Milestone
Examina os objetivos, arquitetura e riscos do projeto Critério de avaliação Requisitos, visão e arquitetura estáveis Verificar que, com os protótipos, todos os riscos foram atacados Planos de Iteração da fase de construção Despesas atuais batem com estimadas

Elaboração - Milestone
Todos o Stakeholders concordam que a visão atual pode ser alcançada se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ? Produtos: Modelo de Caso de Uso (80%) Plano de desenvolvimento Avaliação revisada dos riscos Protótipo da arquitetura

Construção Atingir qualidade o mais breve possível
Desenvolver incrementalmente e lançar as versões de teste (alpha, beta) Completar o desenvolvimento de todos os Casos de Uso

Construção Estabelecer(detalhar) as iterações e definir que funcionalidades entregar em cada uma delas Casos de Uso com maior prioridade e/ou risco de desenvolvimento primeiro Cada iteração é um mini-projeto: Análise, projeto,codificação, teste e integração As iterações são incrementais na função Integração contínua

Construção - Milestone
Sistema e manual Critério de avaliação O sistema já esta maduro o suficiente pra ser entregue? Os stakeholders estão prontos para usá-lo? Despesas reais versus planejadas continuam aceitaveis?

Construção - Milestone
Produtos: Modelo de Caso de Uso e de Projeto completos Manual do usuário O software integrado e pronto para a utilização dos usuários

Transição Teste de validação Conversão do ambiente para produção
Treinamento de usuários e manutenção Otimização Alcançando auto-suporte do usuário

Transição - Milestone Os objetivos foram cumpridos
Coincide com o fim da fase de concepção de outro ciclo Critério de avaliação O usuário está satisfeito Despesas reais versus planejadas continuam aceitaveis?

Transição - Milestone Produtos: Versão final do produto
Manual do usuário atualizado Modelos atualizados

Preliminary Iteration(s)
RUP Core Workflows Fases Workflows de Engenharia Inception Elaboration Construction Transition Modelagem do Negócio Requisitos Análise & Projeto Implementação Teste Deployment Workflows de Suporte Ger. de Configuração Gerência do Projeto Ambiente Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Tempo Iterações

Rational Unified Process

Apresentações semelhantes

Apresentação em tema: "Rational Unified Process"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Rational Unified Process

Apresentações semelhantes

Apresentação em tema: "Rational Unified Process"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback