RUP Rational Unified Process

1. RUPRational Unified Process Engenharia de Software Trabalho elaborado por: Sérgio Reis, nº 3844 Helder Caçoila, nº 3845 Gonçalo Martins, nº 3945

2. Introdução • Num ambiente de constante aparecimento de novas tecnologias de informação, fabricantes e produtos, continuamos a debater-nos com problemas nos projectos de software, verificando-se por exemplo que grande parte destes projectos sofrem atrasos ou revelam-se mais dispendiosos, ultrapassando os limites inicialmente planeados. • Num contexto de evolução tecnológica onde as ferramentas são mais rápidas e eficientes e onde o hardware está em constante evolução tal situação não seria de esperar. Na maior parte das vezes a causa do problema não é a tecnologia.

3. Introdução(2) • Claro que existem erros e incompatibilidades mas não são estes os factores críticos de sucesso que justificam os atrasos e fracassos. Antes de culpar a tecnologia por um projecto mal sucedido, existem questões importantes a responder: • A funcionalidade do sistema suporta o objectivo proposto inicialmente? • A tecnologia escolhida é a mais adequada para o negócio do cliente? • A Equipa de projecto e o cliente falam a mesma linguagem? • A Equipa de projecto trabalha de forma integrada e sem problemas de comunicação? • Será o processo de desenvolvimento de software flexível à mudança?

4. Introdução(3) • Actualmente é este o dilema dos profissionais na produção e desenvolvimento de projectos de software, com repercussões imediatas na problemática da modelação organizacional. • Fig.1. O RUP mostra como aplicar várias práticas de engenharia de software. Também providencia ensinamentos de como fazer uso de várias ferramentas para automatizar processos de software de engenharia específicos.

5. “Afinal, o que é o RUP?” • O RUP, abreviação de Rational Unified Process é um processo de engenharia de software criado pela Rational Software Corporation. É um método de desenvolvimento de software que contempla técnicas a serem seguidas pelos membros da equipa de desenvolvimento de software com o objectivo de aumentar a sua produtividade.

6. Constituição do RUP • O RUP usa a abordagem da orientação a objectos em sua concepção, e é projectado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em acção. Utiliza técnicas e práticas provadas comercialmente. • Embora seja amplamente mutável, é um processo considerado pesado, sendo preferencialmente aplicável a grandes equipas de desenvolvimento e a grandes projetos. Para a gerência do projecto, o RUP contempla 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 electrónico, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela Rational através dos seus "Rational Suites". • Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Modelos Ágeis (leves) como a Programação Extrema (XP).

7. Linhas Mestras • Gestão de requisitos • Uma documentação apropriada é essencial para qualquer grande projecto; note-se que o RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projecto e requisitos de negócio. • Os casos de uso e os cenários são exemplos de factores dependentes do processo, que têm vindo a ser considerados bastante mais eficazes no reconhecimento de requisitos funcionais.

8. Linhas Mestras (2) • Uso de arquitectura baseada em componentes • A arquitectura 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 relaciona-se com um objecto na programação orientada a objectos. • O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitectura executável nas fases iniciais do projecto, antes de comprometer recursos em larga escala.

9. Linhas Mestras (3) • 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 efectiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indivíduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projecto. • A linguagem de modelação UML tornou-se um padrão industrial para representar projetos e é amplamente utilizada pelo RUP.

10. Linhas Mestras (4) • Verificação da qualidade do software • Não assegurar a qualidade do software é a falha mais comum em todos os projetos de software. Normalmente, pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade por uma equipa diferente da equipa de desenvolvimento. O RUP tenciona dar assistência no controle do planeamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipa de desenvolvimento.

11. Linhas Mestras (5) • Gestão e Controlo 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 afectar aplicações de formas inteiramente imprevisíveis o controlo de mudanças é essencial para o sucesso de um projecto. • O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efectuadas noutro sistema não irão afectar o seu sistema.

12. Fases • Até agora estas linhas mestras são gerais, a serem cumpridas no percorrer do ciclo de vida de um projecto. As fases indicam a ênfase que é dada no projecto 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 arquitectura • Construção: ênfase no desenvolvimento • Transição: ênfase na implantação

13. Concepção • Objectivos • Entender o âmbito geral do projecto e os seus objectivos • Colher informações sobre o que deve ser feito • Decidir sobre a continuidade do projecto

14. Concepção (2) • Actividades Essenciais • Entender o que produzir • Identificar os pontos chave do sistema • Determinar no mínimo uma solução possível • Planear custos, agenda e riscos • Decidir qual processo seguir e quais ferramentas • OBS: Podem (devem) ser feitos em paralelo

15. Elaboração • Objectivos • Desenvolver a arquitectura do sistema, tendo em conta: • Requisitos mais significantes • Avaliação dos riscos

16. Elaboração (2) • Actividades Essenciais • Obter uma compreensão detalhada dos requisitos. • Casos de uso mais detalhados • Protótipos de interface validados pelo utilizador • Glossário • Modelar, implementar, validar e definir as linhas base da arquitectura. • Mais importantes blocos de construção, interfaces, decisões de implementação e reutilização • Descrição da interacção dos blocos nos cenários mais importantes • Implementação e validação da arquitectura. • Faça os casos de teste unitários

17. Elaboração (3) • Actividades Essenciais • Minimizar os riscos essenciais e produzir uma agenda mais precisa e estimativas de custo. • Requisitos detalhados. • A implementação do esqueleto minimiza os problemas mais difíceis. • Os riscos já foram quase todos minimizados. • Nessa fase a potencialidade da equipe e das ferramentas já pode ser avaliada • Melhorar o Development Case e a implantação • Esta etapa define o modo de usar o RUP.

18. Construção • Objectivos • Minimizar custos de desenvolvimento • Alcançar um determinado grau de paralelismo de desenvolvimento • Desenvolver iterativamente um produto completo que esteja pronto para a transição

19. Construção (2) • Actividades Essenciais • Descrever Casos de Uso remanescentes • Completar o projecto de componentes e subsistemas • Completar o projecto do base de dados • Implementar e fazer testes de unidade • Integração e testes do sistema • Feedback dos clientes • Prerelease eversão final do sistema

20. Transição • Objectivos • Validar o sistema de acordo com a especificação do utilizador • Treinar utilizadores e Administradores • Preparar o local de implantação • ... • Assegurar disponibilidade do software para os utilizadores finais

21. Transição (2) • Actividades essenciais • Executar planos de deployment • Facultar material de suporte ao utilizador • Testar, no ambiente de desenvolvimento, o produto pronto para entrega • Gerar o release do produto (beta) • Recolher informação de feedback do utilizador • Ajustar o produto de acordo com o feedback • Disponibilizar o produto para os utilizadores finais

22. Conclusão • O RUP com a sua ferramenta de suporte é uma poderosa plataforma para Processos de Engenharia, que é configurável e extensível. • O correcto processo de desenvolvimento para um determinado projecto depende de inúmeros factores, incluindo tamanho do projecto, formalidade, tecnologia, técnicas aplicadas e filosofia de desenvolvimento. Para outros, podemos configurar um processo adequado através da selecção de plug-ins disponíveis e componentes. • Em suma, um RUP plug-in é um componente específico de um processo para uma determinada tecnologia, ferramenta, plataforma ou domínio contendo linhas orientadoras em texto ou em gráficos, exemplos e templates. • Esta arquitectura permite uma fácil configuração de um processo de acordo com as suas necessidades específicas.

23. Conclusão (2) • O RUP pode ser estendido por plug-ins criados por nós utilizando o Process Rational Workbench, e podem ser partilhados utilizando o RUP Exchange da Rational Developer Network. Na maior parte dos casos, deveremos considerar a construção de Thin RUP plug-ins utilizando o RUP Organizer. Os Thin Plug-ins permitem que adicionemos, modifiquemos, ou apaguemos, exemplos, templates, e assets reutilizáveis. • Os clientes mais experientes com necessidades específicas podem também produzir Structural RUP Plug-in utilizando o RUP Modeller, bem como o RUP Organizer. • Os Structural Plug-ins permitem maiores alterações no RUP. • O resultado final são um ou mais processos de desenvolvimento de software, adaptado ás necessidades actuais do projecto e organização, e permitir responder a novas necessidades futuras.

24. Referências • Rational Unified Process, version 2003, IBM Rational Software • Tool Mentor: Packaging Project Specific assets into Thin RUP Plug Ins with RUP Organizer