Metodologia RUP

ANHANGUERA EDUCACIONAL

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Anderson Luiz F. A. M. Nunes – 998452947

Diego Tavares Mendes – 9092484310

Fernando de Souza Valadares - 8868410053

Thamer F. Fortini - 9894553968

PROJETO INTERDISCIPLINAR I: Metodologia RUP

Belo Horizonte

2014

1 – INTRODUÇÃO

Com o intuito de melhorar a qualidade dos softwares e o tempo de implementação, foram criadas várias metodologias para que isso fosse possível e uma delas é a metodologia RUP.

2 – SOBRE A METODOLOGIA

O RUP, ou Rational Unified Process (Processo Racional Unificado), é um processo de Engenharia de Software que fornece técnicas a serem seguidas pelos membros de uma equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.

Sendo ele um processo iterativo, ou seja, que se repete quantas vezes forem necessárias de acordo com o número de requisitos e/ou etapas para se desenvolver um sistema, ele tem o cuidado de eliminar os riscos antecipadamente e durante todo o processo de desenvolvimento. O RUP também oferece uma estrutura de processo customizável para a engenharia de software e por esta razão ele pode ser facilmente adequado para projetos de pequeno, médio e grande porte.

Além disso, é uma metodologia adequada para trabalhos em equipe pelo fato de haver uma preocupação maior com a qualidade sendo possível entregar algo concreto e de valor para o cliente.

Para ilustrar as etapas do processo de desenvolvimento desta metodologia, tem-se a figura 1 abaixo:

2.1 - Fases do RUP

Fase de concepção / Iniciação: Esta fase abrange as tarefas de comunicação entre o planejamento e o cliente, é feito um plano de projeto que avalia os possíveis riscos, as estimativas de custo e prazos, estabelecimento de prioridades, levantamento de requisitos do sistema e analisá-lo preliminarmente. Assim é definido entre as partes interessadas o escopo do projeto, sendo examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.

Fase de Elaboração: Abrange a Modelagem do modelo genérico do processo, esta fase tem como objetivo analisar de uma forma mais detalhada a análise do domínio do problema analisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Perguntas freqüentes como “Os custos são aceitáveis?” isso é definido nesta fase.

Fase de Construção: Fase na qual se desenvolve e/ou adquire os componentes de software, tem como principal objetivo a construção do sistema de software, e tem o foco no desenvolvimento de componentes e outros recursos do sistema. Fase também responsável pela maior parte da codificação.

Fase de Transição: Nesta fase ocorre a entrega do software ao usuário e a fase de testes, o objetivo desta fase é tornar o sistema disponível e compreendido ao usuário final,dentro desta fase incluem atividades como treinamento de usuários finais e também a realização de testes da versão beta para que se garanta que o mesmo possua um nível adequado de qualidade.

3 – VANTAGENS E DESVANTAGENS DA METODOLOGIA

3.1 - Vantagens

O RUP prova ser um processo de desenvolvimento robusto e bem definido, embora bastante complexo/trabalhoso para projetos de software de pequeno porte, ele pode ser bem aproveitado para projetos aonde é preciso manter registro constante do fluxo do projeto.

3.2 – Desvantagens

A metodologia é complexa e trabalhosa para projetos de pequeno porte onde há um investimento pesado em ferramentas de suporte além de possuir limitações na área de manutenção, gestão de pessoal, gestão de reutilização e testes e ainda deve contar com uma vasta experiência da equipe.

4 – COMPARATIVO COM O MODELO CASCATA

O modelo em cascata é um modelo de desenvolvimento de software seqüencial onde o desenvolvimento é visto como uma cascata, sempre fluindo para frente através das etapas de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo “cascata” é freqüentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce defendia uma abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata. Royce originalmente