RUP - Rational Unified Process
Joel De Bortoli - Graduação em Gestão de TI - www.joeldebortoli.com
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.
Conforme [Kroll e Kruchten 2003], podemos ter três definições para o Rational Unified Process (RUP):
O RUP é uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. É descrita em vários livros e artigos. Uma das maiores fontes de informações é o próprio produto IBM RUP , que contém guias detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;
O RUP é um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão;
O RUP é também um produto de processo que oferece uma estrutura de processo customizável para a engenharia de software. O produto IBM RUP suporta a customização e autoria de processos, e uma vasta variedade de processos, ou configuração de processos, podem ser montadas nele. Essas configurações do RUP podem ser criadas para suportar equipes grandes e pequenas, e técnicas de desenvolvimento disciplinadas ou menos formais. O produto IBM RUP contém várias configurações e visões de processos prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros membros da equipe de desenvolvimento em como desenvolver o software. Ele tem sido utilizado por muitas companhias em diferentes setores da indústria.
O RUP utiliza a Linguagem Unificada de Modelagem UML para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG e ter se tornado o padrão empresarial para a modelagem orientada a objetos.
Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e grande porte.
2.1 Os Princípios do RUP
Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e será diferente em cada projeto e organização. Porém, existem alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos:
Atacar os riscos cedo e continuamente;
Certificar-se de entregar algo de valor ao cliente;
Focar no software executável;
Acomodar mudanças cedo;
Liberar um executável da arquitetura cedo;
Construir o sistema com componentes;
Trabalhar junto como um time;
Fazer da qualidade um estilo de vida, não algo para depois.
2.2 Elementos do RUP
O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas.
2.2.1 Papel
Define o comportamento e as responsabilidades de um determinado indivíduo ou grupo de indivíduos trabalhando como uma equipe. Papéis não são indivíduos e nem títulos de trabalho. Um indivíduo pode assumir vários papéis. São exemplos de papéis:
Analista de sistema – O indivíduo que assume este papel coordena a obtenção dos requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;
Projetista – Esse indivíduo define responsabilidades, operações, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;
Projetista de testes – Responsável pelo planejamento, projeto, implantação e avaliação de testes, incluindo a geração de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangência dos testes, resultados e a efetividade.
2.2.2 Atividade
É uma unidade de trabalho que um indivíduo executa quando está exercendo um determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. São exemplos de atividades:
Planejar uma iteração: realizada pelo papel gerente de projeto;
Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
Rever o projeto: realizada pelo papel revisor de projeto;
Executar um teste de performance: realizado pelo papel testador de performance.
2.2.3 Artefato
É um pedaço de informação que é produzido, modificado ou utilizado em um processo. Os artefatos são os produtos de um projeto. São as coisas produzidas durante o desenvolvimento do projeto. Artefatos são utilizados como entradas de atividades e são produzidos como saída. Os artefatos podem ter várias formas:
Um modelo, como um modelo de caso de uso, um modelo de projeto;
Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema;
Um documento, como um caso de negócio, glossário, visão;
Código fonte;
Executáveis.
A enumeração de atividades, papéis e artefatos não constituem um processo. É necessário saber a seqüência do desenvolvimento das atividades para que possam ser produzidos artefatos de valor para o projeto.
2.2.4 Fluxo de Trabalho
É uma seqüência de atividades que são executadas para a produção de um resultado valioso para o projeto. Fluxos de trabalho podem ser representados por diagramas de seqüência, diagramas de colaboração e diagramas de atividades da linguagem UML. O RUP utiliza três tipos de fluxos de trabalho:
Fluxos de trabalho principais, associados com cada disciplina;
Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal;
Planos de iteração, que mostram como a iteração deverá ser executada.
2.2.5 Disciplina
È uma coleção de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separação das atividades em disciplinas torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das atividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte. As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente.
RUP possui duas dimensões:
O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve. Representa o aspecto dinâmico do processo. É expresso em termos de fases, disciplinas e marcos.
O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. Representa o aspecto estático do processo. É descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.
2.3 O Ciclo de Vida de um Projeto RUP
O ciclo de desenvolvimento no RUP possui quatro fases: iniciação, elaboração, construção e transição. Cada uma é concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais.
O ciclo de desenvolvimento termina com uma versão completa do produto de software. As fases definem estados do projeto, que são definidos por riscos que estão sendo mitigados ou questões que precisam ser respondidas.
A fase de iniciação, foca no tratamento de riscos relacionados com o caso de negócio. Deve ser verificado se o projeto é viável e se é financeiramente possível.
Na fase elaboração, o foco deve ser nos riscos técnicos e arquiteturais. O escopo deve ser revisado e os requisitos devem estar mais compreendidos.
Durante a construção, a atenção será voltada para os riscos lógicos, e a maior parte do trabalho será realizada.
Na fase de transição, serão tratados os riscos associados com a logística de distribuição do produto para a base de usuários.
Embora varie muito em empresas e projetos diferentes, um ciclo de desenvolvimento para um projeto de tamanho médio, possui uma distribuição de esforço e programação.
Conforme descrito na documentação do RUP, cada passagem pelas quatro fases gera uma geração do software. A menos que o 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. Esses ciclos subseqüentes são chamados de ciclos de evolução. A cada ciclo, 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, a menos que ocorram mudanças significativas do produto ou da arquitetura, 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
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.
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 (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.
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).
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.
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.
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.
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.
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
10.1 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.
10.2 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.
10.3 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.
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.
10.5 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.
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, garantindo que um sistema de engenharia de software não será afetado por mudanças em outros sistemas. Este conceito é bem aderente com arquiteturas baseadas em componentes.
O RUP é uma metodologia que provê qualidade de software, aumento de produtividade e melhorias na manutenção além de ajudar no controle sobre todas as fases de desenvolvimento do software.
Nenhum comentário:
Postar um comentário