Os objetivos principais da fase Iniciação incluem:

(1)

FASES Iniciação

Os objetivos principais da fase Iniciação incluem:

Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.

Discriminar os casos de uso críticos do sistema, os principais cenários de operação que direcionarão as principais trocas de design.

Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos.

Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração)

Calcular os riscos em potencial (as fontes de imprevistos) (Consulte Conceito:

Risco)

Preparar o ambiente de suporte para o projeto.

Elaboração

Os objetivos principais da fase Elaboração incluem:

Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca também corresponde à transição de uma operação rápida e de baixo risco para uma operação de alto custo e alto risco com uma inércia organizacional freqüente.

Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.

Estabelecer uma arquitetura de baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto.

Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos de pesquisa, descartáveis, para diminuir riscos específicos como:

o

trocas de design/requisitos

o

reutilização de componentes

o

possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais

Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo.

Estabelecer um ambiente de suporte.

As atividades essenciais da fase Elaboração incluem:

Definir, validar e criar a baseline da arquitetura, com rapidez e praticidade.

(2)

Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento.

Criar planos de iteração detalhados de baselines para a fase de construção.

Refinar o processo de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automação necessário para dar assistência à equipe de construção.

Refinar a arquitetura e selecionar componentes. Os componentes potenciais são avaliados e as decisões de fazer/comprar/reutilizar são bem compreendidas para determinar o custo da fase de construção e programar com confiança. Os componentes de arquitetura selecionados são integrados e avaliados em comparação com os cenários básicos. As lições aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em consideração designs alternativos ou reconsiderando os requisitos.

Construção

Os objetivos principais da fase Construção incluem:

Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e retrabalho desnecessários.

Atingir a qualidade adequada com rapidez e eficiência.

Atingir as versões úteis (alfa, beta e outros releases de teste) com rapidez e eficiência.

Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades necessárias.

Desenvolver de modo iterativo e incremental um produto completo que esteja pronto para a transição para a sua comunidade de usuários. Isso implica na descrição dos casos de uso restantes e de outros Requisitos, atualizando o design, concluindo a Implementação e testando o software.

Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja implantado.

Atingir um grau de paralelismo no trabalho das equipes de desenvolvimento.

Mesmo em projetos menores, normalmente há componentes que podem ser desenvolvidos um independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos permitirem). O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas também aumenta a complexidade do gerenciamento de recursos e da sincronização dos fluxos de trabalho. Uma arquitetura sofisticada será essencial para atingir um paralelismo significativo.

Transição

Os objetivos primários da Fase de Transição incluem:

teste beta para validar o novo sistema em confronto com as expectativas do usuário

teste beta e operação paralela relativa a um sistema legado que está sendo substituído

conversão de bancos de dados operacionais

treinamento de usuários e equipe de manutenção

(3)

introdução a marketing, distribuição e equipe de vendas

engenharia voltada para implementação, como preparação, empacotamento e produção comercial, introdução a vendas, treinamento de pessoal em campo atividades de ajuste, como correção de erros, melhoria no desempenho e na usabilidade

avaliação das baselines de implementação tendo como base a visão completa e os critérios de aceitação para o produto

obtenção de auto-suportabilidade do usuário

obtenção do consentimento dos envolvidos de que as baselines de implementação estão completas

obtenção do consentimento dos envolvidos de que as baselines de implementação são consistentes com os critérios de avaliação da visão Atividades Essenciais

As atividades essenciais da fase de Transição incluem o seguinte:

executar planos de implementação

finalizar o material de suporte para o usuário final testar o produto liberado no local do desenvolvimento criar um release do produto

obter feedback do usuário

ajustar o produto com base em feedback tornar o produto disponível aos usuários

Atribuições (Papeis) [http://www.wthreex.com/rup/v711_sp_ptbr/index.htm]

Função: Analista de Sistemas

Essa função lidera e coordena a obtenção de requisitos, delimitando o sistema e definindo sua funcionalidade.

Conjuntos de Funções: Analistas

Expandir Todas as Seções Reduzir Todas as Seções Relacionamentos

Modifica:

Agente Caso de Uso Esboço Seqüencial

Especificações Suplementares Glossário

Modelo de Casos de Uso

(4)

Pedidos dos Envolvidos Visão

Definição de Função: Desenvolvedores

Esse conjunto de função está envolvido principalmente no design e na implementação do software.

Funções Arquiteto de Software Designer

Designer de Banco de Dados Designer de Interface com o Usuário

Implementador Integrador

Definição de Função: Funções Gerais

Esse conjunto de função inclui aquelas funções que não se ajustam aos outros conjuntos de função. Por exemplo, a função "Qualquer Função"

abrange as atividades de gerenciamento de mudanças que podem ser executadas por qualquer um no projeto.

Funções Coordenador de Revisão Envolvidos

Revisor

Revisor Técnico Todas as Funções

Definição de Função: Gerenciadores

Esse conjunto de funções é envolvido principalmente no gerenciamento e na configuração do processo de engenharia de software.

Funções Administrador de Sistemas Coordenador de Projeto Gerenciador de Configuração Gerenciador de Controle de Mudanças

Gerenciador de Teste Revisor de Gerenciamento

Definição de Função: Produção e Suporte

Esse conjunto de função consiste naquelas funções não diretamente relacionada à definição, ao gerenciamento, ao desenvolvimento e ao teste de software, mas que não são necessárias para suportar o processo de desenvolvimento de software ou para produzir materiais adicionais exigidos pelo produto final.

Expandir Todas as Seções Reduzir Todas as Seções

(5)

Relacionamentos

Funções Administrador de Sistemas

Engenheiro de Processo

Definição de Função: Testadores

Este conjunto de função está envolvido principalmente no teste do software.

Funções Analista de Teste Designer de Teste Gerenciador de Teste Testador

Voltar ao Início da Página Descrição Principal

Esse conjunto de função trata de habilidades específicas exclusivas para teste.

Observe que existem funções adicionais envolvidas na disciplina Teste que juntas ampliam as habilidades básicas de outras funções. Essas funções adicionais podem ser encontradas nas demais funções organizadas pelas habilidades básicas que estendem (por exemplo, Gerente, D

Disciplinas

Esta é uma coleta de Disciplinas do RUP publicadas nesta configuração.

Conteúdo Requisitos Análise e Design Implementação Teste

Configuração e Gerenciamento de Mudanças Gerenciamento de Projeto

Ambiente

Voltar ao Início da Página

Disciplina: Requisitos

Esta disciplina explica como eliciar os requisitos dos investidores e

transformá-los em um conjunto de requisitos de Produtos de Trabalho, no escopo do sistema a ser construído e fornece requisitos detalhados sobre o que faz o sistema.

(6)

Fluxos de Trabalho de Referência

Requisitos

Tarefas Captar um Vocabulário Comum Desenvolver a Visão

Desenvolver Especificações Suplementares Detalhar os Requisitos de Software

Detalhar um Caso de Uso

Estruturar o Modelo de Caso de Uso Identificar Pedidos dos Envolvidos Localizar Atores e Casos de Uso Priorizar Casos de Uso

Revisar Requisitos

A finalidade da disciplina Requisitos é:

Estabelecer e manter concordância com os clientes e outros investidores sobre o que o sistema deve fazer.

Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.

Definir os limites do sistema (ou delimitar o sistema).

Fornecer uma base para planejar o conteúdo técnico das iterações.

Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.

Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

Para atingir essas metas, é importante, antes de tudo, entender a definição e o escopo do problema que estamos tentando resolver com este sistema. Investidores são identificados e os Requisitos dos nvestidores são elicidados, reunidos e

analisdos.

Os requisitos de Produtos de Trabalho são então desenvolvidos para descreve completamente o sistema - o que o sistema fará - em um esforço que visualiza todos os investidores, incluindo clientes e usuários potenciais, como importantes fontes de informações (além dos requisitos do sistema).

A disciplina Requisitos está relacionada a outras disciplinas do processo.

A disciplina Análise & Design tem sua entrada principal em Requisitos.

A disciplina Teste valida o sistema quanto (dentre outras coisas) aos requisitos.

A disciplina Configuração& Gerenciamento de Alteração fornece o

mecanismo de controle de alterações dos requisitos. O mecanismo para propor uma alteração ésubmetido a Alterar Requisito , que então érevisado pelo Conselho de Controle de Mudanças.

A disciplina Gerenciamento de Projeto planeja o projeto e cada iteração. Os requisitos de Produtos de Trabalho são entradas importantes para as atividades de planejamento de iteração.

A disciplina Ambiente desenvolve e mantém os artefatos de suporte que são utilizados durante os requisitos.

(7)

Informações Adicionais

Diretrizes Decisões Importantes em Requisitos

Disciplina: Análise e Design

Esta disciplina explica como transformar os Requisitos dos Produtos de Trabalho em Produtos de Trabalho especificando o design do software que o projeto desenvolverá.

Análise e Design Tarefas Análise Arquitetural

Análise de Caso de Uso

Avaliar Viabilidade de Prova de Conceito Arquitetural

Construir Prova de Conceito Arquitetural Criar um Protótipo da Interface do Usuário Descrever a Arquitetura em Tempo de Execução

Descrever a Distribuição Design da Classe

Design de Banco de Dados Design de Caso de Uso Design do Subsistema

Identificar Elementos de Design Identificar Mecanismos de Design

Incorporar Elementos de Design Existentes Projetar a Interface com o Usuário

Revisar a Arquitetura Revisar o Design

As finalidades de Análise e Design são:

Transformar os requisitos em um design do sistema a ser criado.

Desenvolver uma arquitetura sofisticada para o sistema.

Adaptar o design para que corresponda ao ambiente de implementação, projetando-o para fins de desempenho.

A disciplina Análise e Design está relacionada a outras disciplinas, conforme a seguir:

A disciplina Requisitos fornece a entrada principal para Análise e Design.

A disciplina Implementação implementa o design.

A disciplina Testetesta o sistema projetado durante Análise e Design.

A disciplina de Ambiente desenvolve e mantém os artefatos de suporte que são utilizados durante a Análise e Design.

A disciplina Gerenciamento do Projeto planeja o projeto, e cada iteração (descrita em um Plano de Iteração).

(8)

Voltar ao Início da Página Informações Adicionais

Conceitos Arquitetura de Software Componente

Diretrizes Decisões Importantes na Análise e Design Materiais de

Suporte

Arquiteturas de Componentes Modelagem Visual

White papers Desenvolvendo Sistemas em Larga Escala com o Rational Unified Process

Disciplina: Implementação

Esta disciplina explica como desenvolver, organizar, testar a unidade e integrar os componentes implementados de acordo com as especificações do design.

Implementação

Tarefas Analisar Comportamento do Tempo de Execução

Estruturar o Modelo de Implementação Executar Testes de Desenvolvedor Implementar Elementos de Design Implementar Teste do Desenvolvedor Integrar Sistema

Integrar Subsistema

Planejar Integração de Sistema Planejar Integração de Subsistema Revisar o Código

A finalidade da implementação é:

definir a organização do código em termos de subsistemas de implementação organizados em camadas

implementar os elementos de design em termos de elementos de implementação (arquivos de origem, executáveis e outros) testar os componentes desenvolvidos como unidades

integrar os resultados produzidos por implementadores individuais (ou equipes) ao sistema executável

A disciplina Implementação limita o seu escopo a como classes individuais devem ser testadas em unidade. O teste do sistema e o teste de integração são descritos

(9)

na disciplina Teste.

A implementação está relacionada com outras disciplinas:

A disciplina Requisitosdescreve como e, um modelo de caso de uso, capturar requisitos aos quais a implementação deve atender.

A disciplina Análise do & Design descreve como desenvolver um modelo de design. O modelo de design representa o propósito da implementação, e é a entrada principal para a disciplina Implementação.

A disciplina Testedescreve como realizar o teste de integração de cada construção durante a integração do sistema. Descreve também como testar o sistema para verificar se todos os requisitos foram atendidos e como os defeitos são detectados e enviados.

A disciplina Ambientedescreve como desenvolver e manter os artefatos de suporte que são utilizados durante a implementação, como, por exemplo, a descrição do processo, as diretrizes de design e as diretrizes de

programação.

A disciplina Implementaçãodescreve como utilizar o modelo de implementação para produzir e liberar o código para o cliente final.

A disciplina Gerenciamento de Projetodescreve como planejar melhor o projeto. Aspectos importantes do processo de planejamento são o plano de iteração, o gerenciamento de mudanças e os sistemas de controle de defeitos.

Disciplina: Teste

Essa disciplina fornece orientação sobre como avaliar a qualidade do produto.

Fluxos de Trabalho de

Referência Teste

Tarefas Avaliar e Defender Qualidade Definir Abordagem do Teste Determinar Resultados do Teste Estruturar a Implementação de Testes Executar o Conjunto de Testes

Identificar Idéias de Teste

Implementar Conjunto de Testes

A disciplina de Teste age como um fornecedor de serviços para as outras disciplinas de diversas maneiras. Os testes são direcionados principalmente na avaliação da Qualidade do Produto, que é realizada através destas práticas principais:

Localizar e documentar defeitos na qualidade do software.

Sugestões sobre a qualidade do software.

Validar e provar as suposições feitas nas especificações de projeto e requisitos através de demonstração concreta.

Validar se o software funciona conforme o projeto.

(10)

Validar se os requisitos são implementados adequadamente.

Há uma diferença interessante entre a disciplina Teste e as outras do RUP - em essência, a disciplina Teste possui as tarefas de localizar e expor fraquezas no software. É interessante, porque, para obter o maior benefício, é necessário uma filosofia geral diferente da que é utilizada nas disciplinas Requisitos, Análise e Projeto e Implementação. Uma diferença sutil é a de que estas três disciplinas são orientadas para a compleção, sendo que a disciplina Teste é orientada para a incompleção.

Um bom esforço de teste é feito por questões como:

Como este software pode travar?

Em quais situações possíveis este software pode falhar em funcionar como previsto?

A disciplina Teste desafia as suposições, riscos e incertezas inerentes no trabalho das outras disciplinas e trata das preocupações utilizando demonstrações concretas e avaliação imparcial. É desejável evitar dois extremos em potencial:

uma abordagem que não desafia adequada ou efetivamente o software e expões seus problemas e fraquezas inerentes

uma abordagem que é inadequadamente negativa ou destrutiva - se adotar tal abordagem negativa, você poderá considerar impossível de considerar que o software tenha qualidade aceitável e pode alienar o esforço de Teste das outras disciplinas

As informações apresentadas em diversas pesquisas e artigos demonstram que o teste de software responde por 30 a 50 por cento dos custos totais do

desenvolvimento de software. É, portanto, surpreendente notar que a maioria das pessoas acredita que os softwares de computador não são bem testados antes da distribuição. Esta contradição tem sua raiz em alguns problemas-chave.

Testar softwares é muito difícil. Como se quantifica as maneiras diferentes nas quais um determinado programa pode se comportar?

Geralmente, os testes são feitos sem uma metodologia clara, criando

resultados que variam de um projeto para outro e de uma organização para outra. O êxito é, principalmente, um fator da qualidade e habilidades dos indivíduos.

As ferramentas de produtividade são utilizadas insuficientemente. o que torna os aspectos cansativos dos testes intratáveis. Além da falta da execução de testes automatizados, diversos esforços de teste são

conduzidos sem ferramentas que permitem gerenciar efetivamente Dados de Teste e Resultados de Teste extensivos. A flexibilidade de utilização e complexidade do software fazem de um teste completo um objetivo impossível. Utilizar uma metodologia bem concebida e ferramentas de última geração pode melhorar a produtividade e eficácia dos testes de software.

Software de alta qualidade é essencial para o sucesso de sistemas de segurança crítica - como de controle de tráfego aéreo, guia de mísseis ou sistemas de

distribuição médica - nos quais uma falha pode afetar pessoas. O estado crítico de um sistema MIS típico pode não ser tão óbvio de imediato, mas é provável que o impacto de um defeito pode fazer com que o negócio que utiliza o software tenha gastos consideráveis em receita perdida e possíveis custos legais. Nesta era da informação, com demanda crescente pela oferta de serviços distribuídos

(11)

eletronicamente pela Internet, diversos sistemas MIS agora são considerados missão crítica; ou seja, as empresas não podem executar suas funções e têm prejuízos massivos quando há a ocorrência de falhas.

Uma abordagem contínua à qualidade, iniciada no início do ciclo de vida do software pode diminuir os custos de concluir e manter seu software

significativamente. Isso reduz imensamente o risco associado com a implementação de softwares de baixa qualidade.

Relação com Outras Disciplinas

A disciplina Teste está relacionada com outras disciplinas, da seguinte forma:

A disciplina Requisitos, captura os requisitos para o software, que é uma das entradas principais para identificar quais testes devem ser desempenhados.

A disciplina Análise e Projeto determina o projeto adequado para o software, que é outra entrada importante para identificar quais testes devem ser desempenhados.

A disciplina Implementação produz builds do software que são validadas pela disciplina Teste. Dentro de uma iteração, múltiplos builds serão testados - gerenlmente um por ciclo de teste.

A disciplina Implementação fornece o software completo ao usuário final.

Enquanto o software é validado pela disciplina Teste antes disso ocorrer, testes beta e teste de aceitação geralmente são conduzidos como parte da Implementação.

A disciplina Ambiente desenvolve e mantém artefatos de suporte que são utilizados durante o Teste, como as Diretrizes de Teste e Ambiente de Teste.

A disciplina Gerenciamento de Projeto planeja o projeto e o trabalho necessário em cada iteração. Descrito em um Plano de Iteração, este artefato é uma entrada importante, utilizada quando você define a missão de avaliação correta para o esforço de teste.

A disciplina Gerenciamento de Mudança e Configuração controla as

mudanças dentro da equipe de projeto. O esforço de teste verifica se cada mudança foi concluída adequadamente.

Disciplina: Configuração e Gerenciamento de Mudanças Esta disciplina explica como controlar e sincronizar a evolução do

conjunto de Produtos de Trabalho que compõem o sistema de software.

Fluxos de Trabalho de

Referência Gerenciamento de Configuração e Mudanças Tarefas Configurar Ambiente do Gerenciamento de

Configuração (CM)

Confirmar CR Duplicado ou Rejeitado Enviar Controle de Mudanças

Revisar Controle de Mudanças

Um Sistema CM é essencial para controlar os vários Produtos de Trabalho

(12)

produzidos por muitas pessoas que trabalham em um projeto em comum. O controle ajuda a evitar confusões dispendiosas, e assegura que os Produtos de Trabalho resultantes não entrem em conflito devido a alguns dos seguintes tipos de problemas:

Atualização simultânea Notificação Limitada Múltiplas Versões

Atualização Simultânea

Quando dois ou mais membros da equipe trabalham separadamente no mesmo produto de trabalho, o último membro a fazer mudanças desfaz o trabalho realizado pelo anterior. O problema básico é que, se um sistema não permite a atualização simultânea, isso leva a mudanças em série e diminui o ritmo do

processo de desenvolvimento. Entretanto, com a atualização simultânea, o desafio é detectar se ocorreram atualizações simultaneamente e resolver quaisquer

problemas de integração quando essas mudanças forem incorporadas.

Notificação Limitada

Quando um problema é corrigido nos Produtos de Trabalho compartilhados por vários desenvolvedores, e alguns deles não são notificados da alteração.

Múltiplas Versões

A maioria dos programas de grande porte é desenvolvida em liberações evolutivas.

Uma liberação pode estar sendo utilizada pelo cliente, enquanto outra está em teste e uma terceira ainda está em desenvolvimento. Se forem encontrados problemas em qualquer uma das versões, as correções deverão ser propagadas entre elas. Isso pode levar a confusões, que acarretam correções dispendiosas e retrabalho, a menos que as mudanças sejam cuidadosamente controladas e monitoradas.

Um Sistema de CM é útil para gerenciar diversas variantes de sistemas de software em desenvolvimento, controlando as versões que são utilizadas em determinados builds do software, compilando construções de programas individuais ou de

liberações inteiras de acordo com especificações de versão definidas pelo usuário e impondo políticas de desenvolvimento específicas do site.

Alguns dos benefícios diretos obtidos pelo uso de um Sistema de CM incluem:

suporta métodos de desenvolvimento mantém a integridade do produto

assegura integralidade e correção do produto configurado.

fornece um ambiente estável dentro do qual desenvolver o produto.

restringe as alterações nos Produtos de Trabalho de acordo com as políticas do projeto

fornece uma auditoria acompanhando o porque, quando e por quem foi feita alteração nos Produtos de Trabalho.

Além disso, um Sistema de CM armazena dados detalhados de 'contabilidade' sobre o próprio processo de desenvolvimento: quem criou uma versão específica (e quando e por que), quais versões de origens foram utilizadas em uma determinada

(13)

construção, além de outras informações relevantes.

O Sistema de CM de uma organização é utilizado durante todo o ciclo de vida do produto, desde a iniciação até a implementação. Como o repositório de ativos de uma organização, o sistema de CM contém as versões atuais e históricas dos arquivos de origem dos artefatos de requisitos, de design e de implementação que definem uma determinada versão de um sistema ou de um componente do sistema A estrutura de diretórios do produto representada no sistema CM, contém todos os artefatos necessários para implementar o produto. Como tal, a disciplina

Configuração & Gerenciamento de Alteração (CCM) está relacionada a todas as outras disciplinas do processo, uma vez que ela serve como um repositório para os conjuntos resultantes de produtos de trabalho. Incluem:

Domínio: Requisitos, Domínio: Análise e Design, Domínio: Implementação, Domínio: Teste,

Domínio: Implementação,

Domínio: Configuração & gerenciamento de alteração , Domínio: Gerenciamento do Projeto ,

Domínio: Ambiente.

Artefato: Controle de Mudanças

Esses artefatos são utilizados para documentar e controlar uma alteração no produto. Isso fornece um registro de decisões e, com um processo de avaliação apropriado, assegura que o impacto de alteração do pedido seja considerado.

Domínio: Configuração e Gerenciamento de Mudanças Tipos de Produto de Trabalho: Dados do Projeto

Expandir Todas as Seções Reduzir Todas as Seções Objetivo

Para formular e controlar Alterações e Defeitos

Voltar ao Início da Página Relacionamentos

Funções Responsável:

Gerenciador de Controle de Mudanças

Modificado Por:

Engenheiro de Processo Gerenciador de Controle de Mudanças

Todas as Funções

Tarefas Entrada para:

Confirmar CR Duplicado ou Rejeitado

Saída de:

Confirmar CR Duplicado ou Rejeitado

Enviar Controle de Mudanças Iniciar Processo de

Desenvolvimento

(14)

Identificar Pedidos dos Envolvidos

Planejar e Designar Trabalho

Revisar Requisitos

Voltar ao Início da Página Descrição

Breve Resumo

Formulário de Amostra do Controle de Mudanças 1. Identificação

Projeto:

Número do Controle de Mudanças:

Tipo de Controle de Mudanças: (Problema ou Melhoria) Cargo:

Data de Envio:

Originador:

Prioridade do Controle de Mudanças:

2. Problema Atual

Descrição do problema atual:

Falha Crítica:

Dano:

Melhoria:

Novo Requisito:

Condições sob as quais o problema foi observado:

Ambiente Atual: Hardware

Compilador do Sistema Operacional:

Origem do problema atual:

Impacto do problema atual no Custo ou na Economia:

3. Mudança Proposta (Originador) Descrição da mudança proposta:

Custo estimado para implementar a mudança proposta:

4. Mudança Proposta (Mudar Equipe de Revisão) Ação:

Aprovada:

Desaprovada:

Adiada:

Descrição da mudança proposta:

Itens de Configuração Afetados:

Categoria:

Correção de Erros:

Melhoria:

Novo Recurso:

Outros:

(15)

5. Resolução

Custo estimado para implementar a mudança proposta:

Implementador:

Tempo real para implementar a mudança:

Análise:

Implementação:

Teste:

Documentação:

Número de Linhas de Código Afetadas:

6. Avaliação

Métodos de Teste Inspeção

Análise

Demonstração Teste

Plataformas de Teste Casos de Teste

7. Mudar Disposição da Equipe de Revisão Mudanças Aprovadas e Aceitas Descrição

Principal A necessidade de alteração é inerente no desenvolvimento de um sistema de software por ele desenvolver-se durante sua criação inicial e por ser utilizado e mantido subseqüentemente na operação de rotina em um ambiente ativo. Os Controles de Mudanças fornecem um registro de decisões e, com o processo de avaliação apropriado, garantem que os impactos das mudanças sejam considerados.

Controle de Mudanças também são conhecidos por vários nomes, como CRs, defeitos, erros, incidentes, pedidos de aprimoramento. A captura e o gerenciamento apropriados desses pedidos asseguram que as mudanças em um sistema sejam feitas de maneira controlada para que seu efeito no sistema possa ser previsto. Alguns tipos de

importação de Controle de Mudanças incluem:

Pedidos de Aprimoramento são utilizados por vários investidores para solicitar recursos futuros que desejarem incluir no produto. Esses são um tipo de Pedido do Envolvido que captura e articula uma

compreensão das necessidades dos investidores.

Defeitos são relatórios de anomalias ou falhas em um produto de trabalho entregue. Alguns exemplos incluem omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida ou sintomas de erros (falhas) que precisam ser isolados e corrigidos no software.

Também é possível que estejam incluídas variações do que se pode esperar razoavelmente do comportamento do software (como problemas de uso).

A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução e o acompanhamento. As

(16)

pessoas a seguir utilizam os CRs:

Conjunto de Funções: Analistas utilizam os CRs para definir mudanças significativas para requisitos de alto nível e para determinar os requisitos especialmente dos CRs identificados como Pedidos de Aprimoramento.

Conjunto de Funções: Gerenciadores utilizam os CRs para gerenciar e controlar a designação de trabalho.

Conjunto de Funções: Testadores utilizam os CRs para

descrever falhas (defeitos), omissões e problemas de qualidade localizados durante o teste de software.

Conjunto de Funções: Desenvolvedores utiliza os CRs com defeitos para analisar as falhas e localizar os erros ou as causas subjacentes da falha com o fim de resolver o CR.

Função: Analista de Teste utiliza os CRs para planejar os testes exigidos para verificar os CRs resolvidos e para avaliar o

realização do teste, analisando conjuntos de defeitos para medir as tendências na qualidade do software e no processo de

engenharia do software.

Domínio: Gerenciamento de Projeto

Este Domínio captura os Produtos de Trabalho associados com o projeto, planejamento de processo e execução.

Produtos de Trabalho Avaliação de Iteração Avaliação de Status Caso de Negócio Lista de Riscos Ordem de Trabalho

Plano de Desenvolvimento de Software Plano de Iteração

Registro de Revisão