Armindo/ Sandra/ João 1 RUP Rational Unified Process Escola Superior de Tecnologia e Gestão...
Transcript of Armindo/ Sandra/ João 1 RUP Rational Unified Process Escola Superior de Tecnologia e Gestão...
Armindo/ Sandra/ João 1
RUPRUPRational Unified ProcessRational Unified Process
Escola Superior de Tecnologia e Gestão
Instituto Politécnico de Beja
Trabalho 1 de Engenharia de Software
2Armindo/ Sandra/ João
Assuntos a TratarAssuntos 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;
3Armindo/ Sandra/ João
IntroduçãoIntrodução
Rational Unified Process, ou RUP, é uma Rational Unified Process, ou RUP, é uma metodologia de projecto de software criada pela metodologia de projecto de software criada pela Rational Software Corporation.Rational Software Corporation.
RUP descreve como desenvolver software usando RUP descreve como desenvolver software usando técnicas testadas e aprovadas comercialmente.técnicas testadas e aprovadas comercialmente.
4Armindo/ Sandra/ João
Características do RUPCaracterí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 Particularmente aplicável a grandes equipas de
desenvolvimento de software que trabalham em desenvolvimento de software que trabalham em projectos grandes;projectos grandes;
É um processo pesado;É um processo pesado;
5Armindo/ Sandra/ João
As Fases do RUPAs Fases do RUP
O processo analítico do RUP divide o ciclo de vida O processo analítico do RUP divide o ciclo de vida de desenvolvimento de software em várias fases: de desenvolvimento de software em várias fases:
IniciaçãoIniciação ElaboraçãoElaboração ConstruçãoConstrução TransiçãoTransição
6Armindo/ Sandra/ João
As Fases do RUPAs Fases do RUP
Estas fases são executadas ciclicamente. Estas fases são executadas ciclicamente. Cada passo deve resultar num produto de Cada passo deve resultar num produto de software utilizável, mas não software utilizável, mas não necessariamente um produto que atinge necessariamente um produto que atinge totalmente os requisitos do sistema. totalmente os requisitos do sistema.
7Armindo/ Sandra/ João
As Fases do RUPAs Fases do RUP
Este processo iterativo é considerado uma Este processo iterativo é considerado uma abordagem evolucionária para abordagem evolucionária para desenvolvimento de software. desenvolvimento de software.
Cada iteração resulta em melhoras e num Cada iteração resulta em melhoras e num produto que está mais próximo do produto que está mais próximo do objectivo de um sistema completo. objectivo de um sistema completo.
8Armindo/ Sandra/ João
IniciaçãoIniciação
A fase de A fase de iniciaçãoiniciação representa o bloco representa o bloco inicial. Envolve a articulação da visão para inicial. Envolve a articulação da visão para o sistema e o estabelecimento de um o sistema e o estabelecimento de um projecto formal para a construção do projecto formal para a construção do mesmo. mesmo.
Deve ser algo mais do que uma boa ideia Deve ser algo mais do que uma boa ideia rabiscada num papel, ser mostrada uma rabiscada num papel, ser mostrada uma visão clara e o objectivo do projecto visão clara e o objectivo do projecto definido. definido.
9Armindo/ Sandra/ João
ElaboraçãoElaboração Na fase de Na fase de elaboraçãoelaboração, o domínio do , o domínio do
problema será detalhado e o objectivo do problema será detalhado e o objectivo do projecto será definido em grandes projecto será definido em grandes detalhes. Tanto os requisitos funcionais detalhes. Tanto os requisitos funcionais como os não-funcionais para o sistema como os não-funcionais para o sistema devem ser definidos neste ponto. devem ser definidos neste ponto.
Os requisitos não-funcionais podem ser Os requisitos não-funcionais podem ser encarados como factores críticos para o encarados como factores críticos para o sucesso, que descrevem o grau de risco sucesso, que descrevem o grau de risco envolvido no desenvolvimento do sistema. envolvido no desenvolvimento do sistema.
10Armindo/ Sandra/ João
ConstruçãoConstrução
A fase de A fase de construçãoconstrução começa por começa por desenvolver os detalhes da arquitectura desenvolver os detalhes da arquitectura base e produz uma arquitectura final. base e produz uma arquitectura final. Assim como noutras fases do Assim como noutras fases do desenvolvimento, é esperado que esta desenvolvimento, é esperado que esta fase possa envolver múltiplas iterações. fase possa envolver múltiplas iterações.
11Armindo/ Sandra/ João
TransiçãoTransição
Durante o processo de Durante o processo de transiçãotransição, o , o sistema é apresentado novamente ao sistema é apresentado novamente ao utilizador final. Este pode testar o sistema utilizador final. Este pode testar o sistema e encontrar bugs que precisem ser e encontrar bugs que precisem ser corrigidos. corrigidos.
Muitas iterações podem ser necessárias Muitas iterações podem ser necessárias antes que o utilizador aceite o sistema. antes que o utilizador aceite o sistema.
12Armindo/ Sandra/ João
FasesFases
13Armindo/ Sandra/ João
Melhores PráticasMelhores Práticas O RUP utiliza muitas das melhores práticas O RUP utiliza muitas das melhores práticas
de desenvolvimento moderno de software, de desenvolvimento moderno de software, num formulário apropriado para uma grande num formulário apropriado para uma grande escala de projectos e das organizações:escala de projectos e das organizações:
Desenvolver software iterativamente;Desenvolver software iterativamente; Gerir requisitos;Gerir requisitos; Usar arquitectura baseada em Usar arquitectura baseada em
componentes (e tecnologias);componentes (e tecnologias); Modelar visualmente o software;Modelar visualmente o software; Controlar o processo de alteração do Controlar o processo de alteração do
software;software; Verificar a qualidade do software;Verificar a qualidade do software;
14Armindo/ Sandra/ João
Desenvolver Software IterativamenteDesenvolver Software Iterativamente Para se diferenciar de outras metodologias Para se diferenciar de outras metodologias
de software que o precederam, o RUP não de software que o precederam, o RUP não requer a execução sequencial das fases, já requer a execução sequencial das fases, já que tal processo foi visto como lento e não que tal processo foi visto como lento e não eficaz. eficaz.
Em vez disso, as fases são executadas Em vez disso, as fases são executadas como ciclos com o término de cada um como ciclos com o término de cada um representando uma geração. Esta geração representando uma geração. Esta geração inclui uma versão do software e a sua inclui uma versão do software e a sua documentação de suporte. documentação de suporte.
É esperado que o software evolua e assim É esperado que o software evolua e assim continue o ciclo, criando sucessivas continue o ciclo, criando sucessivas versões.versões.
15Armindo/ Sandra/ João
Gerir requisitosGerir requisitos Uma documentação apropriada é Uma documentação apropriada é
essencial para qualquer grande projecto; essencial para qualquer grande projecto; note-se que o RUP descreve como note-se que o RUP descreve como documentar a funcionalidade, restrições documentar a funcionalidade, restrições de sistema, restrições de projecto e de sistema, restrições de projecto e requisitos de negócio.requisitos de negócio.
Os casos de uso e os cenários são Os casos de uso e os cenários são exemplos de artefactos dependentes do exemplos de artefactos dependentes do processo, que têm vindo a ser processo, que têm vindo a ser considerados muito mais eficazes na considerados muito mais eficazes na captura de requisitos funcionais.captura de requisitos funcionais.
16Armindo/ Sandra/ João
Usar arquitectura baseada em componentes Usar arquitectura baseada em componentes
A arquitectura baseada em componentes A arquitectura baseada em componentes cria um sistema que pode ser facilmente cria um sistema que pode ser facilmente extensível, promovendo a reutilização de extensível, promovendo a reutilização de software e um entendimento intuitivo. software e um entendimento intuitivo.
Um componente normalmente relaciona-se Um componente normalmente relaciona-se com um objecto na programação orientada com um objecto na programação orientada a objectos.a objectos.
17Armindo/ Sandra/ João
Modelar visualmente o softwareModelar visualmente o software
O uso de modelos visuais permite que O uso de modelos visuais permite que indivíduos de perfil menos técnico (como indivíduos de perfil menos técnico (como clientes) tenham um melhor entendimento de clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais um dado problema, e assim se envolvam mais no projecto como um todo.no projecto como um todo.
A linguagem de modelação UML tornou-se um A linguagem de modelação UML tornou-se um padrão industrial para representar projectos, e padrão industrial para representar projectos, e é amplamente utilizada pelo RUP.é amplamente utilizada pelo RUP.
18Armindo/ Sandra/ João
Controlar o processo de alteração do Controlar o processo de alteração do softwaresoftware
O processo de alteração do software pode O processo de alteração do software pode impedir e tornar lento o desenvolvimento impedir e tornar lento o desenvolvimento de um sistema. de um sistema.
Deve entender-se primeiro e ser capaz de Deve entender-se primeiro e ser capaz de prever o impacto de alterações de prever o impacto de alterações de software no sistema.software no sistema.
19Armindo/ Sandra/ João
Verificar a qualidade do softwareVerificar a qualidade do software
Não assegurar a qualidade do software é a Não assegurar a qualidade do software é a falha mais comum em todos os projectos falha mais comum em todos os projectos de software. Normalmente, pensa-se em de software. Normalmente, pensa-se em qualidade de software após o término dos qualidade de software após o término dos projectos. projectos.
O RUP controla o planeamento da O RUP controla o planeamento da qualidade, verificando-a na construção de qualidade, verificando-a na construção de todo o processo e envolvendo todos os todo o processo e envolvendo todos os membros da equipa de desenvolvimento.membros da equipa de desenvolvimento.
20Armindo/ Sandra/ João
Implementação e TesteImplementaçã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.
21Armindo/ Sandra/ João
Implementação e Teste (cont.)
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.
23Armindo/ Sandra/ João
Implementação e Teste (cont.)
24Armindo/ Sandra/ João
ConclusãoConclusão
O RUP é uma boa ferramenta de apoio ao O RUP é uma boa ferramenta de apoio ao desenvolvimento de software com desenvolvimento de software com qualidade.qualidade.
Visa melhorar a produtividade da equipa Visa melhorar a produtividade da equipa de desenvolvimento de software.de desenvolvimento de software.
Embora as fases devam obedecer a um Embora as fases devam obedecer a um padrão cíclico, nada impede que as padrão cíclico, nada impede que as melhores práticas não possam ser melhores práticas não possam ser executadas simultaneamente.executadas simultaneamente.
25Armindo/ Sandra/ João
FimFim
Trabalho realizado por:Trabalho realizado por:
Armindo Costa nº 2711Armindo Costa nº 2711
João Amarante nº 2627João Amarante nº 2627
Sandra Gonçalves nº 2755Sandra Gonçalves nº 2755
5º Ano Eng. Informática5º Ano Eng. Informática