VANTAGENS E DESVANTAGENS DO RUP

Vantagens:

    * Processo robusto e bem definido com a geração de artefatos importantes: O RUP tem como base os princípios de engenharia de software reflectidos na sua abordagem de desenvolvimento iterativa, incremental, orientada a requisitos e baseada em arquitectura

    * Os maiores riscos são atacados primeiro, diminuindo as chances de fracasso do projeto

   * O RUP captura muitas das melhores práticas do desenvolvimento de software moderno, de forma que possam ser adaptadas para uma grande variedade de projetos e de organizações:

• Desenvolver iterativamente;
• Gerenciar Requisitos;
• Usa arquitetura baseada em componentes;
• Modelagem Visual;
• Qualidade de software; 
• Produtividade no desenvolvimento, operação e manutenção de software; 
• Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados; 
• Estimativa de prazos e custos com maior precisão. 

Desvantagens:

    * Complexo e trabalhoso para projetos de pequeno porte: Sério investimento em ferramenta de suporte

    * Limitações:  Nas áreas de manutenção, gestão de métricas, gestão de pessoal, gestão de reutilização e testes. Exige experiência da equipe.

    Obs: Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de maneira imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no contexto ao qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e tempo para a absorção da metodologia.

   

Estudo de Caso PMBOK - Regional (Manaus - AM)

Aqui Apresentamos um Estudo de Caso na Utilização do Pmbok na Cidade de Manaus

O material foi colhido na internet e não é de autoria dos autores do Blog no entanto no documento apresentado é citado os autores do Estudo. 

Estudo de Caso - PMBOK na cidade de Manaus

28814776 from Urique Hoffmann

RUP - Princípios e Melhores Práticas - Uso de Arquitetura Baseada em Componentes

Um Breve Resumo e Contextualização:

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

O que significa Arquitetura de Componentes?

Os componentes são grupos de código coesos, na forma de código fonte ou executável, com interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis. As arquiteturas baseadas em componentes tendem a reduzir o tamanho efetivo e a complexidade da solução e, portanto, são mais robustas e flexíveis.

Ênfase Arquitetural

Os casos de uso orientam o Rational Unified Process (RUP) durante todo o ciclo de vida, mas as atividades de design são centralizadas na noção da arquitetura do sistema e em sistemas intensivos de software, arquitetura de software. O foco principal das iterações iniciais do processo, principalmente na fase de elaboração, é produzir e validar uma arquitetura de software, que no ciclo de desenvolvimento inicial toma a forma de um protótipo arquitetural executável que gradualmente evolui até se tornar o sistema final em iterações posteriores.

Arquitetura executável significa uma implementação parcial do sistema criada para demonstrar funções e propriedades selecionadas do sistema, em particular aquelas que satisfazem requisitos não funcionais. A finalidade da arquitetura executável é diminuir os riscos relacionados a desempenho, taxa de transferência, capacidade, confiabilidade, etc. para que a capacidade funcional completa do sistema possa ser adicionada na fase de construção de uma forma segura, sem perigo de quebra.

Para obter uma introdução da noção de arquitetura, mais especificamente arquitetura de software, e para uma explicação de por que essa noção é crucial, consulte Conceitos: Arquitetura de Software.

O RUP fornece uma maneira metódica e sistemática de projetar, desenvolver e validar uma arquitetura. Oferecemos templates para descrição da arquitetura, com os conceitos de várias visões arquiteturais, e para a captura de estilo de arquitetura, regras de design e restrições. A disciplina Análise e Design contém atividades específicas orientadas para identificar restrições arquiteturais e para elementos significativos na arquitetura, além de diretrizes sobre como fazer escolhas arquiteturais. O processo de gerenciamento mostra como o planejamento das iterações iniciais considera o design de uma arquitetura e a resolução dos principais riscos técnicos. Consulte a disciplina Gerenciamento de Projeto e todas as atividades associadas ao Papel: Arquiteto de Software para obter mais informações.

A arquitetura é importante por vários motivos:

    Ela permite obter e manter controle intelectual do projeto, gerenciar sua complexidade e manter a integridade do sistema.

    Um sistema complexo é mais que a soma de suas partes; mais que uma sucessão de pequenas decisões táticas independentes. Ele precisa ter uma estrutura unificadora e coerente para organizar essas partes de modo sistemático e fornecer regras precisas sobre como pode ser aumentado, sem que sua complexidade cresça além da compreensão humana.

    A arquitetura determina os meios para se obter melhor comunicação e entendimento em todo o projeto, estabelecendo um conjunto de referências e um vocabulário comuns, com os quais se discutem questões de design.

    É uma base efetiva para reutilização em larga escala.

    Ao articular claramente os principais componentes e as interfaces críticas entre eles, uma arquitetura permite que você raciocine sobre a reutilização, tanto a reutilização interna que é a identificação das partes comuns, como a reutilização externa que é a incorporação de componentes desenvolvidos internamente e adquiridos prontos para serem usados. No entanto, também permite a reutilização em uma escala maior: a reutilização da própria arquitetura, no contexto de uma linha de produtos que aborda funcionalidades diferentes em um domínio comum.

    Ela fornece uma base para gerenciamento de projeto.

    Planejamento e formação de equipe estão organizados de acordo com os principais componentes. Decisões estruturais fundamentais são tomadas por uma equipe pequena e coesa de arquitetura. Elas não são distribuídas. O desenvolvimento é dividido entre um conjunto de equipes pequenas, cada uma sendo responsável por uma ou várias partes do sistema.


Desenvolvimento Baseado em Componentes


Um componente de software pode ser definido como um pedaço não-trivial de software, um módulo, um pacote ou um subsistema, sendo que todos desempenham uma função clara, possuem uma fronteira clara e podem ser integrados em uma arquitetura bem definida. É a realização física de uma abstração do design.

Os componentes vêm de diferentes lugares:

    Ao definir uma arquitetura muito modular, você identifica, isola, projeta, desenvolve e testa componentes bem formados. Esses componentes podem ser testados individualmente e gradualmente integrados para formar o sistema inteiro.
    Além disso, alguns desses componentes podem ser desenvolvidos para serem reutilizáveis, especialmente os componentes que fornecem soluções comuns para uma ampla variedade de problemas comuns. Esses componentes reutilizáveis, que podem ser maiores que apenas conjuntos de utilitários ou de bibliotecas de classes, formam a base de reutilização dentro de uma organização, aumentando a produtividade e a qualidade geral do software.
    Mais recentemente, o advento das infra-estruturas de componentes comercialmente bem-sucedidas, como CORBA, a Internet, ActiveX e JavaBeans, desencadeou uma indústria completa de componentes desenvolvidos internamente e adquiridos prontos para serem usados para vários domínios, permitindo comprar e integrar componentes, em vez de desenvolvê-los internamente.

O primeiro ponto na lista precedente explora os conceitos antigos de modularidade e de encapsulamento, tornando ainda mais importantes os conceitos subjacentes à tecnologia orientada a objetos. Os últimos dois pontos da lista alteram o desenvolvimento de software da programação: de uma linha por vez para a composição do software através da montagem de componentes.

O RUP suporta desenvolvimento baseado em componentes destas maneiras:

    A abordagem iterativa permite identificar componentes progressivamente e decidir quais desenvolver, quais reutilizar e quais comprar.
    O foco na arquitetura de software permite montar a estrutura, os componentes e como eles se integram, incluindo os padrões e os mecanismos fundamentais através dos quais eles interagem.
    Conceitos como pacotes, subsistemas e camadas são utilizados durante a disciplina Análise e Design para organizar componentes e especificar interfaces.
    Os testes são primeiramente organizados em componentes e, em seguida, em conjuntos maiores de componentes integrados.

Referências para a Elaboração do Post:

http://www.guiafar.com.br/portal/index.php/pt/artigos/tecnologia-da-informacao/108-rup

http://www.wthreex.com/rup/manuals/intro/im_bp3.htm

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

 

Melhores Práticas: Desenvolvimento Iterativo

O que é o Desenvolvimento Iterativo? 

Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que consiste em várias iterações. Uma iteração incorpora um conjunto quase sequencial de atividades em modelagem de negócios, requisitos, análise e design, implementação, teste e implantação, em várias proporções, dependendo do local em que ela está localizada no ciclo de desenvolvimento. 

As iterações nas fases de iniciação e de elaboração se concentram nas atividades de gerenciamento, requisitos e design. As iterações na fase de construção se concentram no design, na implementação e no teste. E as iterações na fase de transição e concentram no teste e na implantação. A programação de uma iteração deve ser considerada fixa e o escopo do conteúdo da iteração gerenciado ativamente para atender a essa programação.

Por que Desenvolver Iterativamente? 

Todos os projetos têm um conjunto de riscos envolvidos. Quanto mais cedo você puder verificar que evitou um risco no ciclo de vida, mais precisos serão seus planos. Muitos riscos nem são descobertos até que você tente integrar o sistema. É impossível prever todos eles, por mais experiente que seja a equipe de desenvolvimento.

Em um ciclo de vida iterativo, a seleção do incremento a ser desenvolvido em uma iteração é feita com base em uma lista dos principais riscos. Como a iteração produz um executável testado, você poderá verificar os riscos diminuiram.

Vantagens de uma Abordagem Iterativa 

Geralmente, uma abordagem iterativa é superior a uma abordagem linear ou em cascata, por vários motivos.

• Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente.
• As táticas e os requisitos variáveis são acomodados. 
• A melhoria e o refinamento do produto são facilitados, resultando em um produto mais robusto.
• As organizações podem aprender a partir dessa abordagem e melhorar seus processos. 
• A capacidade de reutilização aumenta.

Uma vez, um cliente disse: "Com a abordagem em cascata, tudo parece bem até quase no final do projeto; às vezes, até a metade da integração. Aí, tudo desmorona. Com a abordagem iterativa, é muito difícil esconder a verdade durante muito tempo."

Geralmente, os gerentes de projeto resistem à abordagem iterativa, pois consideram-na um infindável refinamento. No Rational Unified Process (RUP), a abordagem interativa é muito controlada; o número, a duração e o objetivo das iterações são planejados. As tarefas e as responsabilidades dos participantes são definidas. São capturadas medidas de progresso objetivas. Ocorre algum retrabalho de uma iteração para a outra, mas isso também é cuidadosamente controlado.

Diminuição de riscos

Uma abordagem iterativa permite que você diminua os riscos mais cedo, pois muitos deles são descobertos somente durante a integração. Durante a iteração inicial, você verifica todas as  disciplinas, considerando muitos aspectos do projeto: ferramentas, softwares desenvolvidos internamente e adquiridos prontos para serem usados, habilidades das pessoas e assim por diante. Pode ser que riscos aparentes demonstrem que não são riscos, e riscos novos e inesperados aparecerão.

Acomodação de mudanças

A abordagem iterativa permite que você considere os requisitos variáveis, já que eles normalmente serão alterados durante o processo.

Forçar os usuários a aceitarem o sistema como o imaginaram originalmente está errado. Eles mudam de idéia porque o contexto está sendo alterado; eles aprendem mais sobre o ambiente e a tecnologia e enxergam uma demonstração intermediária do produto durante o seu desenvolvimento.

Busca de melhor qualidade 

Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os erros são corrigidos após várias iterações. As falhas iniciais são detectadas conforme o produto amadurece, durante as iterações iniciais. Os gargalos de desempenho são descobertos e podem ser reduzidos, em vez de aparecerem na véspera da liberação.

Aumento de reutilização 

O uso de uma abordagem iterativa facilita o aproveitamento dos produtos desenvolvidos internamente e adquiridos prontos para serem usados. Você terá várias iterações para selecioná-los, integrá-los e confirmar que eles são adequados à arquitetura.

Referência Ao Post:

http://www.wthreex.com/rup/manuals/intro/im_bp1.htm

http://www.wthreex.com/rup/OpenUP/index.htm

Fase de Construção, Fase de Transição

 

Fase de Construção

          Nesta fase , começa o desenvolvimento físico do software, produção de códigos, testes alfa. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema, também  é preciso esclarecer os requisitos restantes bem como gerenciar os recursos de controle de operações para otimizar custos, programações e qualidade.

Objetivos

• Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A palavra chave é eficiência.
• Disponibilizar as versões úteis (alfa, beta e etc) com rapidez. Os testes ALFA são realizados durante a fase de Construção.
• Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades.
• Verificar e decidir se o software está pronto para implantação. 
• Atingir a qualidade adequada com rapidez e eficiência.

   

Artefatos

• O Sistema  - O próprio sistema executável, pronto para iniciar os testes beta.

• Plano de Implantação - guia a equipe de implantação e transição para eles disponibilizarem o software. Essa é apenas uma versão inicial do plano, as versões finais são feitas na Transição. Em projetos menores o Plano de Implantação pode estar embutido no Plano de Desenvolvimento de Software.

• Conjunto de Testes - Testes implementados e executados para validação e estabilidade das versões (releases)

• Modelo de Implementação - Expandido a partir daquele criado durante a fase de elaboração; todos os componentes criados no final da fase de construção.

• Materiais de Treinamento - Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso.  Poderá ser necessário se o sistema tiver um forte aspecto de interface de usuário.

• Plano de Iteração - Plano de iteração para a fase de transição concluído e analisado.

• Modelo de Design - Atualizado com novos elementos de design identificados durante a conclusão de todos os requisitos.

• Caso de Desenvolvimento - Refinado com base na experiência inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessários para dar assistência à equipe de transição já estará posicionada.

• Ferramentas - As ferramentas usadas para dar suporte ao trabalho de Construção são instaladas.

• Modelo de Dados - Atualizado com todos os elementos necessários para suportar a implementação persistente (por exemplo, tabelas, índices, etc.).

Atividades Básicas

• Gerenciamento de recursos, otimização de controle e processo
• Desenvolvimento completo do componente e teste dos critérios de avaliação definidos
• Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão

 

Marco: Capacidade Operacional Inicial 

      O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta.Quando chegamos aqui podemos nos perguntar se:

• Os modelos de Análise e Design estão estáveis?
• Resolvemos todos os problemas de design?
• Abordamos todos os casos de uso?
• Glossário e SAD estão atualizados?

Fase de Transição

 Nesta fase ocorre a entrega do software ao usuário. 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.

Objetivos

• Validar o novo sistema em confronto com as expectativas do usuário treinamento de usuários e equipe de manutenção
• Implantação do sistema
• Correção de erros, melhoria no desempenho e na usabilidade
• Avaliação das baselines de implantação tendo como base a visão completa e os critérios de aceitação para o produto
• Obtenção de auto-suportabilidade do usuário
• Obtenção do consentimento dos envolvidos de que as baselines de implantação estão completas
• Obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão

 Artefatos
   

Artefatos Básicos (em ordem de importância)	Estado no marco
O Build do Produto	Concluído de acordo com os requisitos do produto. O produto final deve ser utilizável pelo consumidor.
Notas de Release	Concluídas.
Artefatos de Instalação	Concluídos.
Material de Treinamento	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.
Material de Suporte para o Usuário Final	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.

fonte:http://www.wthreex.com/rup/

Atividades básicas

• Executar planos de implantação
• Finalizar o material de suporte para o usuário final
• Testar o produto liberado no local do desenvolvimento
• Criar um release do produto
• Obter feedback do usuário
• Ajustar o produto com base em feedback
• Disponibilizar o produto para os usuários finais

Marco: Release do Produto

No fim na fase de transição está o quarto marco mais importante do projeto, o Marco do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase de iniciação do próximo ciclo. O Marco do Release do Produto é o resultado da conclusão com êxito de Atividade: Revisão da Aceitação do Projeto. Os critérios básicos de avaliação para a fase de transição envolvem as respostas para estas questões:

• O usuário está satisfeito?
• As despesas reais com recursos são aceitáveis se comparadas com as planejadas?

No Marco do Release do Produto, o produto está em produção e o ciclo de manutenção posterior ao release inicia. Isso pode envolver o início de um novo ciclo ou de algum release de manutenção adicional.

Fontes:

• http://infoblogs.com.br/view.action?contentId=40213&RUP-A-Importancia-dos-Marcos.html
  
• http://www.wthreex.com/rup/portugues/index.htm
• http://brunomarota.blogspot.com.br/2012/06/rup-para-concursos-parte-6-fase-de.html
• http://www.infoescola.com/engenharia-de-software/rup/
• http://tec4rup.wordpress.com/2010/05/13/rup-fases/

As fases do RUP - parte 1 (concepção e elaboração)

As fases do RUP

O ciclo de vida de software do RUP é dividido em quatro fases sequenciais  cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento. Cada passagem pelas quatro fases produz uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subsequentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante.

Vamos agora falar sobre as duas fases iniciais do RUP: As fases de Concepção e de Elaboração.

Fase de Concepção

Objetivos

A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir.

Os objetivos principais da fase de iniciação incluem:

• Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto;
•  Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design;
•  Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos;
• Estimar o custo geral e a programação para o projeto inteiro;
• Estimar riscos em potencial (as origens de imprevistos);
• Preparar o ambiente de suporte para o projeto.

Atividades básicas

• Formular o escopo do projeto;
• Planejar e preparar um caso de negócio;
• Sintetizar uma possível arquitetura;
• Preparar o ambiente para o projeto.

Marco: Objetivos do Ciclo de Vida

O Marco de Objetivos do Ciclo de Vida avalia a viabilidade básica do projeto.

Fase de Elaboração

Objetivos

A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

Os objetivos primários da fase de elaboração incluem:

• Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento;
• Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto;
•  Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto;
•   Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos descartados para diminuir riscos específicos como:
•    Trocas de design/requisito;
•    Reutilização de componentes;
• Possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais.
•  Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo;
•  Estabelecer um ambiente de suporte;
•  Configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Atividades básicas      

•  Definir, validar e criar a baseline da arquitetura com rapidez e eficiência;
•  Refinar a Visão, com base nas informações novas obtidas durante a fase;
•  Criar planos de iteração detalhados e baselines para a fase de construção;
•  Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento;
• Refinar a arquitetura e selecionar componentes.

Marco: Arquitetura do Ciclo de Vida

O marco Arquitetura do Ciclo de Vida estabelece uma baseline gerenciada para a arquitetura do sistema e permite o escalonamento da equipe do projeto na fase de Construção.

RUP - Linhas Mestras - Uso de Software de Modelos Visuais, Verificação da qualidade do software, Gestão e Controle de Mudanças do Software

 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 indíviduos 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 línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.


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 indíviduos 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 línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.

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.


Gestão e Controle de Mudanças do Software

Em todos os projectos de software a mudança é inevitável. O RUP define métodos para controlar e monitorizar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisiveis, 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.


Fonte:
http://www.guiafar.com.br/portal/index.php/pt/artigos/tecnologia-da-informacao/108-rup