Rational Unified Process: Visão Geral

O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software.  Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.  Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.

A figura acima mostra a arquitetura geral do RUP.

O RUP tem duas dimensões:

- O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve

- O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza.

A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.

A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo (consulte Conceitos-chave)

O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais tempo com implementação.

Rational Unified Process: Introdução

O processo unificado consiste da repetição de uma série de ciclos durante a vida de um sistema, como mostrado a seguir. Cada ciclo é concluído com uma versão do produto pronta para distribuição. Essa versão é um conjunto relativamente completo e consistente de artefatos, possivelmente incluindo manuais e um módulo executável do sistema, que podem ser distribuídos para usuários internos ou externos.

Modelo de Ciclo de Vida Proposto pelo RUP

Cada ciclo consiste de quatro fases: Iniciação, Elaboração, Construção e Transição. Cada fase é também subdividida em iterações, como discutido anteriormente, vide figura a seguir.

Um ciclo com suas fases e iterações

Rational Unified Process: Fases

As fases e os marcos de um projeto

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em

cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Fases de Planejamento

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio tamanho deve prever a seguinte distribuição de esforço e programação:

Iniciação Elaboração Construção TransiçãoEsforço ~5 % 20 % 65 % 10%

Programação

10 % 30 % 50 % 10%

que pode ser descrito graficamente da seguinte forma:

Para um ciclo de evolução, as fases de Iniciação e de elaboração seriam bem menores. Ferramentas que automatizam parte do esforço de Construção podem amenizar isso, tornando a fase Construção muito menor do que as fases de Iniciação e de Elaboração juntas.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma versão do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima versão, repetindo a mesma seqüência de fases de Iniciação, Elaboração, Construção e Transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante. Normalmente, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas por ciclos de desenvolvimento anteriores.   São exceções a essa regra os ciclos de evolução em que ocorre uma redefinição significativa do produto ou da arquitetura.

Fase: Iniciação (Inception)

Objetivos

A meta dominante da fase Iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase Iniciação tem muita importância principalmente para os esforços dos novos desenvolvimentos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias em um sistema existente, a fase Iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo.

Os objetivos principais da fase Iniciação incluem:

Estabelecer o escopo do projeto do software 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 e o que direcionará 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 todo o projeto (e estimativas detalhadas para a fase Elaboração, imediatamente a seguir).

Estimar riscos em potencial (as origens de imprevistos) Preparar o ambiente de suporte para o projeto.

Atividades básicas

Formular o escopo do projeto. Isso envolve capturar o contexto, bem como os requisitos e as restrições mais importantes, para que seja possível depreender critérios de aceitação para o produto final.

Planejar e preparar um caso de negócio. Avaliar alternativas para o gerenciamento de riscos, a organização da equipe, o plano do projeto e as mudanças de custo/programação/lucros.

Sintetizar uma possível arquitetura, avaliando as mudanças no design e em fazer/comprar/reutilizar, para que seja possível estimar custo, programação e recursos. O objetivo aqui é demonstrar a possibilidade de execução através de alguma forma de prova de conceito. Isso pode ter a forma de um modelo que simula o que é exigido, ou de um protótipo inicial que explora as áreas consideradas de alto risco. O esforço do protótipo durante a Iniciação deve se limitar a ganhar confiança na possibilidade de uma solução - a solução será executada durante a elaboração e a construção.

Preparar o ambiente para o projeto, avaliando o projeto e a organização, selecionando ferramentas e decidindo quais partes do processo devem ser melhoradas.

Marco: Objetivos do Ciclo de Vida (Lifecycle Objectives Milestone)

No final da fase Iniciação (Inception) está o primeiro marco mais importante do projeto ou Marco dos Objetivos do Ciclo de Vida. Nesse momento, são analisados os objetivos do ciclo de vida do projeto e é decidido sobre prosseguir com o projeto ou cancelá-lo.

Critérios de Avaliação

Consentimento dos envolvidos sobre a definição do escopo e as estimativas de custo/programação.

Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreensão compartilhada desses requisitos.

Consenso de que as estimativas de custo/programação, as prioridades, os riscos e o processo de desenvolvimento são adequados.

Todos os riscos foram identificados e existe uma estratégia de mitigação para cada um.

O projeto poderá ser cancelado ou completamente repensado caso ele não atinja este marco.

Artefatos

Artefatos Básicos Estado no marcoVisão Os requisitos principais, as características-chave e as principais

restrições do projeto foram documentados.Caso de Negócio Definido e aprovado.Lista de Riscos Riscos iniciais do projeto identificados.Plano de Desenvolvimento de Software

Identificação das fases iniciais, duração e objetivo de cada uma. Estimativas de recursos (particularmente o tempo, o pessoal e os custos com ambiente de desenvolvimento) no Plano de Desenvolvimento de Software devem ser consistentes com o Caso de Negócio.

A estimativa de recursos pode abranger o projeto inteiro até a liberação, ou apenas uma estimativa de recursos necessários para a fase Elaboração. As estimativas de recursos para o projeto inteiro devem ser vistas como brutas nesse momento. Essa estimativa é atualizada em cada fase e cada iteração, e se torna mais exata a cada iteração. 

Dependendo das necessidades do projeto, um ou mais artefatos de "Plano" incluído pode ser concluído condicionalmente. Um Plano de Aceitação do Produto inicial deve ser analisado e receber uma baseline. O Plano de Aceitação do Produto é refinado nas iterações subseqüentes à medida que forem descobertos requisitos adicionais.

Além disso, os artefatos de "Guias" incluídos normalmente estão pelo menos na forma de "rascunho".

Plano de Iteração O plano de iteração para a primeira iteração de Elaboração concluído e analisado.

Caso de Desenvolvimento Adaptações e extensões ao Rational Unified Process, documentadas e analisadas. 

Ferramentas Todas as ferramentas para suportar o projeto são selecionadas. São instaladas as ferramentas necessárias para o trabalho na Iniciação.

Glossário Termos importantes definidos; glossário analisado.Modelo de Casos de Uso (Atores, Casos de Uso)

Atores e casos de uso importantes identificados, e fluxos de eventos descritos apenas para os casos de uso mais críticos.

Repositório do Projeto, Solicitação de Mudança

O ambiente de Gerenciamento de Configuração deve estar configurado.

Artefatos Opcionais Estado no marcoDiretrizes de Modelagem de Casos de Uso

Com baseline.

Modelo de Domínio (também conhecido como Modelo de Objeto de Negócio)

Os conceitos-chave usados no sistema, documentados e analisados. Usado como uma extensão do Glossário nos casos em que há relacionamentos específicos entre conceitos de captura essencial.

Templates Específicos do Projeto

Os templates de documentos usados para desenvolver os artefatos de documentos.

Protótipos Uma ou mais provas de conceitos (protótipos), para suportar a Visão e o Caso de Negócio e para tratar riscos específicos.

Fase: Elaboração (Elaboration)

Objetivos

A meta da fase Elaboração é criar uma base para a arquitetura do sistema a fim de fornecer sustentabilidade ao esforço da fase Construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação dos riscos. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

Os objetivos primários 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 base 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 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 base suportará os requisitos do sistema a custo e tempo

justos. Estabelecer um ambiente de suporte.

Para atingir esses objetivos básicos, é também importante configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Atividades básicas

Definir, validar e criar a arquitetura de base com rapidez e eficiência. 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 e bases de referência para a fase Construção. Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento,

incluindo o processo, as ferramentas e o suporte de automatização necessários para dar assistência à equipe de construção.

Refinar a arquitetura e selecionar os 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 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.

Marco: Arquitetura do Ciclo de Vida (Lifecycle Architecture Milestone)

No final na fase Elaboração está o segundo marco mais importante do projeto, o Marco da Arquitetura do Ciclo de Vida. Nesse momento, são examinados os objetivos e o escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos. O marco Arquitetura do Ciclo de Vida estabelece uma base de referência gerenciada para a arquitetura do sistema e permite o escalonamento da equipe do projeto na fase Construção.

Critérios de Avaliação

A Visão e os requisitos do produto são estáveis. A arquitetura é estável. As abordagens principais a serem usadas no teste e na avaliação foram comprovadas. O teste e a avaliação de protótipos executáveis demonstraram que os principais elementos de

risco foram tratados e resolvidos com credibilidade. Os planos de iteração para a fase Construção têm detalhes e fidelidade suficientes para

permitir o avanço do trabalho. Os planos de iteração para a fase Construção são garantidos por estimativas confiáveis. Todos os envolvidos concordam que a visão atual poderá ser atendida se o plano atual for

executado para desenvolver o sistema completo, no contexto da arquitetura atual. A despesa real em oposição à despesa planejada com recursos é aceitável.

O projeto poderá ser cancelado ou completamente repensado caso ele não atinja este marco.

Artefatos

Artefatos Básicos Estado no marco

Protótipos Um ou mais protótipos de arquitetura foram criados para explorar a funcionalidade crítica e os cenários significativos do ponto de vista da arquitetura. Consulte a observação abaixo sobre o papel do protótipo.

Lista de Riscos Atualizada e analisada. Os novos riscos tendem a ser de natureza da arquitetura, relacionados basicamente ao gerenciamento de requisitos não funcionais.

Caso de Desenvolvimento Refinado com base na experiência inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessários para dar assistência à equipe de construção já estará posicionada.

Ferramentas As ferramentas usadas para suportar o trabalho de Elaboração são instaladas.

Documento de Arquitetura de Software

Criado e com baseline, incluindo descrições detalhadas para os casos de uso significativos para a arquitetura (visão de caso de uso), identificação dos mecanismos principais e dos elementos de design (visão lógica), mais a definição da visão de processos e da visão da implantação (do Modelo de Implantação) caso o sistema seja distribuído ou deva lidar com problemas de concorrência.

Modelo de Design (e todos os artefatos constituintes)

Definido e com baseline. Realizações de caso de uso para cenários significativos do ponto de vista da arquitetura foram definidas, e o comportamento necessário foi alocado para os elementos de design apropriados. Os componentes foram identificados, e as decisões de fazer/comprar/reutilizar foram compreendidas para determinar o custo da fase 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.

Modelo de Dados Definido e com baseline. Os elementos de modelo de dados principais (por exemplo, entidades, relacionamentos, tabelas importantes) definidos e analisados.

Modelo de Implementação (e todos os artefatos constituintes, incluindo Componentes)

Estrutura inicial criada e componentes principais identificados e com protótipos.

Visão Refinada, 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.

Plano de Desenvolvimento de Software

Atualizado e expandido para cobrir as fases de Construção e Transição.

Guias, como Guia de Design e Guia de Programação

Os guias usados para suportar o trabalho.

Plano de Iteração Plano de iteração para a fase Construção concluído e analisado.

Modelo de Casos de Uso (Atores,Casos de Uso)

Um modelo de casos de uso (aproximadamente 80% concluído) — todos os casos de uso sendo identificados na pesquisa de modelo de casos de uso, todos os atores sendo identificados e a maioria das descrições de caso de uso (captura de requisitos) sendo desenvolvida.

Especificações Suplementares

Os requisitos suplementares abrangendo os requisitos não funcionais são documentados e analisados.

Conjunto de Testes ("teste de regressão")

Testes implementados e executados para validar a estabilidade do build para cada release executável criado durante a fase Elaboração.

Arquitetura para Automatização de Testes

Uma composição de baseline de vários mecanismos e elementos-chave de software que compõem as características fundamentais do sistema de software de automatização de teste.

Artefatos Opcionais Estado no marco

Caso de Negócio Atualizado se as investigações sobre a arquitetura descobrirem problemas que mudem premissas fundamentais do projeto.

Modelo de Análise Pode ser desenvolvido como um artefato formal; freqüentemente mantido de forma não formal, evoluindo, em vez disso, para uma versão inicial do Modelo de Design.

Materiais de Treinamento Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso.  Poderá ser necessário se o sistema tiver um forte aspecto de interface de usuário.

Templates Específicos do Projeto

Os templates de documentos usados para desenvolver os artefatos de documentos.

O Papel da Criação de Protótipo

O Rational Unified Process dá ao arquiteto de software e ao gerente de projeto a liberdade de construir protótipos de vários tipos (consulte Conceitos: Protótipos) como uma estratégia de redução de riscos. Alguns desses protótipos podem ser puramente exploratórios e serão posteriormente descartados. Contudo, é provável (para sistemas grandes e sem precedentes) que a arquitetura tenha sido construída como uma série de protótipos evolucionários — abrangendo diferentes problemas no decorrer da elaboração — e, no fim da elaboração, terá atingido o ponto máximo em uma base de arquitetura estável e integrada. Não queremos sugerir com isso que o esforço de criação de protótipos durante a elaboração deva resultar em um conjunto de fragmentos de arquitetura que não precisam ser integrados.

Fase: Construção (Construction)

Objetivos

A meta da fase Construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura definida. A fase Construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa

por uma transição de desenvolvimento da propriedade intelectual durante a Iniciação e Elaboração, para o desenvolvimento de produtos que podem ser implantados durante a Construção e Transiçã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 descrever os casos de uso restantes e outros requisitos, incrementar o design, concluir a implementação e testar o software.

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

Atingir certo paralelismo entre o 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.

Atividades Básicas

Gerenciamento de recursos, otimização de controle e processo Desenvolvimento completo dos componentes e teste dos critérios de avaliação definidos Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão

Marco: Capacidade Operacional Inicial (Initial Operational Capability)

No Marco da Capacidade Operacional Inicial, o produto está pronto para ser passado para a Equipe de Transição. Todas as funcionalidades já foram desenvolvidas e todos os alfa-testes (se houver algum) foram concluídos. Além do software, um manual do usuário foi desenvolvido, e existe uma descrição do release atual. O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta.

Critérios de Avaliação

Os critérios de avaliação para a fase Construção envolvem as respostas para estas questões:

Este release do produto é estável e desenvolvido o suficiente para ser implantado na comunidade de usuários?

Todos os envolvidos estão prontos para a transição para a comunidade de usuários? As despesas reais com recursos ainda são aceitáveis se comparadas com as planejadas?

Talvez a transição tenha de ser adiada por um release se o projeto não atingir esse marco.

Artefatos

Artefatos Básicos Estado no marco

"O Sistema" O próprio sistema executável, pronto para começar o teste "beta".

Plano de Implantação Versão inicial desenvolvida, analisada e com baseline. Em projetos menores, isso pode ser embutido no Plano de Desenvolvimento de Software.

Modelo de Implementação (e todos os artefatos constituintes, incluindo Componentes)

Expandido a partir daquele criado durante a fase Elaboração; todos os componentes criados no final da fase Construção.

Conjunto de Testes ("teste de regressão")

Testes implementados e executados para validar a estabilidade do build de cada release executável criado durante a fase Construção.

Materiais de Treinamento Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso, poderá ser necessário se o sistema tiver um forte aspecto de interface de usuário.

Plano de Iteração Plano de iteração para a fase Transição concluído e analisado.

Modelo de Design (e todos os artefatos constituintes)

Atualizado com novos elementos de design identificados durante a conclusão de todos os requisitos.

Caso de Desenvolvimento Refinado com base na experiência inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessários para dar assistência à equipe de transição já estará posicionada.

Ferramentas As ferramentas usadas para dar suporte ao trabalho de Construção são instaladas.

Modelo de Dados Atualizado com todos os elementos necessários para suportar a implementação persistente (por exemplo, tabelas, índices, etc.).

Artefatos Opcionais Estado no marco

Templates Específicos do Projeto

Os templates de documentos usados para desenvolver os artefatos de documentos.

Especificações Suplementares

Atualizadas com novos requisitos (se houver) descobertos durante a fase Construção.

Modelo de Casos de Uso (Atores,Casos de Uso)

Atualizado com novos casos de uso (se houver) descobertos durante a fase Construção.

Fase: Transição (Transition)

Objetivos

O foco da Fase Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase Transição pode atravessar várias iterações e inclui testar o produto em preparação para liberação e pequenos ajustes com base no feedback do usuário. Nesse momento do ciclo de vida, o

feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhados muito antes no ciclo de vida do projeto. 

No fim do ciclo de vida da fase Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

A fase Transição pode ser muito fácil ou muito complexa, dependendo do tipo de produto. Um novo release de um produto de mesa existente pode ser muito simples, ao passo que a substituição do sistema de controle do tráfego aéreo de um país pode ser excessivamente complexa.

As atividades realizadas durante uma iteração na fase Transição dependem da meta. Por exemplo, ao corrigir erros, normalmente bastam a implementação e o teste. Se, no entanto, novas características tiverem de ser adicionadas, a iteração será semelhante a uma fase Construção, exigindo análise, design, etc.

A fase Transição entra quando uma base estiver desenvolvida o suficiente para ser implantada no domínio do usuário final. Isso normalmente requer que algum subconjunto usável do sistema tenha sido concluído com nível de qualidade aceitável e documentação do usuário, de modo que a transição para o usuário forneça resultados positivos para todas as partes. 

Os objetivos principais da fase Transição são:

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 Introdução ao marketing, distribuição e equipe de vendas Engenharia voltada para implantaçã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 bases de implantação tendo como guia 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 “de acordo” dos envolvidos de que as bases de implantação estão completas Obtenção do “de acordo” dos envolvidos de que as bases de implantação são consistentes

com os critérios de avaliação da visão

Atividades básicas

Executar planos de implantaçã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 feedbacks

Disponibilizar o produto para os usuários finais

Marco: Release do Produto (Product Release)

No fim na fase Transição está o quarto marco mais importante do projeto, o Marco Release do Produto. Nesse momento, você avalia se os objetivos foram alcançados, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase Iniciação do próximo ciclo. O Marco Release do Produto é o resultado da conclusão com êxito da Atividade: Revisão da Aceitação do Projeto.

Critérios de Avaliação

Os critérios básicos de avaliação para a fase Transição envolvem as respostas para estas questões:

O usuário está satisfeito? As despesas reais com recursos são aceitáveis se comparadas com as planejadas?

No Marco Release do Produto, o produto está em produção e o ciclo de manutenção posterior ao release se inicia. Isso pode envolver o início de um novo ciclo de desenvolvimento ou de algum release de manutenção adicional.

Artefatos

Artefatos Básicos Estado no marco

O Build do Produto Concluído de acordo com os requisitos do produto. O produto final deve ser utilizável pelo consumidor.

Notas de Release Concluídas.

Artefatos de Instalação Concluídos.

Material de Treinamento Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.

Material de Suporte para o Usuário Final

Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.

Artefatos Opcionais Estado no marco

Conjunto de Testes ("teste de regressão")

O conjunto de testes desenvolvidos para validar a estabilidade de cada build pode ser fornecido na situação em que o cliente deseja executar um nível básico de teste no local.

Empacotamento Compacto do Produto

No caso de criar um produto compacto, o contratante precisará dos artefatos de empacotamento necessários para ajudar a colocar o produto no varejo.