RUP Rational Unified Proccess (Processo Unificado da Rational) Equipe WEB Cercomp

Transcrição

1 RUP Rational Unified Proccess (Processo Unificado da Rational) Equipe WEB Cercomp

2 1. Introdução É um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, então o RUP ganhou o nome de IRUP IBM Rational Unified Software (porém o nome mais conhecido ainda é RUP); Fornece técnicas às equipes de desenvolvimento de software objetivando o aumento da produtividade seguindo uma abordagem prescritiva (normatização); O RUP se baseia no paradigma de Orientação a Objetos e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos 2 em ação.

3 1. Introdução É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos; Porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala; Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software. 3

4 1. Introdução O RUP se baseia nos 4 P s: Pessoas; Projeto; Produto; Processo. 4

5 2. Linhas Mestras O RUP define as seguintes linhas mestras e esqueletos (templates) para os membros da equipe de um ciclo de produção: Parte do cliente; Avaliação do progresso do projeto pela sua gerência. Ajuda os programadores a manterem se concentrados no projeto. 5

6 2.1. Gestão de requisitos Descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio (Uma documentação apropriada é essencial para qualquer grande projeto). Os casos de uso (Use Cases) e os cenários são exemplos de artefatos (produtos de trabalho finais ou intermediários produzidos e usados durante os projetos) dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais descrição das diversas funções que clientes e usuários querem ou precisam que o software faça. 6

7 2.1. Gestão de requisitos 7

8 2.2. Arquitetura baseada em componentes Sistema que pode ser facilmente extensível; Reutilização de software e um entendimento intuitivo; Um componente normalmente se relaciona com um objeto na programação orientada a objetos; Arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala; Estes componentes são normalmente incluídos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objetos). 8

9 2.3. Software de modelos visuais Elaborar de modo efetivo uma maneira de se ter uma visão geral de uma solução; Melhor entendimento por parte de pessoas com menor conhecimento técnico (ex: cliente) de um dado problema, e assim se envolvam mais no projeto como um todo; A linguagem de modelagem UML tornou se um padrão industrial para representar projetos e é amplamente utilizada pelo RUP. 9

10 2.4. Verificação da qualidade do software 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. 10

11 2.5. Gestão e Controle de Mudanças do Software Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, 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. 11

12 3. Fases Indicam a ênfase que é dada ao projeto em um momento específico; Um projeto é dividido em quatro fases: 1. Concepção: ênfase no escopo do sistema; 2. Elaboração: ênfase na arquitetura; 3. Construção: ênfase no desenvolvimento; 4. Transição: ênfase na implantação. 12

13 3.1. Fase de concepção Delimitação do âmbito do projeto e do business case¹, afim de que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto. [1]. Forma profissional de justificar o investimento para aprovar um projeto estratégico que agrega valor ao negócio da empresa. 13

14 3.2. Fase de Elaboração Análise da extensão do sistema (ex: problemas a serem resolvidos); Definição de uma arquitetura estável e robusta para todo o sistema, tendo em consideração os seus requisitos; Busca complementar o levantamento/documentação dos casos de uso. 14

15 3.3. Fase Construção Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta; Deve se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline" imagem de uma versão de cada artefato. 15

16 3.4. Fase de Transição Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega, acompanhamento e qualidade do software; Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do cliente; Nesta fase também é realizada a capacitação dos usuários. 16

17 4. Processo RUP - Gráfico 17

18 Referências Wthreex RUP Portugues Wikipedia RUP Process 18