Rational Unified Process
Origem: Wikipédia, a enciclopédia livre.
| Processo de Desenvolvimento de Software |
|---|
| Este artigo é parte da série Processo de desenvolvimento de software |
| Atividade e Passos |
| Requirimentos | Arquitetura | Especificação | Implementação | Teste | Implantação | Manutenção |
| Modelos |
| Ágil | Cleanroom | Interativo | RAD | RUP | Espiral | Cascata | XP | Scrum |
| Disciplinas de Apoio |
| Gerenciamento de configuração | Documentação | Gerenciamento de Projeto |
O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.
O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.
É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.
O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela Rational através de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Metodos Ágeis (leves) como a Programação Extrema, Scrum, FDD e outros.
Índice |
[editar] Linhas mestras
O RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da equipe de um ciclo de produção: parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os programadores a manterem-se concentrados no projeto.
[editar] Gestão de requisitos
Uma documentação apropriada é essencial para qualquer grande projeto; note-se que o RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.
[editar] Uso de arquitetura baseada em componentes
A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.
Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objectos).
[editar] Uso de software de modelos visuais
Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.
A línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.
[editar] Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento. O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.
[editar] Gestão e Controle de Mudanças do Software
Em todos os projectos de software a mudança é inevitável. O RUP define métodos para controlar e monitorizar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisiveis, o controle de mudanças é essencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
[editar] Fases
Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projecto. As fases indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projecto, o RUP divide o projecto em quatro fases diferentes:
- Concepção: ênfase no escopo do sistema
- Elaboração: ênfase na arquitetura
- Construção: ênfase no desenvolvimento
- Transição: ênfase na implantação
O RUP também se baseia nos 4 P's:
- Pessoas
- Projeto
- Produto
- Processo
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 proximas fases e documentam o projeto. Além de permitir melhor acompanhamento.
[editar] A Fase de concepção
A fase de concepção contém os workflows necessários que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura, e o planejamento do projeto [... ] se as partes interessadas tiverem bons conhecimentos, pouca análise será requerida então. Se não tiverem o conhecimento necessário, mais análise será requerida.
Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem definidas quanto a sua quantidade e objetivos.
[editar] Princípios e melhores praticas
RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas, por exemplo:
- Desenvolvimento de software interativo
- Gerenciamento de requisito
- Uso de arquitetura baseada em componente
- Modelagem visual de software
- Verificação da qualidade software
- Controle alteração de software
[editar] Desenvolvimento de software iterativo
Dado o tempo gasto para desenvolver um software grande e sofisticado, não é possível definir o problema e construir o software em um único passo. Os requerimentos irão freqüentemente mudar no decorrer do desenvolvimento do projeto, devido a restrições de arquitetura, necessidades do usuário ou a uma maior compreensão do problema original. Iterações permitem ao projeto ser constantemente refinado, além de assinalarem itens de alto risco do projeto como as tarefas de maior prioridade. De forma ideal, ao termino de cada iteração haverá uma versão executável, o que ajuda a reduzir o risco de configuração do projeto, permitindo maior retorno do usuário e ajudando ao desenvolvedor manter-se focado.
O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:
- Integração é feita passo a passo durante o processo de desenvolvimento, limitando-se cada passo a poucos elementos.
- Integração é menos complexa, reduzindo seu custo e aumentado sua eficiência.
- Partes separadas de projeto e/ou implementação podem ser facilmente identificadas para posterior reuso.
- Mudanças de requerimento são registradas e podem ser acomodadas.
- Os riscos são abordados no inicio do desenvolvimento e cada iteração permite a verificação de riscos já percebidos bem como a identificação de novos.
- Arquitetura de software é melhorada através de um escrutino repetitivo.
Usando iterações, um projeto irá ter um plano geral, como também múltiplos planos de iteração. O envolvimento dos stakeholders é freqüentemente encorajado a cada entrega. Desta maneira, as entregas servem como uma forma de se obter o comprometimento dos envolvidos, promovendo também uma constante comparação contra os requerimentos e a prontidão da organização para as pendências que surgem.
[editar] Gerenciamento de requisitos
O Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades do usuário final pela identificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto trás como benefícios:
- A correcção dos requerimentos gera a correcção do produto, as necessidades dos usuários são encontradas.
- As características necessárias irão ser incluídas, reduzindo o custo de desenvolvimentos posteriores.
RUP sugere que o gerenciamento de requisitos tem que seguir estas actividades:
- Analise o problema é concordar com o problema e criar medições que irão provar seu valor para a organização.
- Entendo as necessidades de seus stakeholders é compartilhar o problema e valores com os stakeholders-chave e levantar quais as necessidades que estão envolvidas na elaboração da idéia.
- Definir o problema é a definição das características das necessidades e esquematizar os casos de uso, actividades que irão facilmente mostrar os requerimentos de alto-nível e esboçar o modelo de uso do sistema.
- Gerenciar o escopo do sistema trata das modificações de escopo que irão ser comunicadas baseadas nos resultados do andamento e seleccionadas na ordem na qual os fluxogramas de casos de uso são atacados.
- Refinar as definições do sistema trata do detalhamento dos fluxogramas de caso de uso com os stakeholders de forma a criar uma especificação de requerimentos de software que pode servir como um contrato entre o seu grupo e o do cliente e poderá guiar as actividades de teste e projecto.
- Gerenciamento das mudanças de requisitos trata de como identificar as chegadas das mudanças de requerimento num projeto que já começou.
[editar] Uso de arquitetura baseada em componentes
Arquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão e promove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto de objetos na programação orientada ao objeto.
Arquitetura de software aumenta de importância quando um sistema se torna maior e mais complexo. RUP foca na produção da arquitetura básica nas primeiras interações. Esta arquitetura então se torna um protótipo nos ciclos iniciais de desenvolvimento. A arquitetura desenvolve-se em cada interação para se tornar a arquitetura final do sistema. RUP também propõem regras de projeto e restrições para capturar regras de arquitetura. Pelo desenvolvimento interativo é possível identificar gradualmente componentes os quais podem então ser desenvolvidos, comprados ou reusados. Estes componentes são freqüentemente construídos em infra-estruturas existentes tais como CORBA e COM, ou JavaEE
[editar] Modelagem visual de software
Abstraindo sua programação do seu código e representando-a usando blocos de construção gráfica constitui-se de uma forma efetiva de obter uma visão geral de uma solução. Usando esta representação, recursos técnicos podem determinar a melhor forma para implementar a dado conjunto de interdependências lógicas. Isto também constrói uma camada intermediária entre o processo de negócio e o código necessário através da tecnologia da informação. Um modelo neste contexto é uma visualização e ao mesmo tempo uma simplificação de um projeto complexo. RUP especifica quais modelos são necessários e porque.
A Linguagem modelagem unificada (UML) pode ser usada para modelagem de Casos de Uso, diagrama de classes e outros objetos. RUP também discute outros formas para construir estes modelos.
[editar] Verificar qualidade de software
Garantia da qualidade é o ponto mais comum de falha nos projetos de software, desde isto é freqüentemente algo que não se pensa previamente e algumas vezes tratado por equipes diferentes, A RUP ajuda no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e prove teste nos processo para medir este nível.
[editar] Controle de alterações no software
Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear e monitoras esta mudanças. RUP também define espaços de trabalho seguros (do inglês secure workspaces), garantindo que um sistema de engenharia de software não será afetado por mudanças em outros sistemas. Este conceito é bem aderente co arquiteturas baseadas em componentes.
