IBM Rational Unified Process (RUP)

Melhores práticas comprovadas para software e entrega e implementação de sistemas e de gerenciamento de projetos eficazIBM Rational Unified Process ® (RUP ®) é um framework de processo abrangente que fornece indústria testadas práticas para software e entrega e implementação de sistemas e de gerenciamento de projetos eficaz. É um dos muitos processos contidos na Biblioteca Rational Process , que oferece melhor orientação de práticas adequadas para o seu desenvolvimento em particular ou necessidade do projeto.IBM Rational Method Composer permite que você personalize facilmente RUP para atender as necessidades específicas de seu projeto. Ele permite que você selecionar e implantar somente os componentes do processo que você precisa, e depois publicá-lo através de sua intranet.O RUP âmbito do processo com o Rational Method Composer fornece:

Processos baseados nas melhores práticas adotadas em milhares de projetos em todo o mundo. Evite inventar tudo do zero e reutilização de processos que têm sido bem sucedidas para outras organizações.

Padrões de capacidade que permitem que os gerentes de projeto para rapidamente adicionar ou remover pedaços reutilizáveis de processos que tratam de problemas comuns.Porque não há dois projetos são iguais, gerentes de projeto podem modificar o processo para atender às necessidades específicas do projeto.

Ready-to-use processos de entrega de fornecer o gerente de projeto com um ponto de partida para o planejamento rápida e iniciar um projeto. Um processo de entrega oferece um modelo de projeto inicial e identifica quais marcos de tipo para usar no projeto, que trabalham para oferecer produtos de cada etapa, e quais recursos são necessários para cada fase.

RUP promove o desenvolvimento iterativo e organiza o desenvolvimento de software e sistemas em quatro fases, cada uma consistindo de uma ou mais iterações executáveis do software a essa fase de desenvolvimento.

RUP – PRIMEIROS PASSOSPublicado por Rafael Peria de Sene  /   16 de fevereiro de 2011  /   Em Desenvolvimento, TI

Corporativa  /   0Comentários

Rational Unified Process (RUP) é um processo de engenharia de software que fornece uma abordagem

disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento,

cujo objetivo é assegurar a produção de software de alta qualidade dentro de prazos e orçamentos

previsíveis (Kruchten 2003, pág. 14). Derivado dos trabalhos sobre UML[1] e do Processo Unificado de

Desenvolvimento de Software, ele traz elementos de todos os modelos genéricos de processo, apoia a

iteração e ilustra boas práticas de especificação e projeto (Sommervillie 2007, pág. 54). Ele captura

seis das melhores práticas no desenvolvimento de software de forma satisfatória para uma grande

faixa de projetos e organizações (Krutchten 2003, pág. 14). As melhores práticas abordadas são as

seguintes (Sommerville 2007, pág. 56):

1. Desenvolver o software iterativamente: planejar os incrementos de software com base nas

prioridades do cliente e desenvolver e entregar o mais cedo possível às características de sistema de    

maior prioridade no processo de desenvolvimento.

2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e manter

acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no sistema antes

de aceitá-las.

3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do sistema com

componentes, reduzindo a quantidade de software a ser desenvolvido e, consequentemente, reduzir

custos e riscos.

4. Modelar software visualmente: usar modelos gráficos de UML para apresentar as visões estática

e dinâmica do software.

5. Verificar a qualidade do software: garantir que o software atenda aos padrões de qualidade da

organização.

6. Controlar as mudanças do software: gerenciar as mudanças do software, usando um sistema de

gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento de configuração.

O RUP é um modelo constituído por quatro fases do processo de software, relacionadas mais

estritamente aos negócios do que a assuntos técnicos (Sommerville 2007, pág. 54). As quatro fases do

RUP são descritas abaixo:

1. Concepção: o objetivo desta fase é estabelecer um business case[2] para o sistema. Devem ser

identificadas todas as entidades externas (pessoas e sistemas) que irão interagir com o sistema em

desenvolvimento e definir essas interações. Essas informações são utilizadas para avaliar a

contribuição do novo sistema para o negócio.

2. Elaboração: os objetivos desta fase são desenvolver um entendimento do domínio do problema,

estabelecer um framework[3] de arquitetura para o sistema, desenvolver o plano de projeto e

identificar seus principais riscos. Ao final desta fase deve-se ter um modelo de requisitos para o

sistema (os casos de uso da UML são especificados), uma descrição de arquitetura e um plano de

desenvolvimento do software.

3. Construção: está fase está essencialmente relacionada ao projeto, programação e teste do

sistema. As partes do sistema são desenvolvidas paralelamente e integradas durante esta fase. Ao final

deve-se ter um sistema de software em funcionamento e a documentação associada pronta para ser

liberada para os usuários.

4. Transição: nesta fase, faz-se a transferência do sistema da comunidade de desenvolvimento para a

comunidade de usuários, com a entrada do sistema em funcionamento no ambiente real. Esta é uma

atividade ignorada na maioria dos modelos de processo de software, pois é onerosa e às vezes

problemática. Ao final desta fase, deve-se ter um sistema de software documentado, funcionando

corretamente em seu ambiente operacional.

Cada uma das fases descritas acima pode ser realizada de forma iterativa, com os resultados

desenvolvidos incrementalmente.

As atividades que ocorrem durante o processo de desenvolvimento são chamadas

de workflows. Existem seis workflows principais, exibidos na Tabela 1.

WorkflowDescrição

Modelagem de Negócios

Os processos de negócio são modelados usando casos de uso de

negócios.

Requisitos

Os agentes que interagem com o sistema são identificados e os casos de uso são desenvolvidos para modelar os requisitos do sistema.

Análise e Projeto

Um modelo de projeto é criado e documentado usando modelos de arquitetura, modelos de componente, modelos de objetos e modelos de sequencia.

Implementação Os componentes de sistema são

implementados e estruturados em subsistemas de implementação. A geração automática de código com base os modelos de projeto ajuda a acelerar esse processo.

Teste

O teste é um processo iterativo realizado em conjunto com a

implementação. O teste de sistema segue o término da implementação.

Implantação

Uma versão do produto é criada, distribuída aos usuários e instalada no

local de trabalho.

Gerenciamento de Configuração e

Mudança

Este workflow de apoio gerencia mudanças no sistema.

Gerenciamento de Projetos

Este workflow de apoio gerencia o desenvolvimento do sistema.

Ambiente

Este workflow está relacionado à disponibilização de ferramentas apropriadas de software para a equipe de desenvolvimento.

Tabela 1 : Workflows no Rational Unified Process (Sommerville 2007, pág. 55)

Embora o RUP não seja um processo adequado a todos os tipos de desenvolvimento de software, ele

representa uma nova geração de processos genéricos. A mais importante inovação é a separação de

fases e workflows, e o reconhecimento de que a implantação de software no ambiente do usuário é

parte do processo. As fases são dinâmicas e tem objetivos. Os workflows são estáticos e constituem

atividades técnicas que não estão associadas a uma única fase, mas podem ser utilizados ao longo do

desenvolvimento para atingir os objetivos de cada fase (Sommerville 2007, pág. 56).

 Referências

Businesscase (2011), http://www.businesscase.com.br  acesso em 22/01/11.

Sommerville, I. (2007), Engenharia de Software, Oitava Edição, Pearson Addison-Wesley.

Larman, Craig. (2007), Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a

objetos e ao desenvolvimento iterativo,  Terceira Edição, Bookman.

Kruchten, Phillippe. (2003), Introdução ao RUP: Rational Unified Process, Primeira Edição, Ciência

Moderna.

[1] UML é uma linguagem visual para especificar, construir e documentar os artefatos do sistema

(Craig 2007, pág. 39).

[2] Business Case é uma forma de justificar o investimento para aprovar um projeto estratégico que

agrega valor ao negócio da empresa (BusinessCase, 2011).

[3] Framework é uma estrutura genérica em um domínio específico que pode formar a base de uma

família de aplicações. Os frameworks são geralmente implementados como um conjunto de classes

concretas e abstratas, especializadas e instanciadas para criar uma aplicação (Sommerville 2007, pág.

527).

7

inShare

Rafael Peria de SeneBacharel em Ciência da Computação pela Universidade Federal de Alfenas. Desenvolvi durante a

graduação pesquisas nas áreas de engenharia de software e processos de desenvolvimento de

software. Tenho sólidos conhecimentos em processos de desenvolvimento de software (RUP e

OpenUP), análise e coleta de requisitos, métodos ágeis de desenvolvimento (SCRUM e XP),

programação utilizando as linguagens Java, C e SQL e modelagem de dados utilizando UML.

O Processo Unificado da Rational conhecido como RUP (Rational Unified Process), é um processo

de engenharia de software  criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemática para se obter vantagens no uso da UML. Foi criado pela Rational Software Corporation e adquirido em fevereiro de 2003 pela IBM.

O principal objetivo do RUP é atender as necessidades dos usuários garantindo uma produção de software de alta qualidade que cumpra um cronograma e um orçamento previsíveis. Assim, o RUP mostra como o sistema será construído na fase de implementação, gerando o modelo do projeto e, opcionalmente, o modelo de análise que é utilizado para garantir a robustez. O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcançadas.

O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software.  Cada fase tem um papel fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais como o Analista de sistema, Projetista, Projetista de testes, entre outros.

Fases do RUP

Fase de Concepção / Iniciação: Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.

Fase de Elaboração: Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa.

Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.

Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

Referências Bibliográficas:

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Processhttp://www.ibm.com/software/awdtools/rup/

http://www.infoescola.com/engenharia-de-software/rup/

http://www-01.ibm.com/software/awdtools/rup/

http://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos/#.UUkNBBzvvRM

O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário

de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo

nome IRUPque agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de

Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o

objetivo de aumentar a sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a

notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas

comercialmente.

É 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.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por

diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e

os Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

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, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os

programadores a manterem-se concentrados no projeto.

[editar]Gestão de requisitos

Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve como

documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.

Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm

sido considerados muito mais eficazes na captura de requisitos funcionais.

[editar]Uso de arquitetura baseada em componentes

A arquitetura 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 se relaciona com um objeto na

programação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura

executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.

Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de

Componentes de Objectos).

[editar]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 efetiva 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 projeto como um todo.

A linguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada

pelo RUP!

[editar]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.

[editar]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.

[editar]Fases

Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projeto. As fases

(vide figura abaixo) indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do

tempo de um projeto, o RUP divide o projeto em quatro fases diferentes:

1. Iniciação ou 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.

O RUP também se baseia nos 4 Ps:

1. Pessoas

2. Projeto

3. Produto

4. Processo

As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido

enquanto as fases são objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir

melhor acompanhamento.

[editar]Fase de Concepção

A fase de iniciação ou concepção contém os workflows necessários à concordância dos stakeholders - as partes

interessadas - com os objetivos, a arquitetura e o planejamento do projeto. Se essas partes interessadas tiverem

bons conhecimentos, pouca análise será requerida. Caso contrário, será exigida uma análise mais elaborada. Nesta

fase, os requisitos essenciais do sistema são transformados em casos de uso. O objetivo não é fechá-los em sua

totalidade, mas apenas aqueles necessários à formação de opinião. A etapa é geralmente curta e serve para definir

se é viável continuar com o projeto e definir os riscos e o custo deste último. Um protótipo pode ser feito para que o

cliente possa aprovar. Como cita o RUP, o ideal é que sejam feitas iterações, mas estas devem ser bem definidas

quanto à sua quantidade e aos objetivos.

[editar]Fase de Elaboração

A fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento /

documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os

projetos e inicia a versão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração)

está estável?; O plano do projeto é confiável?; Custos são admissíveis?

[editar]Fase de Construção

Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa. Os testes

beta são realizados no início da fase de Transição.

Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline".

[editar]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.

[editar]Disciplinas

[editar]Seis Disciplinas de Engenharia

[editar]Disciplina de Modelagem de Negócios

As organizações estão cada vez mais dependentes de sistemas de TI, tornando-se imperativo que os engenheiros

de sistemas de informação saibam como as aplicações em desenvolvimento se inserem na organização. As

empresas investem em TI, quando entendem a vantagem competitiva do valor acrescentado pela tecnologia. O

objetivo de modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de

comunicação entreengenharia de negócios e engenharia de software. Compreender o negócio significa que os

engenheiros de software devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais

problemas na organização e possíveis melhorias. Eles também devem garantir um entendimento comum da

organização-alvo entre os clientes, usuários finais e desenvolvedores.

Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será implantado e

como usar esta visão como uma base para descrever o processo, papéis e responsabilidades.

[editar]Disciplina de Requisitos

Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um

conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos

detalhados para o que deve fazer o sistema.

[editar]Disciplina de Análise e Projeto("Design")

O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um sistema que:

Execute, em um ambiente de execução específico, as tarefas e funções especificadas nas descrições de casos

de uso

Cumpra todas as suas necessidades

Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais

Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de análise. O modelo de

design serve como uma abstração do código-fonte, isto é, o projeto atua como um modelo de "gabarito" de como o

código-fonte é estruturado e escrito. O modelo de projeto consiste em classes de design estruturado em pacotes e

subsistemas com interfaces bem definidas, representando o que irá se tornar componentes da aplicação. Ele também

contém descrições de como os objetos dessas classes colaboram para desempenhar casos de uso do projeto.

[editar]Disciplina de Implementação

Os efeitos da implementação são:

Para definir a organização do código, em termos de subsistemas de implementação organizadas em camadas

Para implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)

Para testar os componentes desenvolvidos como unidades

Integrar os resultados produzidos por implementadores individuais (ou equipes), em um sistema executável

Sistemas são realizados através da aplicação de componentes. O processo descreve como reutilizar componentes

existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o sistema mais fácil

de manter e aumentar as possibilidades de reutilização.

[editar]Disciplina de Teste

As finalidades da disciplina de teste são:

Para verificar a interação entre objetos

Para verificar a integração adequada de todos os componentes do software

Para verificar se todos os requisitos foram corretamente implementados

Identificar e garantir que os defeitos são abordados antes da implantação do software

Garantir que todos os defeitos são corrigidos, reanalisados e fechados

O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto

permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes

são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação,

e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o processo descreve como você

passar pelo teste do ciclo de planejamento, projeto, implementação, execução e avaliação.

[editar]Disciplina de Implantação

O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus

usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a

embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de

ajuda e assistência aos usuários. Embora as atividades de implantação estejam principalmente centradas em torno

da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a

implantação, no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP

contêm menos detalhes do que outros workflows.

[editar]Três Disciplinas de Apoio/Suporte

[editar]Disciplina de Ambiente

O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades

necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à

organização de desenvolvimento de software os processos e as ferramentas que darão suporte à equipe de

desenvolvimento. Se os usuários do RUP não entendem que o RUP é um framework de processo, eles podem

percebê-lo como um processo pesado e caro. No entanto, um conceito-chave dentro do RUP foi que o processo RUP

pode e, muitas vezes, deve ser refinado. Este foi inicialmente feito manualmente, ou seja, por escrito, um documento

de "caso de desenvolvimento" que especificou o processo refinado para ser utilizado. Posteriormente, o produto IBM

Rational Method Composer foi criado para ajudar a tornar esta etapa mais simples, engenheiros de

processos e gerentes de projeto poderiam mais facilmente personalizar o RUP para suas necessidades de projeto.

Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a versão open-source e leve do RUP, são agora

apresentados como processos distintos, por direito próprio, e atendem a diferentes tipos e tamanhos de projetos,

tendências e tecnologias de desenvolvimento de software. Historicamente, como o RUP, muitas vezes é

personalizado para cada projeto por um perito do processo RUP, o sucesso total do projeto pode ser um pouco

dependente da capacidade desta pessoa.

[editar]Disciplina de Configuração e Gerência de Mudança

A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de

configuração, de solicitações de mudança, e de status e medição.

Gerenciamento de configuração: A gestão de configuração é responsável pela estruturação sistemática dos

produtos. Artefatos, como documentos e modelos, precisam estar sob controle de versão e essas alterações

devem ser visíveis. Ele também mantém o controle de dependências entre artefatos para que todos os artigos

relacionados sejam atualizados quando são feitas alterações

Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de sistemas com muitos

artefatos existem diversas versões. O CRM mantém o controle das propostas de mudança

Gerenciamento de status e medição: Os pedidos de mudança têm os

estados: novo, conectado, aprovado, cedido e completo. A solicitação de mudança também tem atributos como a

causa raiz, ou a natureza (como o defeito e valorização), prioridade, etc. Esses estados e atributos são

armazenados no banco de dados para produzir relatórios úteis sobre o andamento do projeto. A Rational

também tem um produto para manter a solicitações de mudança chamado ClearQuest. Esta atividade têm

procedimentos a serem seguidos

[editar]Disciplina de Gerência de Projeto

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou planos de Fase que

descreve todo o projeto, e uma série de alta granularidade ou planos de Iteração que descrevem os passos

iterativos. Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de

desenvolvimento iterativo: Gestão de riscos; Planejamento um projeto iterativo através do ciclo de vida e para uma

iteração particular; E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do

RUP não tenta cobrir todos os aspectos do gerenciamento de projetos.

Por exemplo, não abrange questões como:

Gestão de Pessoas: contratação, treinamento, etc

Orçamento Geral: definição, alocação, etc

Gestão de Contratos: com fornecedores, clientes, etc

[editar]Princípios e melhores prática

RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas, por exemplo:

1. Desenvolvimento de software iterativo

2. Gerenciamento de requisitos

3. Uso de arquitetura baseada em componente

4. Modelagem visual de software

5. Verificação da qualidade do software

6. Controle de alteração no software

[editar]Desenvolvimento iterativo

Dado o tempo gasto para desenvolver um software grande e sofisticado, não é possível definir o problema e construir

o software em um único passo. Os requerimentos irão freqüentemente mudar no decorrer do desenvolvimento

doprojeto, devido a restrições de arquitetura, necessidades do usuário ou a uma maior compreensão do problema

original. Alterações permitem ao projeto ser constantemente refinado, além de assinalarem itens de alto risco do

projeto como as tarefas de maior prioridade. De forma ideal, ao término de cada iteração haverá uma versão

executável, o que ajuda a reduzir o risco de configuração do projeto, permitindo maior retorno do usuário e ajudando

ao desenvolvedor manter-se focado.

O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:

A integração é feita passo a passo durante o processo de desenvolvimento, limitando-se cada passo a poucos

elementos

A integração é menos complexa, reduzindo seu custo e aumentado sua eficiência

Partes separadas de projeto e/ou implementação podem ser facilmente identificadas para posterior reuso

Mudanças de requisitos são registradas e podem ser acomodadas

Os riscos são abordados no inicio do desenvolvimento e cada iteração permite a verificação de riscos já

percebidos bem como a identificação de novos

Arquitetura de software é melhorada através de um escrutino repetitivo

Usando iterações, um projeto terá um plano geral, como também múltiplos planos de iteração. O envolvimento

dos stakeholders é freqüentemente encorajado a cada entrega. Desta maneira, as entregas servem como uma forma

de se obter o comprometimento dos envolvidos, promovendo também uma constante comparação entre

os requisitos e o desenvolvimento da organização para as pendências que surgem.

[editar]Gerenciamento de requisitos

O Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades do usuário final pela

identificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto traz como

benefícios:

A correção dos requisitos gera a correção do produto, desta forma as necessidadades dos usuários são

encontradas.

As características necessárias serão incluídas, reduzindo o custo de desenvolvimentos posteriores.

RUP sugere que o gerenciamento de requisitos tem que seguir as atividades:

Análise do problema é concordar com o problema e criar medições que irão provar seu valor para a

organização

Entender as necessidades de seus stakeholders é compartilhar o problema e valores com os stakeholders-

chave e levantar quais as necessidades que estão envolvidas na elaboração da ideia

Definir o problema é a definição das características das necessidades e esquematização dos casos de uso,

atividades que irão facilmente mostrar os requisitos de alto-nível e esboçar o modelo de uso do sistema

Gerenciar o escopo do sistema trata das modificações de escopo que serão comunicadas baseadas nos

resultados do andamento e selecionadas na ordem na qual os fluxogramas de casos de uso são atacados

Refinar as definições do sistema trata do detalhamento dos fluxogramas de caso de uso com

os stakeholders de forma a criar uma especificação de requerimentos de software que pode servir como um

contrato entre o seu grupo e o do cliente e poderá guiar as atividades de teste e projeto

Gerenciamento das mudanças de requisitos trata de como identificar as chegadas das mudanças de

requerimento num projeto que já começou

[editar]Uso de arquitetura baseada em componentes

Arquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão e

promove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto

de objetos naprogramação orientada ao objeto.

Arquitetura de software aumenta de importância quando um sistema se torna maior e mais complexo. RUP foca na

produção da arquitetura básica nas primeiras iterações. Esta arquitetura então se torna um protótipo nos ciclos

iniciais de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final do

sistema. RUP também propõe regras de projeto e restrições para capturar regras de arquitetura. Pelo

desenvolvimento iterativo é possível identificar gradualmente componentes os quais podem então ser desenvolvidos,

comprados ou reusados. Estes componentes são freqüentemente construídos em infra-estruturas existentes tais

como CORBA e COM, ouJavaEE, ou PHP

[editar]Modelagem visual de software

Abstraindo sua programação do seu código e representando-a usando blocos de construção gráfica constitui-se de

uma forma efetiva de obter uma visão geral de uma solução. Usando esta representação, recursos técnicos podem

determinar a melhor forma para implementar a dado conjunto de interdependências lógicas. Isto também constrói

uma camada intermediária entre o processo de negócio e o código necessário através da tecnologia da informação.

Um modelo neste contexto é uma visualização e ao mesmo tempo uma simplificação de um projeto complexo. RUP

especifica quais modelos são necessários e porque.

A Linguagem modelagem unificada (UML) pode ser usada para modelagem de Casos de Uso, diagrama de classes e

outros objetos. RUP também discute outras formas para construir estes modelos.

[editar]Verificar qualidade de software

Garantia da qualidade de software é o ponto mais comum de falha nos projetos de software, desde que isto é

freqüentemente algo que não se pensa previamente e é algumas vezes tratado por equipes diferentes. O RUP ajuda

no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os

membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada

membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de

qualidade esperado e provê testes nos processos para medir este nível.

[editar]Controle de alterações no software

Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear e

monitorar estas mudanças. RUP também define espaços de trabalho seguros (do inglês secure workspaces),

garantindo que um sistema de engenharia de software não será afetado por mudanças em outros sistemas. Este

conceito é bem aderente com arquiteturas de software baseados em componentização.

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process