Rational Unified Process – RUP
1.
Princípios Básicos
Um grande problema nos projetos atuais é o grande dinamismo e
complexidade dos negócios nos dias de hoje. Cada vez mais os sistemas são
complexos e precisam estar prontos em menos tempo. Mais do que isso, as
necessidades mudam ao longo do tempo e a especificação de um sistema
provavelmente será alterada durante seu desenvolvimento. Além disso, temos
tecnologias novas (software e hardware) surgindo a cada dia. Algumas
funcionam bem. Outras não. Visando atacar estes problemas, o RUP adota as
seguintes premissas básicas:
•
Uso de iterações para evitar o impacto de mudanças no projeto,
•Gerenciamento de mudanças e
•
Abordagens dos pontos de maior risco o mais cedo possível.
2.
O processo
O Processo Unificado foi incorporado pela Rational, que criou um produto,
comercialmente chamado de RUP, Rational Unified Process. O RUP prevê ciclo
iterativo e incremental para organização do processo de desenvolvimento
como forma de minimizar:
· Falta de sincronia entre necessidades do usuário e de negócio;
· Dificuldade em manter o sistema;
· Mudança de requisitos;
· Falta de qualidade do sistema;
· Esforço desordenado do time de desenvolvimento.
O RUP possui quatro fases
1.
Inception (Concepção)
Atividades:
Definir o escopo do projeto,
os atores que interagem com o sistema, identificação dos casos de uso.
Produtos:
É definido um plano de negócios, que inclui critérios de sucesso, avaliação de risco, estimativa de recursos necessários ao desenvolvimento do projeto
plano de fases indicando as datas dos principais pontos de controle (major milestones).
Decisão:
Decidir se prossegue o desenvolvimento
Elaboration (Elaboração)
Atividades:
compreensão dos requisitos do sistema definição de uma arquitetura base
detalhamento de maior parte dos casos de uso. Produtos:
um protótipo de arquitetura executável é construído em uma ou mais iterações – dependendo do escopo, tamanho e risco do projeto.
Descrição da arquitetura de software
Lista de Riscos e Plano de Negócios revisados. Decisão:
Decidir se prossegue com a construção, mediante o escopo apresentado, seleção da arquitetura, solução para os riscos apresentados.
Construction (Construção)
Atividades:produto completo é desenvolvido de forma iterativa e incremental, até gerar uma versão beta
requisitos remanescentes e os critérios de aceitação Produto:
implementação e teste de software completo
Produto de Software Integrado as plataformas adequadas; Manuais de Usuário;
Descrição da Versão Corrente.
Transition (Implantação)
Atividades:
Implantação do sistema para o usuário final treinamento, instalação e suporte.
correção de alguns problemas
Cada fase é subdividida em iterações. A cada iteração, um conjunto de
atividades deverão ser realizadas (workflow):
•
Business Modeling (Modelagem de Negócio)
A intenção é melhorar o entendimento do negócio através do desenvolvimento de um modelo de negócios. Os documentos gerados são use cases de negócio e modelo de objetos de negócio.
•
Requirements (Requisitos)
Possibilita um melhor entendimento dos requisitos do sistema partindo de um acordo com o cliente e com objetivo de oferecer uma orientação aos desenvolvedores. É produzido um modelo de caso de uso detalhado e um protótipo do sistema.
•
Analysis and Design (Análise e Projeto)
Os requisitos capturados na disciplina anterior são transformados em design. Modelos de analise e design são gerados.
•
Implementation (Implementação)
Nesta fase, o design é transformado em código. A estratégia é desenvolver o sistema em camadas, particionando em subsistemas. O resultado final é componente testado que faz parte do produto final.
•
Test (Teste)
Elaboração de testes e verificação se todos os requisitos foram cumpridos. Os documentos gerados são os modelos e casos de testes.
•
Deployment (Utilização)
Torna o produto disponível para o usuário final. Responsável pelo empacotamento do produto, instalação, treinamento ao usuário e distribuição do produto.
Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver uma mudança neste período para as funções em questão.
Conteúdo do RUP
O que é o RUP afinal? Sabemos neste ponto que é uma metodologia completa e vimos sua estrutura básica. Porém o que ele oferece?
O RUP, além de uma metodologia, é um produto comercializado pela Rational, que é uma grande documentação baseada em hipertexto (HTML). Do conteúdo deste material, destaco os seguintes assuntos:
Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos. Cada tarefa, subproduto e papel é descrito em detalhe. Este modelo pode ser seguido à risca ou adaptado conforme sua necessidade específica.
Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.
Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário. Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30. Exemplos de papéis são: analista de sistemas, analista de negócio, etc.
Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artifacts) gerados ao longo do projeto. Estes documentos são descritos em detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários das ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a usar ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.
Como Adotar
Com base nestes recursos a adoção do RUP pode ser feita de mais de uma maneira. Um extremo seria usar o RUP à risca, ou seja, aplicar todos os métodos e processos exatamente como são propostos. A vantagem desta abordagem é que nada deve ser alterado, pois o RUP é bem completo e detalhado. Porém existe um preço a ser pago, pois o RUP na íntegra é complexo. Esta abordagem implicaria em treinamentos, projetos piloto, etc. Propostas de projetos de adoção do RUP são descritos no próprio produto.
O extremo oposto seria adotar outro modelo de processo mais simples ou conhecido (o atual, se existir) e utilizar o material do RUP como fonte de referência complementar para assuntos não abordados em outro modelo como, por exemplo, os modelos de documentos.
A primeira abordagem é interessante para empresas que precisam de uma grande formalização do processo de desenvolvimento de software e cujo método atual seja totalmente inadequado ou inexistente. A segunda abordagem seria interessante para quem já tem alguma metodologia que considera adequada, mas que tem deficiência em alguma área como, por exemplo, suporte a UML. Soluções intermediárias também são possíveis.
3.
Glossário
Artefato
documento
Iteração
repetição
Pontos de controle (milestones)
Os pontos de controle são usados para avaliar e identificar possíveis falhas no
desenvolvimento de software. São divididos em dois tipos: major milestone e minor milestone.
RUP
é um framework de componentes de processos, métodos e técnicas que podem ser aplicados a qualquer projeto de software específico. Devido a sua grande abrangência, é esperado que sejam feitas adaptações, seja em relação a natureza do projeto ou da organização em que está sendo utilizado, para que seja melhor aproveitado.
Workflow
Apresentação passo a passo das tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos
Tarefas
Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.
