Rational Unified Process

Apresentação em tema: "Rational Unified Process"— Transcrição da apresentação:

1 Rational Unified Process
Escola Superior de Tecnologia e Gestão Instituto Politécnico de Beja Trabalho 1 de Engenharia de Software RUP Rational Unified Process Armindo/ Sandra/ João

2 Assuntos a Tratar Características do RUP; Fases do RUP;
Melhores Praticas; Implementação e Testes; Armindo/ Sandra/ João

3 Introdução Rational Unified Process, ou RUP, é uma metodologia de projecto de software criada pela Rational Software Corporation. RUP descreve como desenvolver software usando técnicas testadas e aprovadas comercialmente. Armindo/ Sandra/ João

4 Características do RUP
Orientado a casos de uso; Iterativo e incremental; Gere todo o ciclo de vida do sistema; Particularmente aplicável a grandes equipas de desenvolvimento de software que trabalham em projectos grandes; É um processo pesado; Armindo/ Sandra/ João

5 As Fases do RUP O processo analítico do RUP divide o ciclo de vida de desenvolvimento de software em várias fases: Iniciação Elaboração Construção Transição Armindo/ Sandra/ João

6 As Fases do RUP Estas fases são executadas ciclicamente. Cada passo deve resultar num produto de software utilizável, mas não necessariamente um produto que atinge totalmente os requisitos do sistema. Armindo/ Sandra/ João

7 As Fases do RUP Este processo iterativo é considerado uma abordagem evolucionária para desenvolvimento de software. Cada iteração resulta em melhoras e num produto que está mais próximo do objectivo de um sistema completo. Armindo/ Sandra/ João

8 Iniciação A fase de iniciação representa o bloco inicial. Envolve a articulação da visão para o sistema e o estabelecimento de um projecto formal para a construção do mesmo. Deve ser algo mais do que uma boa ideia rabiscada num papel, ser mostrada uma visão clara e o objectivo do projecto definido. Armindo/ Sandra/ João

9 Elaboração Na fase de elaboração, o domínio do problema será detalhado e o objectivo do projecto será definido em grandes detalhes. Tanto os requisitos funcionais como os não-funcionais para o sistema devem ser definidos neste ponto. Os requisitos não-funcionais podem ser encarados como factores críticos para o sucesso, que descrevem o grau de risco envolvido no desenvolvimento do sistema. Armindo/ Sandra/ João

10 Construção A fase de construção começa por desenvolver os detalhes da arquitectura base e produz uma arquitectura final. Assim como noutras fases do desenvolvimento, é esperado que esta fase possa envolver múltiplas iterações. Armindo/ Sandra/ João

11 Transição Durante o processo de transição, o sistema é apresentado novamente ao utilizador final. Este pode testar o sistema e encontrar bugs que precisem ser corrigidos. Muitas iterações podem ser necessárias antes que o utilizador aceite o sistema. Armindo/ Sandra/ João

12 Fases Armindo/ Sandra/ João

13 Melhores Práticas O RUP utiliza muitas das melhores práticas de desenvolvimento moderno de software, num formulário apropriado para uma grande escala de projectos e das organizações: Desenvolver software iterativamente; Gerir requisitos; Usar arquitectura baseada em componentes (e tecnologias); Modelar visualmente o software; Controlar o processo de alteração do software; Verificar a qualidade do software; Armindo/ Sandra/ João

14 Desenvolver Software Iterativamente
Para se diferenciar de outras metodologias de software que o precederam, o RUP não requer a execução sequencial das fases, já que tal processo foi visto como lento e não eficaz. Em vez disso, as fases são executadas como ciclos com o término de cada um representando uma geração. Esta geração inclui uma versão do software e a sua documentação de suporte. É esperado que o software evolua e assim continue o ciclo, criando sucessivas versões. Armindo/ Sandra/ João

15 Gerir 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 artefactos dependentes do processo, que têm vindo a ser considerados muito mais eficazes na captura de requisitos funcionais. Armindo/ Sandra/ João

16 Usar 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. Armindo/ Sandra/ João

17 Modelar visualmente o software
O uso de modelos visuais permite 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 como um todo. A linguagem de modelação UML tornou-se um padrão industrial para representar projectos, e é amplamente utilizada pelo RUP. Armindo/ Sandra/ João

18 Controlar o processo de alteração do software
O processo de alteração do software pode impedir e tornar lento o desenvolvimento de um sistema. Deve entender-se primeiro e ser capaz de prever o impacto de alterações de software no sistema. Armindo/ Sandra/ João

19 Verificar a qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os projectos de software. Normalmente, pensa-se em qualidade de software após o término dos projectos. O RUP controla o planeamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipa de desenvolvimento. Armindo/ Sandra/ João

20 Implementação e Teste Implementação
O objectivo é construir o sistema, produzindo todo o código necessário para a criação do sistema executável. Os modelos de design são a base da implementação. A implementação inclui o teste de classes e módulos separados, mas não a verificação do seu funcionamento integrado. Armindo/ Sandra/ João

21 Implementação e Teste (cont.)
Armindo/ Sandra/ João

22 Implementação e Teste (cont.)
O objectivo é verificar o sistema na sua totalidade. Inicialmente verifica-se cada caso de uso separadamente e posteriormente o sistema na sua totalidade. No final desta actividade, o sistema está pronto para ser utilizado. Armindo/ Sandra/ João

23 Implementação e Teste (cont.)
Armindo/ Sandra/ João

24 Conclusão O RUP é uma boa ferramenta de apoio ao desenvolvimento de software com qualidade. Visa melhorar a produtividade da equipa de desenvolvimento de software. Embora as fases devam obedecer a um padrão cíclico, nada impede que as melhores práticas não possam ser executadas simultaneamente. Armindo/ Sandra/ João

25 Fim Trabalho realizado por: Armindo Costa nº 2711
João Amarante nº 2627 Sandra Gonçalves nº 2755 5º Ano Eng. Informática Armindo/ Sandra/ João