A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Armindo/ Sandra/ João 1 RUP Rational Unified Process Escola Superior de Tecnologia e Gestão Instituto Politécnico de Beja Trabalho 1 de Engenharia de Software."— Transcrição da apresentação:

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

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

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

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

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

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

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

8 8Armindo/ Sandra/ João 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. 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. Deve ser algo mais do que uma boa ideia rabiscada num papel, ser mostrada uma visão clara e o objectivo do projecto definido.

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

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

11 11Armindo/ Sandra/ João 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. 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. Muitas iterações podem ser necessárias antes que o utilizador aceite o sistema.

12 12Armindo/ Sandra/ João Fases

13 13Armindo/ Sandra/ João 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: 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; Desenvolver software iterativamente; Gerir requisitos; Gerir requisitos; Usar arquitectura baseada em componentes (e tecnologias); Usar arquitectura baseada em componentes (e tecnologias); Modelar visualmente o software; Modelar visualmente o software; Controlar o processo de alteração do software; Controlar o processo de alteração do software; Verificar a qualidade do software; Verificar a qualidade do software;

14 14Armindo/ Sandra/ João 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. 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. 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. É esperado que o software evolua e assim continue o ciclo, criando sucessivas versões.

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

16 16Armindo/ Sandra/ João 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. 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. Um componente normalmente relaciona-se com um objecto na programação orientada a objectos.

17 17Armindo/ Sandra/ João 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. 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. A linguagem de modelação UML tornou-se um padrão industrial para representar projectos, e é amplamente utilizada pelo RUP.

18 18Armindo/ Sandra/ João 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. 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. Deve entender-se primeiro e ser capaz de prever o impacto de alterações de software no sistema.

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

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

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

22 22Armindo/ Sandra/ João Implementação e Teste (cont.) Teste 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.

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

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

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


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

Apresentações semelhantes


Anúncios Google