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:
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.
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.
Fases
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 (Atividade:
Revisar Marcos do Ciclo de Vida) 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:
Esforço
|
~5 %
|
20 %
|
65 %
|
10%
|
Programação
|
10 %
|
30 %
|
50 %
|
10%
|
que pode ser descrito graficamente como
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 de 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 geração do software. A menos que produto
"desapareça", ele irá se desenvolver na próxima geraçã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.
Iniciação ou
Concepção: ênfase no escopo do sistema;
Elaboração:
ênfase na arquitetura;
Construção:
ênfase no desenvolvimento;
Transição: ênfase
na implantação.
As fases são compostas
de iterações. As iterações são janelas de tempo; as iterações
possuem prazo definido enquanto as fases são objetivas.
Todas as fases geram
artefatos. Estes serão utilizados nas próximas fases e documentam o
projeto, além de permitir melhor acompanhamento.
Fase de Concepção
A fase de iniciação
ou concepção contém os workflows necessários à concordância
dos stakeholders - as partes interessadas - com os objetivos, a
arquitetura e o planejamento do projeto. Se essas partes interessadas
tiverem bons conhecimentos, pouca análise será requerida. Caso
contrário, será exigida uma análise mais elaborada. Nesta fase, os
requisitos essenciais do sistema são transformados em casos de uso.
O objetivo não é fechá-los em sua totalidade, mas apenas aqueles
necessários à formação de opinião. A etapa é geralmente curta e
serve para definir se é viável continuar com o projeto e definir os
riscos e o custo deste último. Um protótipo pode ser feito para que
o cliente possa aprovar. Como cita o RUP, o ideal é que sejam feitas
iterações, mas estas devem ser bem definidas quanto à sua
quantidade e aos objetivos.
Fase de Elaboração
A
fase de elaboração será apenas para o projeto do sistema,
buscando complementar o levantamento / documentação dos casos de
uso, voltado para a arquitetura do sistema, revisa a modelagem do
negócio para os projetos e inicia a versão do manual do usuário.
Deve-se aceitar: Visão geral do produto (incremento + integração)
está estável?; O plano do projeto é confiável?; Custos são
admissíveis?
Fase de Construção
Na fase de construção,
começa o desenvolvimento físico do software, produção de códigos,
testes alfa. Os testes beta são realizados no início da fase de
Transição.
Deve-se aceitar testes,
e processos de testes estáveis, e se os códigos do sistema
constituem "baseline".
Fase de Transição
Nesta fase ocorre a
entrega ("deployment") do software, é realizado o plano de
implantação e entrega, acompanhamento e qualidade do software.
Produtos (releases, versões) devem ser entregues, e ocorrer a
satisfação do cliente. Nesta fase também é realizada a
capacitação dos usuários.
O Rational Unified
Process propõe uma abordagem iterativa, o que significa que deve-se
testar todo o projeto. Isto permite encontrar defeitos tão cedo
quanto possível, o que reduz radicalmente o custo de reparar o
defeito. Os testes são realizados ao longo de quatro dimensões da
qualidade:confiabilidade, funcionalidade, desempenho da aplicação,
e o desempenho do sistema. Para cada uma destas dimensões da
qualidade, o processo descreve como você passar pelo teste do ciclo
de planejamento, projeto, implementação, execução e avaliação.
O objetivo da
implantação é o de produzir com sucesso lançamentos de produtos e
entregar o software para seus usuários finais. Ele cobre uma vasta
gama de atividades, incluindo a produção de releases externos do
software, a embalagem do software e aplicativos de negócios,
distribuição do software, instalação do software e prestação de
ajuda e assistência aos usuários. Embora as atividades de
implantação estejam principalmente centradas em torno da fase de
transição, muitas das atividades devem ser incluídas nas fases
anteriores para se preparar para a implantação, no final da fase de
construção. Os processos ("workflows") de "Implantação
e Ambiente" do RUP contêm menos detalhes do que outros
workflows.
Três
Disciplinas de Apoio/Suporte
Disciplina de
Ambiente
O ambiente enfoca as
atividades necessárias para configurar o processo para um projeto.
Ele descreve as atividades necessárias para desenvolver as
diretrizes de apoio a um projeto. A proposta das atividades de
ambiente é prover à organização de desenvolvimento de software os
processos e as ferramentas que darão suporte à equipe de
desenvolvimento. Se os usuários do RUP não entendem que o RUP é um
framework de processo, eles podem percebê-lo como um processo pesado
e caro. No entanto, um conceito-chave dentro do RUP foi que o
processo RUP pode e, muitas vezes, deve ser refinado. Este foi
inicialmente feito manualmente, ou seja, por escrito, um documento de
"caso de desenvolvimento" que especificou o processo
refinado para ser utilizado. Posteriormente, o produto IBM Rational
Method Composer foi criado para ajudar a tornar esta etapa mais
simples, engenheiros de processos e gerentes de projeto poderiam mais
facilmente personalizar o RUP para suas necessidades de projeto.
Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a
versão open-source e leve do RUP, são agora apresentados como
processos distintos, por direito próprio, e atendem a diferentes
tipos e tamanhos de projetos, tendências e tecnologias de
desenvolvimento de software. Historicamente, como o RUP, muitas vezes
é personalizado para cada projeto por um perito do processo RUP, o
sucesso total do projeto pode ser um pouco dependente da capacidade
desta pessoa.
Disciplina de
Configuração e Gerência de Mudança
A disciplina de Gestão
de Mudança em negócios com RUP abrange três gerenciamentos
específicos: de configuração, de solicitações de mudança, e de
status e medição.
Gerenciamento de
configuração: A gestão de configuração é responsável pela
estruturação sistemática dos produtos. Artefatos, como documentos
e modelos, precisam estar sob controle de versão e essas alterações
devem ser visíveis. Ele também mantém o controle de dependências
entre artefatos para que todos os artigos relacionados sejam
atualizados quando são feitas alterações
Gerenciamento de
solicitações de mudança: Durante o processo de desenvolvimento de
sistemas com muitos artefatos existem diversas versões. O CRM mantém
o controle das propostas de mudança
Gerenciamento de
status e medição: Os pedidos de mudança têm os estados: novo,
conectado, aprovado, cedido e completo. A solicitação de mudança
também tem atributos como a causa raiz, ou a natureza (como o
defeito e valorização), prioridade, etc. Esses estados e atributos
são armazenados no banco de dados para produzir relatórios úteis
sobre o andamento do projeto. A Rational também tem um produto para
manter a solicitações de mudança chamado ClearQuest. Esta
atividade têm procedimentos a serem seguidos
Disciplina de
Gerência de Projeto
O planejamento de
projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou
planos de Fase que descreve todo o projeto, e uma série de alta
granularidade ou planos de Iteração que descrevem os passos
iterativos. Esta disciplina concentra-se principalmente sobre os
aspectos importantes de um processo de desenvolvimento iterativo:
Gestão de riscos; Planejamento um projeto iterativo através do
ciclo de vida e para uma iteração particular; E o processo de
acompanhamento de um projeto iterativo, métricas. No entanto, esta
disciplina do RUP não tenta cobrir todos os aspectos do
gerenciamento de projetos.
http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process
Nenhum comentário:
Postar um comentário