RUP

Você deve ta se perguntando que diabos é isso?
Hmm.. vejamos.. NÃO, NÃO, rup não é uma onomatopéia pra dizer que alguém está com soluço..
RUP significa Rational Unified Process ou Processo Unificado da Rational ( empresa Rational que pertence a IBM, dai agora é IRUP) e é mais um modelo de processo de desenvolvimento de software, ou seja, mais um meio de descrever um conjunto de atividades para transformar os requisitos do usuário em software!
Por que usar o RUP?
Porque ele é legal, oras...
Ele é um modelo mais moderno ( visto que tem gente que desenvolve com o mesmo método de 25 anos atras, não tirando os tiozões neh, mas veja bem.. muita coisa mudou = evoluiu, e a nova geração também tras idéias boas xD )
A comunidade de desenvolvimento já estava precisando de um modelo de processo que:

• Provesse um guia para a ordem das atividades da equipe do processo;
• Direcionasse as tarefas dos desenvolvedores e da equipe como um todo;
• Especificasse quais artefatos que devem ser desenvolvidos;
• Oferecesse critérios para monitoramento e medida dos produtos e atividades de um processo.

E é isso que o RUP é capaz

• Ele é composto de 5 disciplinas que oferecem diretrizes para definição de tarefas e atribuições das responsabilidades em um projeto de software
• É baseado na UML

E por que tudo isso é importante, afinal?

Oras, vejamos alguns dos motivos mais comuns de fracasso de produção de software:

• Gerenciamento informal de requisitos ( é muito comum ficar so no boca a boca e a caba que ninguém faz nada padronizado, cada um faz de um jeito, na hora até entende.. mas e depois quando tem que dar manutenção?);
• Não entendimento das necessidades dos usuários ( não adianta vc achar que entendeu, como diz um prof meu, quando for lidar com o usuário pra saber o que ele realmente quer que o software faça finja-se de burrinho, porque nem sempre o que vc entende logo de cara é o que ele realmente quer, geralmente ele nem sabe direito o que quer, mas quer que resolva os problemas dele!);
• Incapacidade de lidar com as mudanças de requisitos( ao longo do projeto , muitas vezes, o usuário muda de idéia em relação ao que ele julga realmente importante que o software faça e vc tem que estar apto para fazer essas mudanças, se nao o software vai ficar ruim do mesmo jeito);
• Complexidade crescente e excessiva;
• Qualidade ruim;
• Testes insuficientes(muitas vezes os testes sao feitos por quem desenvolve o software, que e quem sabe o caminho certinho que nao da bugs e funciona perfeitamente, e isso eh errado pq quando chega ao cliente ele SEMPRE vai fazer da forma errada!);
• Baixa performace.

CARACTERÍSTICAS DO RUP

• Direcionado a caso de uso : processo de desenvolvimento segue um fluxo através de workflows que derivam dos casos de uso( outro dia eu explico o que é caso de uso);
• Centrado em arquitetura: ajuda o arquiteto a focar nos objetivos ( corretos de preferencia). Nota: os casos de uso e arquitetura devem "caminhar" em paralelo
• *Iterativo e incremental: o trabalho de engenharia é dividido em partes menores (pequenos projetos ou iterações). Cada iteração resulta num incremento no produto.

Vamos explicar melhor ...

Ele funciona mais ou menos assim:

em cada iteração, os desenvolvedores identificam e especificam os casos de uso relevantes, criam um projeto usando a arquitetura escolhida como um guia, implementam o projeto em componentes e verificam se os componentes satisfazem o caso de uso. SE a iteração atingir seu objetivo, passa para a proxima iteração, caso contrario, os desenvolvedores devem revisar suas decisões e o que fizeram e tentam de novo (só que de outra forma é claro, de maneira que de certo).
No desenho abaixo da pra entender um pouco melhor como funciona (se vc conseguir lê-lo, é claro)

Ta, mas pra que tudo isso? Que que eu ganho com essas tais de iterações?

Muito simples, caro leitor...
Com a iteração controlada vc reduz o custo do risco às despesas de um único incremento, e não de um produto pronto( imagina vc passar meses fazendo um projeto pra depois, laaaaaaaaa no final , ele nao da certo? melhor faze um poquinho e testa, outro poquinho e testa... e assim vai)
Reduz o risco de não colocar o produto no mercado no tempo esperado (imagina, vc fez tudo , dai chega na hora de testa vc percebe um erro lá na frente e dai tem que refazer um monte de coisa, quando não tudo)
É mais rápido, porque trabalha com pequenos processos , mais simples e mais focados
As necessidades dos clientes e requerimentos não podem ser definidos logo no começo. São tipicamente refinadas em iterações sucessivas (mesmo porque quando o cliente chega pra vc e diz que quer um software a maioria das vezes ele nem sabe mesmo o que quer, apenas quer pq sabe que irá facilitar a vida dele!)

PRODUTO DE PROJETO DE SOFTWARE DO RUP

• Modelo de caso de uso - com todos os casos de uso e seus relacioamentos com usuário. Define o escopo do sistema;
• Modelo de análise - tem dois propósitos : refinar os casos de uso em mais detalhes e fazer alocação inicial do comportamento do sistema em uma série de objetos que proveem o comportamento;
• Modelo de projeto(design) - define: a)estrutura estática do sistema com subsistemas, classes e interfaces b)casos de uso realizados como colaborações entre subsistemas, classes e interfaces
• Modelo de implementação - inclui componentes ( representando o código fonte) e mapeando as classes para os componentes
• Modelo de implantação ( deployment) - definem os nós fisicos dos computadores e o mapeamento entre os componentes para esses nós
• Modelo de teste - descreve os casos de testes e verifica os casos de uso
• Modelo de banco de dados - consiste dos modelos lógicos e físicos dos dados

A figura abaixo (se conseguir ler) resume mais ou menos o que essas palavras todas disseram ai acima:

CICLO DE VIDA DO RUP

• Repete uma série de ciclos com uma RELEASE.
• Cada ciclo consiste em 4 fases :
• - inseption( iniciação) - chegar a um acordo com os stakeholders;
• - elaboration( elaboração) - especificar a arquitetura;
• - construction ( construção) - implementação;
• - transition ( transição) - transferir o produto para o usuário final ( pode ser apenas um release)
• Nota: cada fase é dividida em iterações.

FASES DE ITERAÇÕES

• Uma fase termina com um marco (milestone), que é definido pela disponibilidade de certos
• artefatos (modelos ou documentos) em um determinado estado;
• Dentro de cada fase, são realizadas iterações e uma iteração é equivalente a um “miniprojeto”;

FASES

• Iniciação - Objetivos: estabelecer o escopo, identificar os casos de uso, esboçar a arquitetura, estimar riscos. Artefatos Principais: documento de escopo, modelo de caso de uso, glossário, proposta, comercial, avaliação de riscos, plano de projeto;
• Elaboração - Objetivos : definir, validar e delinear a arquitetura, delinear a visão, planejar a fase de construção. Artefatos Principais: modelo de caso de uso detalhado, especificação da arquitetura, protótipos, lista de riscos revisada, plano de construção, manual do usuário preliminar.
• Construção - Objetivos: construir o software com objetivo de minimizar custos de desenvolvimento, priorizar qualidade, investir em visões de software úteis. Artefatos Principais: produto de software integrado, manual do usuário, descrição da versão atual
• Transição - Objetivos: validação do sistema pelos usuários, implantação e instalação do produto, treinamento dos usuários, liberação para marketing, distribuição e vendas. Artefatos Principais: produto final, manual do sistema, manual do usuário, relatório de implantação

FOCO DAS ITERAÇÕES EM CADA FASE

• Iniciação: entender os requisitos de modo abrangente e definir o escopo do projeto;
• Elaboração: captura dos requisitos e definição da arquitetura. Pode haver implementação para provas de conceito;
• Construção: implementação do produto operacional;
• Transição: transferência do produto para o cliente e tarefas relacionadas;

DISCIPLINAS DO RUP

• Cada atividade do processo tem como finalidade criar ou atualizar um ou mais artefatos
• O RUP possui 6 processos de engenharia e 3 processos de suporte, também chamados de disciplinas

• Disciplinas de Engenharia:

1. – Modelagem de Negócio: foca no entendimento do negócio ser automatizado pelo software ( Avalia situação do negócio, descreve o negócio atual, explora automação dos identifica processos de de negócio, refina processos de negócio, especifica realizações processos de negócio, refina papéis e responsabilidades, modela domínio );
2. – Requisitos: foca no entendimento dos requisitos do software(Analisa problema, captura as necessidades dos stakeholders, defini o sistema, gerencia o escopo do sistema, refina a definição do sistema, gerencia mudanças de requisitos);
3. – Análise e Design: análise dos requisitos e projeto (design) do software( Define arquitetura candidata, refina arquitetura analisar comportamento, especifica componentes, especificar componentes de tempo-real, especificar banco de dados);
4. – Implementação: codificação dos componentes( Estrutura o Modelo de Implementação, planeja a integração, implementa componentes, integrar subsistemas, integrar sistemas);
5. – Teste: avaliação do sistema em relação aos requisitos ( Planeja teste, especifica teste, implementa teste, executar testes no estágio de teste deintegração, executar testes no estágio de teste de sistema, avalia resultado do teste);
6. – Implantação: entrega do software ( Planeja implantação, desenvolve material de suporte, testa o sistema no ambiente de desenvolvimento, cria versão, versão beta, testa o sistema no ambiente do cliente, empacota o produto, prove acesso ao site de download);

• Disciplinas de Suporte:

1. – Gerenciamento de Projeto ( Planeja controles de configuração e mudanças, prepara ambiente de gerenciamento de mudanças, muda e disponibilizar itens, gerencia baselines e versões, monitorar e reporta status, gerencia pedidos de mudança);
2. – Gerenciamento de Configurações e Mudanças;
3. – Ambiente: preparação do ambiente para desenvolvimento do projeto ( Prepara ambiente para o projeto, prepara ambiente para iteração, prepara diretrizes para iteração, suporta ambiente para iteração).