Princípios do RUP

Objetivo

    Tem como objetivo garantir a produção de software de alta qualidade que está de acordo com as necessidades dos seus usuários finais com um cronograma e custo previsível.

Outros métodos:

• Cleanroom
• Métodos Ágeis

1. Scrum
2. XP(Extreme Programming)
3. FDD (Feature Driven Development)
4. Open UP

Melhores Práticas

Desenvolvimento Interativo e Incremental
    
    O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja, substitui o modelo clássico de desenvolvimento em cascata para uma abordagem um pouco mais dinâmica, dividida em iterações, onde, dentro de cada iteração, teremos a execução de cada uma de suas disciplinas, em proporção de acordo com a fase do projeto.

 Gerenciamento de Requisitos
    
    O Gerenciamento de requisitos no RUP está 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.

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.

Modelagem Visual

    O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML para ilustrar os processos em ação. A UML é usada para modelagem de Casos de Uso, diagrama de classes e outros objetos.

Verificação contínua da qualidade

    O RUP ajuda no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os membros da equipe.

Gerenciamento de Mudanças

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

Principais Características

1. Interativo e Incremental
2. Dirigido por Casos de Uso
3. Centrado na Arquitetura
4. Orientado a Objetos
5. Tratamento de Risco

O ciclo de vida de um sistema consiste em quatro fases:

1. Concepção: Definição do escopo do projeto.
2. Elaboração: Definição dos requisitos e arquitetura.
3. Construção: Desenvolvimento do sistema.
4. Transição: Implantação do sistema.

Disciplinas do RUP

1. Modelagem do Negócio
2. Requisitos
3. Análise e Projeto
4. Implementação
5. Testes
6. Implantação
7. Gerenciamento e Planejamento
8. Gerência de Configuração
9. Ambiente 

Referência Bibliográfica
RUP - Rational Unified Process, http://www.guiafar.com.br/portal/index.php?option=com_content&view=article&id=108:rup&catid=43:tecnologia-da-informacao&Itemid=169&lang=pt.

Referência Bibliográfica

 Charbonneau, Serge.Software Project Management - A Mapping between RUP and the PMBOK.developerWorks. Publicação: 03/05/2004. Acesso em: 10/09/2011.32p. Disponível em:http://www-106.ibm.com/developerworks/rational/library/4721.html

BARROS M.O., BESSA A.T.  Integração entre o PMBOK e RUP. Rio de Janeiro: UNIRIO; Dezembro de 2009. Relatórios Técnicos do DIA/UNIRIO, No. 0026/2009.

CAMPOS L.M.L., LIMA A.S. Gerenciamento de Projetos de Desenvolvimento de Software com o RUP e o PMBOK, 2009.

Comparativo

Como pudemos ver, as metodologias parecem ter muito em comum, não é?
Comparamos elas sob alguns focos:

Como vimos,  RUP oferece uma abordagem normativa para padronização e melhores práticas em engenharia de software, e o PMBOK oferece uma abordagem descritiva para a uniformização de melhores práticas em  projeto de gestão.

Mas eles são compativeis?

Ambas as metodologias são iterativas e não devem ser tratadas como um processo único e não repetitivo. Pelo contrário, os grupos de processos do PMBOK ou as fases do RUP devem ser revisados algumas vezes ao longo de todo o ciclo de vida do projeto, sendo assim, eles têm foco na melhoria contínua em seus grupos e fases.

Sob outro foco, os processos do PMBOK foram comparados com as nove disciplinas do RUP.
Contudo, alguns processos de gerenciamento de projetos do PMBOK não se enquadraram neste cruzamento; entretanto, são fundamentais para o bom andamento de um projeto. Esse mesmo entendimento é válido para o RUP, onde a integração de algumas disciplinas não foi possível, em decorrência desta metodologia ser voltada à construção de software e obrigatórias para este tipo de projeto.

Foram classificados os processos de gerenciamento de projetos versus as disciplinas em ambas as metodologias como “Atividades Customizadas”.
As disciplinas do RUP “Análise e Design”, “Implementação”, “Teste”, “Implantação” e “Ambiente” não foram apresentadas em decorrência da ausência de cruzamento com os processos de gerenciamento de projetos do PMBOK, porém, obrigatórias em um projeto de construção de software. Assim como no RUP,
alguns processos fundamentais do PMBOK tornaram ausentes. A próxima figura  retrata os processos de gerenciamento de projetos no PMBOK ausentes nessa integração e fundamentais para o bom andamento do projeto, num total de 9 atividades.

O PMP não fornece padrões de documentação, portanto os
padrões do RUP poderão ser utilizados (é importante lembrar que existem outros padrões para documentação utilizando o PMBOK um exemplo disso é o grupo TenStep (www.tenstep.com) que possui uma biblioteca on-line via Internet de padrões de documentação que podem ser utilizados para este fim).

Conclusão
Comparando o  RUP e o PMBOK, não exitem incompatibilidades fundamentais entre os dois.
Como já foi resaltado, são usados termos diferentes para designar conceitos similares. Vimos também que não há nada no  RUP que contradiga as praticas do PMBOK e vice-versa.

Apresentação

Introdução ao RUP

O que é RUP?
O RUP, abreviação de Rational Unified Process (ou Processo Unificado Racional), é um processo de engenharia de software criado pela Rational Software Corporation e adquirida posteriormente pela IBM em 2003. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de 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 utiliza a Linguagem Unificada de Modelagem UML para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG e ter se tornado o padrão empresarial para a modelagem orientada a objetos. Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e grande porte.
 
A arquitetura básica do RUP se divide em duas dimensões (figura 01):

Figura 01

Horizontal: Representam o tempo de vida de um projeto, os aspectos do ciclo de vida do processo de engenharia de um sistema, de acordo com o decorrer do projeto. Essa dimensão demonstra o aspecto dinâmico do processo, suas fases, iterações e milestones.

Vertical: Representam os grupos de atividades lógicas que são realizadas durante o decorrer do tempo. Essa dimensão demonstra o aspecto estático do processo, que será composto por disciplinas, atividades, fluxos, artefatos e papéis.

O RUP incorpora as melhores práticas de desenvolvimento de software de acordo com as causas de sucesso apontadas pela indústria de software:
1) Desenvolvimento iterativo;
2) Gerenciamento de requisitos;
3) Arquitetura baseada em componentes;
4) Modelo visual de software;
5) Verificação contínua da qualidade de software;
6) Controle de mudança de software;

Desenvolvimento Interativo e Incremental

O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja, substitui o modelo clássico de desenvolvimento em cascata para uma abordagem um pouco mais dinâmica, dividida em iterações, onde, dentro de cada iteração, teremos a execução de cada uma de suas Disciplinas (figura 02), em proporção de acordo com a Fase do projeto.

Figura 02

Arquitetura e Casos de Uso

Em sua essência, dizemos que o RUP é “centrado na arquitetura” e “dirigido por casos de uso”. Isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de softwares (ou seja, os aspectos relacionados aos maiores riscos de um projeto de desenvolvimento) estão intimamente ligados à arquitetura, visto que ele mesmo define arquitetura como “tudo o que sobra quando você não pode mais tirar nada mais do sistema, mas ainda continua entendendo-o e explicando como ele funciona”. Sendo assim, devemos então tratar como centro (core) do nosso desenvolvimento, nossos requisitos arquiteturais do projeto.

Além disso, quando dizemos que o RUP é dirigido por casos de uso, mostramos que para solucionarmos um problema (o grande e único motivo para a criação de um sistema), devemos primeiro entender da melhor forma possível esse problema, dividi-lo e organizá-lo de uma maneira que todos os envolvidos no projeto de construção desse sistema (todos os stakeholders) possam compreender a situação. Para realizar essas atividades, o RUP encontra na UML a solução: Use Cases e seus atores.

Fases

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.

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://www.guiafar.com.br/portal/index.php?option=com_content&view=article&id=108%3Arup&catid=43%3Atecnologia-da-informacao&Itemid=169&lang=pt 
http://www.wthreex.com/rup/portugues/index.htm http://www.infoescola.com/engenharia-de-software/rup/
http://www.baguete.com.br/artigos/731/adilson-taub-junior/04/11/2009/rational-unified-process-rup

O que é PMI?

O PMI(Project Management Institute) é uma associação sem fins lucrativos que reúne profissionais do mundo inteiro que trabalham em gerenciamento de projetos, com mais de um milhão de membros e associados em mais de 185 países. O PMI defende o uso de boas práticas para o gerenciamento de projetos, apoiado pelos padrões internacionalmente reconhecidos e o extenso programa de pesquisas.

O PMBOK Guide^® é uma de suas publicações e apresenta as boas práticas para gerenciamento de projetos geralmente reconhecidas pelos profissionais da área.

Site do PMI: http://www.pmi.org

GT1 - Plano do Projeto SIDEP