Metodologias de Desenvolvimento

Metodologias de Desenvolvimento
Faculdade 7 de Setembro Metodologias de Desenvolvimento Paulo Benício

Metodologias e Processo de Desenvolvimento
Professor: Paulo Benício /msn:

Roteiro Introdução

Introdução Sistemas Computacionais: Crescimento acelerado.
Empregados em vários setores. Alguns mitos que se tornaram realidade: Caixas Eletrônicos Computação embarcada em automóveis. Computadores laptop. Projeto do Genoma Humano World Wide Web.

Modelo de Desenvolvimento

Engenharia de Software Uma tecnologia em camadas
Processos de engenharia devem se apoiar num compromisso organizacional com a qualidade Cultura de um processo continuo de aperfeiçoamento Desenvolvimento de abordagens cada vez mais amadurecidas para a engenharia de software A camada que dá apoio à engenharia de software é o enfoque na qualidade.

Processos (procedimentos)
A camada de processo é o fundamento da Engenharia de Software Os procedimentos constituem o elo de ligação que mantém juntos os métodos e as ferramentas Possibilitam o desenvolvimento racional e oportuno de software Definem áreas chave (key process areas – kpa) que estabelecem: a seqüência em que os métodos serão aplicados os produtos que deverão ser entregues os controles que ajudam a assegurar a qualidade e a coordenar as mudanças os marcos de referencia que possibilitam aos gerentes avaliar o progresso.

Métodos Métodos proporcionam os detalhes de “como fazer” para construir o software. Envolvem tarefas como: planejamento e estimativa de projeto análise de requisitos projeto de estrutura de dados Algoritmos Codificação Teste Manutenção Muitas vezes, introduzem uma notação gráfica ou orientada à linguagem e um conjunto de critérios para a qualidade do software

Ferramentas As ferramentas proporcionam apoio automatizado ou semi automatizado para o processo e para os métodos Quando ferramentas são integradas de modo que a informação criada por uma ferramenta pode ser usada por outra, origina-se um sistema de apoio ao desenvolvimento chamado Engenharia de Software Apoiada por Computador (CASE – Computer Aided Software Engineering) CASE combina software, hardware e uma base de dados de engenharia de software semelhante ao CAD/CAM

Desenvolvimento de software
Engenheiros de software utilizam estes recursos para desenvolver software de alta qualidade Um procedimento é um conjunto de ferramentas e técnicas que juntas geram um produto Um método ou técnica é um procedimento formal para produzir algum resultado Uma ferramenta é um instrumento ou sistema automatizado para resolver alguma coisa da melhor forma Um paradigma representa uma abordagem ou filosofia para construir um software.

Atores da Engenharia de Software

Membros de uma equipe de desenvolvimento
Analista Projetista Programador Responsável por testes Instrutor

Na sua proposta de trabalho, responda a estas perguntas!!
Engenharia Independente do elemento a ser tratado, um processo de engenharia deve tratar as seguintes questões: Qual é o problema a ser resolvido? Que características do elemento são usadas para resolver o problema? Como o elemento (e a solução) serão realizados? Como o elemento vai ser construído? Que abordagem será usada para descobrir erros que foram cometidos no projeto e na construção do elemento? Como o elemento será mantido a longo prazo, quando correções, adaptações e aperfeiçoamentos forem solicitados pelos usuários? ELEMENTO = SOFTWARE

Engenharia de software Visão genérica
Para realizar a engenharia de software adequadamente um processo (forma de trabalho) deve ser definido Um processo de ES pode ser categorizado, genericamente em 3 fases, que focalizam as questões feitas anteriormente: Fase de definição Fase de desenvolvimento Fase de manutenção

Engenharia de software Fase de Definição
Considere também estas questões na sua proposta de trabalho!! Engenharia de software Fase de Definição se concentra no quê Que informação deve ser processada Que função e desempenho são desejados Que comportamento é esperado do sistema Que interfaces devem ser estabelecidas Que restrições de projeto existem Que critérios de validação são necessários para definir um sistema bem sucedido Identificação dos requisitos chave do software Os métodos variam de acordo com o paradigma de Engenharia de Software escolhido, mas 3 tarefas principais ocorrerão: Engenharia de sistema ou de informação Planejamento do projeto de software Análise de requisitos

Engenharia de Software Fase de desenvolvimento
Focaliza o como Como os dados serão estruturados Como a função deve ser implementada Como os detalhes procedimentais devem ser implementados Como as interfaces devem ser caracterizadas Como o projeto deve ser traduzido em linguagem de programação Como o teste vai ser realizado Os métodos variam, mas 3 tarefas técnicas ocorrerão: Projeto de software Geração de código Teste de software

Engenharia de Software Fase de manutenção
Focaliza nas modificações Aplica os passos das fases de definição e de desenvolvimento, mas no contexto do software já existente Quatro tipos de manutenção: Manutenção corretiva – modifica o software para corrigir defeitos Manutenção adaptativa – modifica o software para adaptá- lo a mudanças no ambiente externo Manutenção perfectiva – aprimora o software além dos requisitos originais Manutenção preventiva (reengenharia de software) – modifica o software para que possa ser mais facilmente corrigido, adaptado e melhorado Apoio contínuo ao usuário: assistência técnica e suporte

Atividades guarda-chuva
Atividades que devem ser aplicadas durante todas as etapas do processo de software Assim chamadas porque são utilizadas a todo momento, encobrindo todas as atividades do processo Incluem atividades de: Acompanhamento e controle de projeto de software Revisões técnicas formais Garantia de qualidade de software Gestão de configuração de software Preparação e produção de documentos Gestão de reutilização Gestão de risco

Processo de Software

Processo de Software Estrutura comum de processo de software
Define um pequeno número de atividades Aplicáveis a todos os projetos de software Conjuntos de tarefas Permite que as atividades da estrutura sejam adaptadas às características do projeto de software e às necessidades da equipe do projeto Constituídos de Coleção de tarefas Marcos de projeto Produtos do trabalho Pontos de garantia de qualidade Atividades guarda-chuva ocorrem em todo o modelo de processo

Processo de Software CMM (Capability Maturity Model)
Estabelecidas pelo Software Engineering Institure (SEI) – Prescreve um conjunto de capacidades (i.e.,requisitos de qualidade) de Engenharia de Software presentes à medida que as empresas atingem níveis de maturidade de processo de software São 5 níveis que indicam uma medida da efetividade global das práticas de Engenharia de Software de uma empresa

Modelos de Processo de Software
A Engenharia de Software compreende um conjunto de etapas envolvendo métodos, ferramentas e procedimentos Estas etapas são chamadas de Modelos de Processo Estes modelos são escolhidos considerando: domínio da aplicação os métodos e as ferramentas a serem usadas os controles e os produtos que precisam ser entregues as características do grupo desenvolvedor o grau de conhecimento sobre o problema

Modelos de Processo de Software
Caracterizado como um ciclo de solução de problema com 4 estágios: Situação atual: Identificação do estado atual das coisas Definição do problema: Identifica o problema a ser resolvido Desenvolvimento técnico: Resolve o problema por meio de aplicação de uma tecnologia Integração: Entrega os resultados (documentos, programas, dados, nova função de negócio, novo produto) Aplica-se ao trabalho de Engenharia de Software em diferentes níveis de detalhe: a aplicação como um todo ou um componente de programa, até o nível de linha de código Distinção nítida das etapas é difícil, num processo real Conforme se desenvolve o trabalho rumo a um sistema completo, as etapas se aplicam recursivamente às necessidades do usuário e à especificação técnica do desenvolvedor do software.

Processos de Desenvolvimento
Roteiro Processos de Desenvolvimento

Engenharia de Software
Modelos de Ciclo de Vida ou Processos de Software

Modelo + Planejamento = Processo
Modelo X Processo Um modelo é algo teórico, um conjunto de possíveis ações. O processo deve determinar ações práticas a serem realizadas pela equipe, tais como prazos definidos e métricas para se avaliar como elas estão sendo realizadas Modelo + Planejamento = Processo

Modelos de Processo Principais modelos:
Modelo Seqüencial Linear ou em Cascata (Waterfall) Modelo de Prototipagem Modelo RAD Modelos Evolucionários: Incremental Espiral Espiral ganha-ganha Desenvolvimento concorrente Desenvolvimento baseado em componentes Modelo de Métodos Formais

Modelo em Cascata (Waterfalls)
Às vezes chamado de Modelo de Ciclo de Vida Clássico ou de Modelo Seqüencial Linear Abordagem sistemática seqüencial para o desenvolvimento do software, começando pelo nível de sistema e progride através da análise, codificação, teste e manutenção O paradigma desse ciclo de vida requer uma abordagem sistemática e seqüencial ao desenvolvimento. É o paradigma mais antigo e o mais usado

Modelo em Cascata (Waterfalls)
O processo Cascata está associado às metodologias propostas nas décadas de Notadamente as metodologias Estruturadas Yourdon Constantine Chris Gane Page-Jones

Modelo em Cascata (Waterfalls) Etapas
Engenharia de Sistemas Análise de Requisitos Projeto Codificação Teste Manutenção

Modelo em Cascata (Waterfalls) Atividades
Análise e definição de requisitos Objetivos, funções e restrições são definidos, com ajuda de clientes e usuários, e servem como uma especificação do sistema, indicando o que deve ser implementado. Design de sistemas e software Envolve a descrição do sistema e do software em termos de unidades abstratas e de suas relações, indicando como o software deve ser implementado. Implementação e testes de unidade As unidades do software devem ser codificadas e testadas individualmente. Integração e testes de sistema A unidades são integradas e testadas Entrega, operação e manutenção A manutenção envolve a correção de erros e evolução do sistema para atender a novos requisitos.

Modelo em Cascata (Waterfalls) Características
Oferece maior previsibilidade de prazos e custo: melhor planejamento e gerenciamento. Principais problemas Projetos reais raramente seguem o fluxo seqüencial Dificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicas O cliente precisa ter paciência Indicado somente quando os requisitos são bem conhecidos Pode ser usado em trabalhos acadêmicos com etapas bem definidas de “levantamento bibliográfico”

Processo de Desenvolvimento
Arquitetura genérica de aplicativos Camada de Apresentação Interface Homem Máquina Rotinas de Apresentação Camada de Banco de Dados Rotinas de Acesso Banco de Dados Camada de Lógica da Aplicação Regras de Negócio (Métodos) Classes (Implementação) fig. 3 – A marco arquitetura base Aplicativo

Planejamento Insumos Produtos Papéis Contrato e/ou Proposta
Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Contrato e/ou Proposta Produtos Plano de Desenvolvimento Plano de Configuração Plano de Garantia da Qualidade Plano de Verificação e Validação Papéis Gerente/Coordenador de Projeto SQA Gerente de Qualidade Gerente de Configuração

Requisitos Insumos Produtos Papéis Requisitos contidos na Proposta
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Requisitos contidos na Proposta Produtos Especificação de Requisitos Especificação de Casos de Uso Papéis Engenheiro de sistemas Arquiteto Analista de sistemas Coordenador de projeto Cliente

Análise e Projeto Insumos Produtos Papéis
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Especificação de Casos de Uso, Interface, Núlceo e Base de Dados Produtos Projeto de Interface, Núcleo e Base de Dados Especificação de Teste de Integração Especificação de Teste de Unidade Papéis Analista de sistemas Arquiteto Coordenador de projeto

Codificação Insumos Produtos Papéis
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Projeto de Interface, Núcleo e Base de Dados Produtos Guia de Implementação (Build) Código Fonte Papéis Analista de sistemas Programador Coordenador de projeto

Teste de Unidade Insumos Produtos Papéis
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Especificação de Teste de Unidade Código do aplicativo Produtos Relatório de Teste de Unidade Código do aplicativo testado e corrigido Papéis Analista de sistemas Programador Coordenador de projeto

Integração (Opcional)
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Especificação de Teste de Integração Código do aplicativo Produtos Relatório de Teste de Integração Código do aplicativo testado e corrigido Papéis Analista de sistemas Programador Coordenador de projeto

Teste de Sistema Insumos Produtos Papéis
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Especificação de Teste de Sistema Código do aplicativo Produtos Relatório de Teste de Sistema Código do aplicativo testado e corrigido Papéis Engenheiro de Sistemas Programador Coordenador de projeto

Teste de Aceitação Insumos Produtos Papéis
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Especificação de Teste de Aceitação Código do aplicativo Produtos Relatório de Teste de Aceitação Código do aplicativo testado e corrigido Papéis Engenheiro de Sistemas Cliente

Empacotamento Insumos Produtos Papéis Código do produto
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Código do produto Arquivos de execução Guia de implementação Produtos Pacote do produto Papéis Analista de Sistemas Coordenador de Projeto

Consolidação Insumos Produtos Papéis Histórico do projeto
Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotamento Teste de Sistema Consolidação Insumos Histórico do projeto Documentação do projeto Produtos Relatório de Lições Aprendidas Papéis Toda equipe do projeto

Responsabilidades Grupo de Engenharia Grupo de Desenvolvimento
Planejamento Requisitos Integração Teste de Aceite Projeto Análise Codificação Teste Unitário Empacotamento Teste de Sistema Consolidação Grupo de Engenharia Grupo de Desenvolvimento Grupo de Qualidade

Resumo dos Produtos Planos de Projeto Espec. de Requisitos
Planejamento Requisitos Projeto Análise Codificação Testes ( Unit/Integr/ Sist/Aceite ) Empacotamento Consolidação Planos de Projeto Espec. de Requisitos Espec. de Sistema Proj. de Sistema Código fonte Relatório de Testes Pacote do Produto Relatório de Lições

Modelo de Prototipação
Abordagem interessante em situações em que a incerteza está presente na definição de requisitos, de objetivos e/ou de procedimentos Desenvolvimento Exploratório A partir de requisitos iniciais, é elaborado um protótipo que permite, junto ao cliente, explorar novos requisitos. Permite a criação de um modelo do software que será desenvolvido, em uma das seguintes formas: Um protótipo que retrata a interação homem-máquina de forma que o usuário entenda esta interação Um protótipo de trabalho que implemente um subconjunto das funções do software Um programa que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas em um novo esforço de desenvolvimento

Protótipo de software é um sistema que... funciona não tem tempo de vida definido pode servir a múltiplos propósitos deve ser construído rapidamente e com baixo custo é parte integrante de um design centrado no usuário, para avaliação e modificação Podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente algumas facetas do sistema a desenvolver.

Problemas O cliente vê o protótipo como uma versão de trabalho do software e exige a sua adequação para o produto, pensando no prazo e não considerando as questões de qualidade e manutenibilidade O desenvolvedor, muitas vezes, faz concessões de implementação e qualidade a fim de colocar um protótipo em funcionamento Definir as regras do jogo desde o início cliente e desenvolvedor devem estar cientes e de acordo em que o protótipo serve como um mecanismo de definição dos requisitos

Modelo de Desenvolvimento Rápido da Aplicações – RAD
É um modelo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto É uma adaptação do modelo seqüencial linear, no qual o desenvolvimento rápido se utiliza da construção baseada em componentes. Se os requisitos são bem compreendidos e o objetivo do projeto é restrito, o processo RAD permite a uma equipe de desenvolvimento criar um sistema plenamente funcional, dentro de períodos muito curtos (e. 60 a 90 dias) Muito aplicado a sistemas de informação

Fases Modelagem do negócio o fluxo de informação entre as funções do negócio é modelado Modelagem de dados o fluxo de informação é refinado num conjunto de objetos de dados necessários para dar suporte ao negócio. Os atributos e as relações são definidos Modelagem do processo descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados Geração da aplicação usa: técnicas de quarta geração; reuso e desenvolvimento de componentes; e ferramentas automatizadas para facilitar a construção Teste e entrega reutiliza componentes o que reduz o tempo de teste, porém os novos componentes e as interfaces precisam ser testados

Desvantagens Para projetos grandes exige RH suficiente para criar um número adequado de equipes RAD Exige desenvolvedores e clientes comprometidos com atividades rápidas Nem todos os tipos de aplicações são apropriadas. A abordagem RAD pode não funcionar se o software: não pode ser adequadamente modularizado exigir desempenho superior que deve ser conseguido através de ajustes das interfaces dos componentes Quando riscos técnicos forem elevados, o RAD não é adequado (novas tecnologias, interoperabilidade com outros sistemas, etc)

Exemplo de RAD – metodologias ágeis Extreme programing (XP) Valores definidos na metodologia Comunicação: a comunicação da equipe deve ser eficaz Simplicidade: a solução mais simples deve ser a selecionada para resolver o problema Feedback: o trabalho da equipe deve ser orientado ao feedback do cliente e ao software funcionado Coragem: as pessoas assumam responsabilidade sobre o trabalho a ser realizado

Extreme programing (XP) Práticas: Planejamento do jogo Releases pequenos Uso de metáforas para o projeto de software Design simples Testes automáticos Refactoring Programação em pares Propriedade coletiva do código Integração contínua 40 horas semanais de trabalho Cliente no local Padrão de codificação

Modelos Evolucionários
Modelo Incremental Modelo Espiral Modelo Espiral Ganha-Ganha Modelo Desenvolvimento Concorrente

O software evolui durante um período de tempo Requisitos do negócio e do produto mudam freqüentemente, à medida que o desenvolvimento prossegue Prazos reduzidos de mercado exigem versão reduzida Os modelos evolucionários são iterativos e permitem o desenvolvimento de versões cada vez mais completas do software Objetiva a elaboração de um produto operacional a cada incremento

Para a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema Abordagem híbrida Iteração repetir partes do processo à medida que os requisitos do sistema evoluem Por exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitos Cada ciclo desenvolve uma versão mais completa

Desenvolvimento Evolucionário

Modelo Incremental Combina cascata com prototipagem
Ao invés de entregar o sistema como um produto único, o desenvolvimento e entrega é quebrado em incrementos Cada seqüência linear produz um incremento factível, operacional do software Requisitos de usuário são priorizados e os de mais alta prioridade são desenvolvidos primeiro Uma vez que o desenvolvimento é iniciado, os requisitos são congelados, embora os requisitos para os demais incrementos continuem a evoluir É útil quando não há mão-de-obra disponível para uma implementação completa, dentro do prazo estabelecido

Modelo Incremental Exemplo: Processador de Texto
1o release: gestão básica de arquivos, edição e produção de documentos (núcleo do produto) 2o: capacidades mais sofisticadas de edição 3o: verificação sintática e gramatical 4o: capacidade avançada de disposição de página

Modelo Incremental

Modelo Incremental Vantagens Problemas
Os clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele. O primeiro estágio deve satisfazer os requisitos mais importantes e, assim, o software pode ser imediatamente usado Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posteriores Existe um risco menor de fracasso completo do sistema Problemas – Pode ser difícil mapear os requisitos para incrementos específicos – É difícil identificar facilidades comuns que todos os incrementos exijam

Modelo em Espiral Proposto por Boehm, em 1988
O processo não é descrito como uma seqüência de atividades (com eventuais retornos) O processo é representado como uma espiral, onde cada loop representa uma fase do processo. Foi desenvolvido para abranger as melhores características, tanto do ciclo de vida clássico como do de prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos

Modelo em Espiral O Processo Espiral é similar ao Incremental mas
Cada ciclo produz algo a ser avaliado não necessariamente código Gerência de Riscos embutida no processso Ao final de cada loop é perguntado “Devemos continuar?” As atividades do modelo em espiral formam uma estrutura chamada de regiões de tarefas

Modelo em Espiral de Bohem
O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Setores da Espiral: Definição de objetivos, alternativas e restrições Especificação de objetivos para a fase Identificação e Redução dos Riscos Riscos são identificados e as atividades são levantadas para tratá-los Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, o projeto pode ser cancelado Desenvolvimento e Validação Um modelo de desenvolvimento para o sistema é escolhida Pode ser qualquer um dos modelos genéricos Planejamento O projeto é revisado Se a decisão for continuar, um novo loop da espiral é planejado

Profª Fairus Manfroi

Modelo em Espiral Variações do modelo espiral de Bohem
Considera entre três e seis regiões de tarefas ou setores da espiral, que podem ser: Comunicação com o cliente: Estabelecer efetiva comunicação entre desenvolvedor e cliente Planejamento: Definir recursos, prazos, objetivos, alternativas, restrições e outras informações do projeto Análise de risco: Avaliar os riscos técnicos e gerenciais, análise de alternativas Engenharia: Construir uma ou mais representações da aplicação, desenvolvimento do produto. Construção e liberação: Construir, testar, instalar e fornecer apoio ao usuário (documentação, treinamento, ...) Avaliação pelo cliente: Obter um feedback do cliente, realimentando o processo.

Modelo em Espiral

Modelo em Espiral Um projeto de desenvolvimento conceitual começa no centro da espiral e continua até que o desenvolvimento conceitual se complete Se o conceito tiver que ser transformado em um produto real, o processo prossegue através do próximo ponto de entrada, e um novo projeto de desenvolvimento é iniciado O novo produto evolui em torno da espiral, seguindo o caminho para fora A espiral, caracterizada desse modo, permanece operacional até que o software seja descontinuado

Modelo em Espiral Cada interação ao redor da espiral possibilita a construção de versões progressivamente mais complexas. Outros modelos de ciclo de vida podem ser usados para elucidar requisitos, tais como o de prototipagem. O paradigma do modelo espiral é, atualmente, a abordagem mais realística para o desenvolvimento de software de grande porte. Usa uma abordagem evolucionária, capacitando o desenvolvedor e o cliente a entenderem e reagirem aos riscos de cada etapa evolutiva. Usa prototipagem como mecanismo de redução de risco, mas permite aplicar prototipagem em qualquer etapa do processo.

Modelo em Espiral Vantagens
O modelo em espiral permite que, ao longo de cada iteração, se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos. Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.

Modelo em Espiral No entanto...
A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e fia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas. O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Modelo em Espiral ganha-ganha
Define um conjunto de atividades de negociação no começo de cada passagem em torno da espiral Ao invés de só uma atividade de comunicação com o cliente, as seguintes atividades são definidas: Identificação dos principais interessados (stakeholders) do sistema ou subsistema Determinação das condições de lucro do interessado Negociação das condições de ganho do interessado para reconciliá-lo no âmbito das condições ganha- ganha para todos os envolvidos

Modelos Evolucionários – Modelo em Espiral ganha-ganha

Desenvolvimento Baseado em Componentes
Incorpora técnicas de orientação a objetos Incorpora as características do modelo espiral e compõe aplicações a partir de componentes de software previamente desenvolvidos ou desenvolvidos durante o processo. Enfatiza a reutilização, isto é desenvolve para e com reuso. Fases do processo Análise do Componente; Modificação dos requisitos; Projeto do sistema com reuso; Desenvolvimento e integração.

Modelo de Métodos Formais
Baseado na transformação de uma série de representações matemáticas da especificação em um programa executável. A especificação de requisitos, informal ou semi-formal, é redefinida em uma especificação formal detalhada, utilizando uma notação matemática: VDM, Z, B, Larch e outras Baseado na transformação de uma especificação matemática através de refinamentos sucessivos até um programa executável As atividades de design, implementação e testes são substituídas por um processo transformacional. Transformações devem “preservar a correção”, isto é, permitem mostrar que o programa está de acordo com a sua especificação Exemplo mais conhecido: Cleanroom (IBM) Incremental, onde para cada estágio é demonstrada a correção em relação ao anterior

Problemas Demanda pessoal especializado Como poucos desenvolvedores de software tem o preparo necessário para aplicar métodos formais, torna-se necessário treinamento extensivo Dificuldade em especificar formalmente alguns aspectos de sistemas Interface com usuário É difícil usar os modelos como um mecanismo de comunicação, com clientes despreparados tecnicamente Aplicação Sistemas críticos onde segurança e/ou confiabilidade devem ser garantidas antes mesmo que o sistema entre em operação Eletrônica de aeronaves, dispositivos médicos, ... Desenvolvedores que queiram evitar multas caso ocorram falhas (transações financeiras, etc)

Desenvolvimento orientado ao reuso
Baseia-se na reutilização sistemática onde sistemas são integrados a partir de Componentes existentes (in-house) Componentes de prateleira [COTS (Commercial- off-the-shelf)] Estágios do processo Análise dos componentes Projeto de sistema com reuso Desenvolvimento e integração Processo promissor, mas existe pouca experiência

Desenvolvimento orientado ao reuso

Roteiro Framework RUP

Rational Unified Process

Rational Unified Process (RUP)
Desenvolvimento do software iterativamente Gerenciamento dos requisitos Uso de arquiteturas baseadas em componentes Modelagem visual do software Verificação da qualidade do software Controle de mudanças do software

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

Rational Unified Process (RUP)
Um modelo de processo derivado do trabalho com UML e processos associados. Normalmente descrito sob 3 perspectivas Dinâmica: mostra as fases ao longo do tempo; Estática: mostra as atividades do processo; Prática: sugere boas práticas.

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

Rational Unified Process (RUP) Ciclo de vida de desenvolvimento
Profª Fairus Manfroi

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?

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 (RUP) Fases 1: Concepção (Inception)
Definição do escopo e do business case (caso de negócio) que inclui critérios de sucesso, avaliação de riscos, recursos necessários Plano p/ as fases seguintes incluindo escalonamento Ao fim desta fase os objetivos do projecto são examinados e decisões devem ser tomadas Documentos: overview do problema, use cases principais, glossário inicial, relatório inicial de avaliação de riscos, business case, plano de projeto, protótipos iniciais

Rational Unified Process (RUP) Fases 2: Elaboração (Elaboration)
Analisar o domínio do problema em detalhe Definir uma arquitetura Detalhar o plano de projecto Eliminar os riscos elevados Resultados: requisitos funcionais do sistema (através de use cases) e não funcionais, descrição da arquitetura, resolução dos principais riscos, decisão p/ proceder c/ a construção

Rational Unified Process (RUP) Fases 3: Construção (Construction)
Desenvolvimento detalhado do desenho, implementação, integração dos componentes, e testes exaustivos É prestada atenção ao controlo de custos, prazos e qualidade do produto

Rational Unified Process (RUP) Fases 4: Transição (Transition)
O software (versão beta) é entregue aos utilizadores Substituído posteriormente pelo sistema de produção

Rational Unified Process (RUP) Artefatos
Modelo do negócio (da organização) Modelo do domínio (contexto) Modelo de use case (requisitos funcionais) Modelo de análise Modelo de desenho Modelo de processo (concorrência e sincronização) Modelo de instalação (topologia do HW) Modelo de implementação Modelo de teste

Abordagens para nortear o desenvolvimento de software
Desenvolvimento Orientado a Função: O sistema é visto como um conjunto de funções; O sistema consiste em uma decomposição progressiva de funções de sua funcionalidade; As funções cada vez mais simples, resultantes da decomposição, são implementadas. Desenvolvimento Orientado a Evento: O sistema é particionado de acordo com os evento que ocorrem no seu ambiente, os quais devem ser adequadamente respondidos. Desenvolvimento Orientado a Dados: A atenção é voltada à definição de uma estrutura de dados; As funções são construídas em torno das abstrações de dados.

Abordagens para nortear o desenvolvimento de software
Desenvolvimento Orientado a Objetos (DOO): Na abordagem orientada a objetos um sistema é construído como um conjunto de Objetos (entidades) interativos que encapsulam dados e operações que atuam sobre estes dados. A orientação a objetos baseia-se na abstração dos dados e ocultamento da informação. Desenvolvimento Orientado a Aspectos (DSOA ) o pensamento inteligente é capaz de estudar um aspecto de determinado problema isoladamente, mas sabendo o tempo todo que outros aspectos estão esperando sua vez. DSOA é uma técnica para melhorar a separação de concerns na construção de software e apoiar ao aumento da reusabilidade e facilidade de evolução. Apóia a modularização de crosscutting concerns por meio de abstrações que possibilitam a sua separação e composição para produzir o sistema. Nova forma de abstração e novo mecanismo para compor aspectos e classes.

Roteiro Métodos Ágeis

Novos ventos no mundo do Desenvolvimento de Software
Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente para desenvolver tanto software com qualidade. Copyleft Fabio Kon

Problemas Com metodologias de desenvolvimento Com software
Supõem que é possível prever o futuro Pouca interação com os clientes Ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.) Avaliação do progresso baseado na evolução da burocracia e não do código Com software Grande quantidade de erros Falta de flexibilidade Copyleft Fabio Kon

Como resolver esse impasse?
Melhores Tecnologias Padrões de Projeto (reutilização de idéias) Componentes (reutilização de código) Middleware (aumenta a abstração) Melhores Metodologias Métodos Ágeis (o foco nesta disciplina) outras... (abordadas, p.ex., na disciplina ES) Copyleft Fabio Kon

Metodologias de Desenvolvimento de Software OO
“Tradicionais” Comunidade de Engenharia de Software IEEE/ACM ICSE p.ex. Carnegie-Mellon SEI RUP, CMM, etc. Ágeis Comunidade de POO ACM OOPSLA p.ex. Illinois, Beck, Cockburn, Jeffries, Cunningham… XP, Crystal, Scrum, etc. Copyleft Fabio Kon

Métodos Ágeis de Desenvolvimento de Software
Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se opõe a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos. Manifesto Ágil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001. Copyleft Fabio Kon

O Manifesto do Desenvolvimento Ágil de Software
Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente é mais importante do que negociação de contratos. Adaptação a mudanças é mais importante do que seguir o plano inicial. Copyleft Fabio Kon

Princípios do Manifesto Ágil
Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor. Entregar versões funcionais em prazos curtos. Estar preparado para requisitos mutantes. Pessoal de negócios e desenvolvedores juntos. Troca de informações através de conversas diretas. Copyleft Fabio Kon

Principais Métodos Ágeis
Nesta disciplina veremos: Programação eXtrema (XP) Outros métodos ágeis interessantes: Crystal (uma família de métodos) Scrum Adaptive Software Development Feature Driven Development etc. Copyleft Fabio Kon

Gerência de Projetos com Metodologias Ágeis e Scrum

Gerência de Projetos com Metodologias Ágeis e Scrum
Introdução Por que métodos ágeis? Controle Empírico de Processos Scrum Artefatos do Scrum Papéis do Scrum Regras do Scrum Métodos Tradicionais versus Métodos Ágeis Conclusão

Introdução Controle empírico para projetos complexos
Projetos não completamente definidos e que precisam ser executados com urgência Scrum: uma metodologia ágil Projetos complexos e variáveis no tempo Descentralização do controle Igualdade de responsabilidade

Por que métodos ágeis? Urgência e alta complexidade
Métodos tradicionais Refletem a complexidade do problema na sua gerência Falham na gerência de projetos que não podem ser totalmente especificados Gerente de Projetos: ponto único de falhas Analogia ao desenvolvimento de softwares de forma estática e monolítica

Por que métodos ágeis? Métodos ágeis
Valiosos no tratamento de projetos parcialmente definidos Resultado incremental aumenta ROI (return on investiment) Stakeholders podem visualizar/utilizar os resultados Tem maior poder de escolha dos caminhos do projeto Decisões baseadas em fatos Melhor do que qualquer previsão Decisão distribuída entre os envolvidos no projeto (não apenas o gerente)

Controle Empírico de Processo
Problemas complexos são aqueles imprevisíveis Gerenciá-los através de métodos tradicionais e modelos probabilísticos seria muito complexo Sociedade é baseada em processos que funcionam porque há um grau de imprecisão aceitável

Controle Empírico de Processo
Para produtos que precisam uma precisão maior do que a média É preciso se certificar a cada passo se o processo está convergindo Projetar um processo que repetidamente produz um produto de qualidade aceitável é chamado de controle definido de processo Utiliza-se controle definido sempre que os mecanismos pelos quais os processos operam são bem entendidos Analogia a commodities: processo bem definido e imutável Quando um controle definido não pode ser aplicado devido à sua complexidade, algo como controle empírico de processos deverá ser aplicado

Bases do Controle Empírico de Processo
Visibilidade Aspectos do projeto que afetam a sua execução precisam ser visíveis e verdadeiros Permite o controle do processo Inspeção Diversos aspectos do projeto precisam ser inspecionados em uma freqüência suficiente Variações não aceitáveis devem ser detectadas Adaptação Se determinado que algum aspecto está fora dos limites aceitáveis, deve-se adaptá-lo rapidamente para minimizar desvios futuros

Scrum Uma alternativa de utilizar métodos ágeis na gerência de projetos Aplicável especificamente a projetos de softwares É um processo simples Processo, artefatos e regras são poucas e fáceis de entender Simplicidade deste pode ser decepcionante aos acostumados com metodologias tradicionais As vezes é difícil fazer com que as simples regras sejam corretamente aplicadas

Scrum Não é um método prescritivo
Não define previamente o que deve ser feito em cada situação Projetos complexos não permitem prever todos os eventos Define um framework e um conjunto de práticas que permitem as bases do controle empírico Aplica o senso comum Combinação de experiência, treinamento, confiança e inteligência de toda a equipe Senso comum em vez do senso de uma única pessoa é uma das razões do sucesso do Scrum

Esqueleto e Coração do Scrum

Artefatos do Scrum: Product Backlog
Lista priorizada dos requisitos do projeto com o tempo estimado para torná-los em funcionalidade Estimativas em dias, sendo mais precisas para itens mais prioritários Mudanças podem ser feitas de acordo com as necessidades que aparecem Nunca está completo, sendo que o utilizado no plano de projeto é meramente uma estimativa inicial dos requisitos O responsável é o Product Owner

Qualquer membro do time pode adicionar ou remover itens Com consentimento do Product Owner São requisitos funcionais ou não-funcionais, ou qualquer tópico de discussão Os itens com maior prioridade serão selecionados para o próximo Sprint Quanto menos prioritários, mais abstratos são os itens Podem existir muito mais requisitos que não foram ainda listados ou nem pensados É atualizado pelo Product Owner sempre que necessário Permite a adaptabilidade do processo

Artefatos do Scrum: Sprint Backlog
Lista de tarefas que define o trabalho do time durante o Sprint Cada tarefa identifica o responsável que irá trabalhar sobre ela e o restante do tempo estimado para terminá-la em dias Tarefas devem estar organizadas para que estejam em 4 a 16 horas de trabalho Tarefas maiores são consideradas placeholders Substituições de tarefas que não foram propriamente definidas Apenas o time pode modificá-lo É como uma fotografia do trabalho do Sprint

Artefatos do Scrum: Sprint Backlog

Artefatos do Scrum: Gráfico de Burndown
Representa o trabalho total restante dentro de um Sprint, de um release ou produto A origem dos dados para criar este gráfico é o Sprint Backlog ou o Product Backlog

Artefatos do Scrum: Potentially Shippable Increment
Um incremento é uma funcionalidade do produto desenvolvida pelo time durante o Sprint Deve ser um incremento completamente desenvolvido, que contenha as características de um produto finalizado Product Owner pode escolher implementar imediatamente a funcionalidade desenvolvida Cada incremento deve ter sido bem codificado, testado e documentado

Papéis no Scrum: Product Owner
Responsável por apresentar os interesses de todos os stakeholders Define fundamentos iniciais do projeto, objetivos com relação ao ROI e planos de release A lista de requerimentos é o Product Backlog Certifica se as atividades com maior valor para o negócio são criadas primeiro Priorização freqüente das funcionalidades antes de cada iteração

Papéis no Scrum: Time Responsável por escolher as funcionalidades a serem desenvolvidas e cada interação e desenvolvê-las O time se auto-gerencia, se auto-organiza Todos os membros do time são coletivamente responsáveis pelo sucesso de cada iteração

Papéis no Scrum: ScrumMaster
Responsável pelo sucesso do Scrum Ensina o Scrum para os envolvidos com o projeto Implementa o Scrum na empresa de forma adaptada a sua cultura, para continuamente gerar benefícios Certifica se cada pessoa envolvida está seguindo seus papéis e as regras do Scrum Certifica que pessoas não responsáveis não interfiram no processo

Papéis no Scrum Todas as responsabilidades de gerenciamento são divididas entre estes três papéis Para o bom funcionamento do Scrum as pessoas responsáveis pelo projeto devem ter autoridade para fazer o que for necessário pelo sucesso desse Pessoas não responsáveis não podem interferir no projeto Gera aumento de produtividade Propicia o momentum (cada interferência tem o tempo certo para ser feita) Evita situações constrangedoras para os envolvidos

Regras do Scrum ScrumMaster deve se certificar de que cada envolvido no projeto siga suas regras As regras permitem a execução correta do Scrum Mudanças das regras devem originar do time ScrumMaster deve ser convencido de que todos envolvidos entenderam suficientemente as regras do Scrum para o correto discernimento Discussões desnecessárias são perdas de tempo de produção da equipe

Regras do Scrum: Sprint Planning Meeting
A reunião de planejamento do Sprint deve ocorrer dentro de 8 horas com duas partes de 4 horas Primeiro seguimento: Product Owner deve preparar o Product Backlog antes da reunião Seleção dos itens do Product Backlog que o time se compromete em torná-los incrementos potencialmente implementáveis Decisão final é do Product Owner Stakeholders não devem participar

Regras do Scrum: Sprint Planning Meeting
Segundo seguimento: Ocorre imediatamente após o primeiro Product Owner deve estar disponível para o que o time faça perguntas sobre o Product Backlog O time deve decidir sozinho como os itens selecionados serão implementados Nenhum outro participante pode fazer perguntas ou observações nesta parte Resultado deste seguimento é o Sprint Backlog

Regras do Scrum: Reunião Diária do Scrum
Reunião de no máximo 15 minutos, a menos que o time seja grande o suficiente para precisar de mais tempo Deve ser feita no mesmo lugar onde o time trabalha Resulta em melhores resultados se realizada no inicio do dia de trabalho Todos os membros do time devem participar desta reunião

Regras do Scrum: Reunião Diária do Scrum
ScrumMaster faz as seguintes perguntas para cada membro do time: O que você fez desde a última reunião diária do Scrum relacionada a este projeto? O que você irá fazer desde agora até a próxima reunião diária do Scrum relacionada a este projeto? O que está impedindo você de realizar o seu trabalho o mais efetivamente possível? Os membros devem responder apenas a estas perguntas para não estender a reunião

Regras do Scrum: Sprint
Não deve ser maior do que 30 dias consecutivos Sem considerar outros fatores, este é o tempo necessário para produzir algo de interesse para o Product Owner e os stakeholders O time pode pesquisar e requisitar ajuda externa Ninguém deve prover conselhos, comentários ou direções ao time durante o Sprint O time se auto-gerencia O time se compromete com o Product Backlog Não é permitida modificações nele durante o Sprint

Regras do Scrum: Sprint
Responsabilidades do time durante o Sprint: Participar das reuniões diárias do Scrum Manter o Sprint Backlog atualizado Disponibilizar o Sprint Backlog publicamente O time tem o compromisso de implementar todos os itens selecionados

Regras do Scrum: Reunião de Revisão do Sprint
Reunião de no máximo 4 horas sob responsabilidade do ScrumMaster O time não deve gastar mais de 1 hora na preparação desta reunião Objetivo: mostrar o Product Owner e stakeholders as funcionalidades que foram feitas Artefatos não devem ser apresentados, pois não são funcionalidades No final da reunião Cada stakeholder fala suas impressões e sugere mudanças com suas respectivas prioridades Possíveis modificações no Product Backlog são discutidas entre o Product Owner e o time ScrumMaster anuncia a data e o local da próxima reunião de revisão do Sprint ao Product Owner e a todos stakeholders

Regras do Scrum: Reunião Retrospectiva do Sprint
Não deve ser maior do que 3 horas. Participam desta reunião: time, o ScrumMaster e, opcionalmente, o Product Owner Os membros do time devem responder a duas questões: O que aconteceu de bom durante o último Sprint? O que pode ser melhorado para o próximo Sprint? ScrumMaster escreve as respostas e prioriza na ordem que deseja discutir as potenciais melhorias ScrumMaster neste reunião tem o papel de facilitar que o time encontre melhores formas de aplicar o Scrum

Métodos Tradicionais versus Métodos Ágeis
Gerente de projetos controla cada atividade Pré-definição de cada solução e atividade Antecipação de situações de risco, permitindo bem tratá- las Documentação extensa Projetos que podem ser totalmente previstos Métodos Ágeis Descentralização do controle Definição incremental de soluções e atividades Situações de risco são percebidas no inicio de cada ciclo Documentação reduzida Projetos parcialmente definidos (definição tardia)

Situações em que Métodos Ágeis e Scrum não podem ser aplicados: Projetos críticos que exigem alto grau de confiabilidade e qualidade (ex: projeto de um software controlador de vôos) Quando se deseja terceirização da mão-de-obra de programação, há a necessidade de uma documentação bem definida Equipes com membros dispersos pelo mundo não podem realizar o Daily Scrum Meeting, não sendo possível aplicá-lo (equipes muito grandes também problemas) Quando o Product Owner não pode estar tão presente freqüentemente, o Scrum também é inviabilizado

Métodos Ágeis geram bons resultados em: Equipes pequenas de desenvolvimento (até 15 membros) Pode-se aplicar Meta-Scrum para equipes maiores Equipes competentes Capacidade de auto-gerenciamento não é uma virtude tão comum Projetos complexos porém que se possa consultar os interessados sempre que necessário

Conclusão Projetos complexos e urgentes necessitam de uma nova abordagem Scrum é uma boa solução de controle empírico É eficiente quando as regras e os papéis são bem seguidos Apesar da sua simplicidade, as pessoas costumam não aceitar facilmente a nova abordagem Há diversos casos de sucesso Deve-se considerar as condições da equipe e a características dos projetos antes de uma migração Sistemas operacionais e controles de automóveis continuaram seguindo a abordagem tradicional

Bibliografia SCHWABER, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2004. MOUNTAIN GOAT SOFTWARE. The Scrum Process Development. Disponível em: < um/>. Acesso em: Setembro, 2006. SUTHERLAND, Jeff. ScrumWeb Home Page: A Guide to the SCRUM Development Process. Jeff Sutherland’s Object Technology Web Page. Disponível em: < m/index.html>. Acesso em: Setembro, 2006.

Scrum Jeff Suttherland Ken Schwaber Conferências Inspiração
Ken Schwaber Conferências OOPSLA 96, PLoP 98 Inspiração Desenvolvimento Iterativo e Incremental em empresas (DuPont, Honda, etc) nos anos 80 Copyleft Fabio Kon

Programação eXtrema XP
Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos. Ganhou notoriedade a partir da OOPSLA’2000. Nome principal: Kent Beck. Copyleft Fabio Kon

XP – Princípios e técnicas
Teste automatizado contínuo Integração contínua Alto envolvimento do usuário Programação por “times” Atenção específica às limitações e interações humanas

Abordagem no desenvolvimento com Extreme Programming

Desenvolvimento Tradicional, Espiral, e XP
Comparação de Ciclos de Vida Desenvolvimento Tradicional, Espiral, e XP

Reações a XP Alguns odeiam, outros amam. Quem gosta de programar ama!
Deixa o bom programador livre para fazer o que ele faria se não houvesse regras. Força o [mau] programador a se comportar de uma forma similar ao bom programador. Copyleft Fabio Kon

Premissas Básicas do Modelo Tradicional
É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

O que está por trás deste modelo?
Custo de mudanças requisitos desenho testes análise implementação produção

E se a realidade hoje em dia fosse outra?
Custo de mudanças tempo

E se essa fosse a realidade?
A atitude dos desenvolvedores de software seria completamente diferente: Tomaríamos as grandes decisões o mais tarde possível. Implementaríamos agora somente o que precisamos agora. Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

E essa é a nova realidade ! (pelo menos em muitos casos)
Orientação a Objetos: facilita e cria oportunidades para mudanças. Técnicas de Refatoração. Testes automatizados: nos dão segurança quando fazemos mudanças. Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em lidar com código mutante.

A Quem se Destina XP? Grupos de 2 a 10 programadores
Projetos de 1 a 36 meses (calendário) De 1000 a linhas de código Papéis: Programadores (foco central)(sem hierarquia) “Treinador” ou “Técnico” (coach) “Acompanhador” (tracker) Cliente

E Se Eu Não Me Encaixo Nesses Casos?
Você ainda pode aprender muito sobre desenvolvimento de software. Terá elementos para repensar as suas práticas. No início se dizia: “Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP.” XP is like teenage sex. Hoje não é mais necessariamente assim.

As 12 Práticas de XP (versão 2000)
Planejamento Fases Pequenas Metáfora Design Simples Testes Refatoração Programação Pareada Propriedade Coletiva Integração Contínua Semana de 40 horas Cliente junto aos desenvolvedores Padronização do código

Princípios Básicos de XP
Feedback rápido Simplicidade é o melhor negócio Mudanças incrementais Carregue a bandeira das mudanças / não valorize o medo (Embrace change) Alta qualidade do código

As 4 Variáveis do Desenvolvimento de Software
Tempo Custo Qualidade Escopo (foco principal de XP)

Um Projeto XP Fase de Exploração duração: 2 a 6 meses.
termina quando a primeira versão do software é enviada ao cliente. clientes escrevem “historias” (story cards). programadores interagem com clientes e discutem tecnologias. Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. Planejamento: 1 a 2 dias.

Um Dia na Vida de um Programador XP
Escolhe uma história do cliente. Procura um par livre. Escolhe um computador para programação pareada. Seleciona um “cartão de história” contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

Discute modificações recentes no sistema Discute história do cliente Testes Implementação Projeto (design) Integração

Atos constantes no desenvolvimento: Executa testes antigos. Busca oportunidades para simplificação. Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento. Escreve novos testes. Enquanto todos os testes não rodam a 100%, o trabalho não está terminado. Integra novo código ao repositório.

Testes Fundamento mais importante de XP.
É o que dá segurança e coragem ao grupo. Testes de unidades (Unit tests) escritos pelos programadores para testar cada elemento do sistema (e.g., cada método em cada caso). Testes de funcionalidades (Functional tests) escritos pelos clientes para testar a funcionalidade do sistema.

Testes Testes das unidades do sistema Testes das funcionalidades
Tem que estar sempre funcionando a 100%. São executados várias vezes por dia. Executados à noite automaticamente. Testes das funcionalidades Vão crescendo de 0% a 100%. Quando chegam a 100% acabou o projeto.

O Código Padrões de estilo adotados pelo grupo inteiro.
O mais claro possível. XP não se baseia em documentações detalhadas e extensas (perde-se sincronia). Comentários sempre que necessários. Comentários padronizados. Programação Pareada ajuda muito!

Programação Pareada Erro de um detectado imediatamente pelo outro (grande economia de tempo). Maior diversidade de idéias, técnicas, algoritmos. Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc. Vergonha de escrever código feio (gambiarras) na frente do seu par. Pareamento de acordo com especialidades. Ex.: Sistema Multimídia Orientado a Objetos

Propriedade Coletiva do Código
Modelo tradicional: só autor de uma função pode modificá-la. XP: o código pertence a todos. Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça. Mas rode os testes!

Refatoração (Refactoring)
Uma [pequena] modificação no sistema que não altera o seu comportamento funcional mas que melhora alguma qualidade não- funcional: simplicidade flexibilidade clareza desempenho

Exemplos de Refatoração
Mudança do nome de variáveis Mudanças nas interfaces dos objetos Pequenas mudanças arquiteturais Encapsular código repetido em um novo método Generalização de métodos raizQuadrada(float x) raiz(float x, int n)

Cliente Responsável por escrever “histórias”.
Muitas vezes é um programador ou é representado por um programador do grupo. Trabalha no mesmo espaço físico do grupo. Novas versões são enviadas para produção todo mês (ou toda semana). Feedback do cliente é essencial. Requisitos mudam (e isso não é mau).

Coach (treinador) Em geral, o mais experiente do grupo.
Identifica quem é bom no que. Lembra a todos as regras do jogo (XP). Eventualmente faz programação pareada. Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias. Seu papel diminui à medida em que o time fica mais maduro.

Tracker (Acompanhador)
A “consciência” do time. Coleta estatísticas sobre o andamento do projeto. Alguns exemplos: Número de histórias definidas e implementadas. Número de unit tests. Número de testes funcionais definidos e funcionando. Número de classes, métodos, linhas de código Mantém histórico do progresso. Faz estimativas para o futuro.

Quando usar XP Equipes de projeto pequenas (12 ou menos)
Pessoal de desenvolvimento bem treinado e talentoso Escopo limitado nos projetos Aplicatipos que rodarão sózinhos Novos sistemas Interface mínimo com sistemas legados Uso extensivo de ferramentas de desenvolvimento e de testes orientadas a objeto.

Quando XP Não Deve Ser Experimentada?
Quando o cliente não aceita as regras do jogo. Quando o cliente quer uma especificação detalhada do sistema antes de começar. Quando os programadores não estão dispostos a seguir (todas) as regras. Se (quase) todos os programadores do time são medíocres. Copyleft Fabio Kon

Quando XP Não Deve Ser Experimentada?
Grupos grandes (>10 programadores). Quando feedback rápido não é possível: sistema demora 6h para compilar. testes demoram 12h para rodar. exigência de certificação que demora meses. Quando o custo de mudanças é essencialmente exponencial. Quando não é possível realizar testes (muito raro). Copyleft Fabio Kon

Conclusão Vencendo os Medos
Escrever código. Mudar de idéia. Ir em frente sem saber tudo sobre o futuro. Confiar em outras pessoas. Mudar a arquitetura de um sistema em funcionamento. Escrever testes. Copyleft Fabio Kon

As 12 Práticas de XP (versão 2000)
Planejamento Fases Pequenas Metáfora Design Simples Testes Refatoramento Programação Pareada Propriedade Coletiva Integração Contínua Semana de 40 horas Cliente junto aos desenvolvedores Padronização do código Copyleft Fabio Kon

Práticas de XP As práticas foram refatoradas (veja Mas a idéia é exatamente a mesma Novas práticas interessantes: Conserte XP quando a metodologia quebrar. Mova as pessoas. Client Proxy (by Klaus) Copyleft Fabio Kon

Conclusão XP não é para todo mundo.
Mas todo mundo pode aprender com ela. Copyleft Fabio Kon

Características Comuns dos Métodos Ágeis
Coloca o foco Na entrega freqüente de sub-versões do software [funcionando] para o cliente. Nos seres humanos que desenvolvem o software. Retira o foco de Processos rígidos e burocratizados. Documentações e contratos detalhados. Ferramentas que são usadas pelos seres humanos. Copyleft Fabio Kon

www.xispe.com.br www.extremeprogramming.org
Maiores Informações Copyleft Fabio Kon

Roteiro Trabalhos

Arquitetura de Computadores
Exercícios em Sala Arquitetura de Computadores

EXERCÍCIO 1: Aula 1 (1 ponto)
Questões: Monte uma tabela comparativa (+/-) entre os diferentes processos de desenvolvimento: Cascata, Incremental / RUP, XP, Scrum Ilustre situações em que cada um dos processos de desenvolvimento seria melhor indicado. Detalhamento: Trabalho a ser desenvolvido em equipes de até 4 pessoas; Pontuação: relevância e aderência ao tema, criatividade, capacidade de raciocínio e visão de mercado / pesquisa; Forma de trabalho: Folha avulsa; Data de entrega: Diária. Sugestão: ilustrar com exemplos.

Exercícios em Casa Estágio II

TRABALHO 1: Aula 1 (1 ponto)
Descrição: Monte um Documento de Visão Técnica para um sistema escolhido. O sistema deve ter funcionalidades como acessibilidade Web, arquitetura em camadas, múltiplos perfis de usuário. Apresente igualmente a WBS do sistema. Detalhamento: Trabalho a ser desenvolvido em equipes de até 4 pessoas; Pontuação: relevância e aderência ao tema, criatividade, capacidade de raciocínio e visão de mercado / pesquisa; Forma de trabalho: Folha avulsa; Data de entrega: Diária. Sugestão: ilustrar com exemplos.

Grato pela Atenção FA7– Fortaleza, 02/01/10

Metodologias de Desenvolvimento

Apresentações semelhantes

Apresentação em tema: "Metodologias de Desenvolvimento"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Metodologias de Desenvolvimento

Apresentações semelhantes

Apresentação em tema: "Metodologias de Desenvolvimento"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback