Bom pessoal, o post anterior foi falando sobre o MVC que é direcionado para parte de programação mesmo. Já o RUP abrange todas as etapas para a criação do software, é a Engenharia do Software.
O RUP foi criado pela empresa Rational Software Corporation desenvolveu um framework de processos com a finalidade de mostrar como fazer um processo de engenharia de software.
A figura abaixo representa, nas linhas, o que se convencionou chamar disciplinas, isto é, o que será feito durante o desenvolvimento do software. Nas colunas, estão as fases do desenvolvimento. As partes coloridas, na interseção, representam a quantidade de esforço de cada disciplina a ser realizado durante cada uma das fases:
Uma iteração significa percorrer todas as disciplinas durante uma fase ou parte dela. Por estas práticas o RUP é um processo de desenvolvimento iterativo e incremental, orientado a objetos, com enfoque em casos de uso e análise de risco. O RUP, desenvolvido para ser aplicável a uma grande classe de projetos diferentes, pode ser considerado como um framework genérico para processos de desenvolvimento. Isto significa que para ser usado eficientemente ele deve ser configurado para a empresa ou para um projeto.
O RUP é composto por 4 fases (concepção, elaboração, construção e transição) cada uma com objetivos específicos. Na fase de concepção, deve-se estabelecer o escopo e a viabilidade econômica do projeto. Na elaboração, o objetivo é eliminar os principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. Na fase de construção, um produto completo é desenvolvido de maneira iterativa até que esteja pronto para ser passado aos usuários, o que ocorre na fase de transição, onde uma versão beta do sistema é disponibilizada. No final da transição pode ser iniciado um novo ciclo de desenvolvimento para a evolução do produto, o que envolveria todas as fases novamente.
Todas as fases têm ao final um marco (milestone) de verificação de quais objetivos da fase foram alcançados.
As disciplinas representam o que deve ser feito pelos responsáveis em termos de atividades e artefatos. O RUP fornece modelos (templates) para cada artefato e roteiros (guidelines) para a execução de suas atividades
Processo de Engenharia de Software na visão do RUP:
Uma iteração significa percorrer todas as disciplinas durante uma fase ou parte dela. Por estas práticas o RUP é um processo de desenvolvimento iterativo e incremental, orientado a objetos, com enfoque em casos de uso e análise de risco. O RUP, desenvolvido para ser aplicável a uma grande classe de projetos diferentes, pode ser considerado como um framework genérico para processos de desenvolvimento. Isto significa que para ser usado eficientemente ele deve ser configurado para a empresa ou para um projeto.
O RUP é composto por 4 fases (concepção, elaboração, construção e transição) cada uma com objetivos específicos. Na fase de concepção, deve-se estabelecer o escopo e a viabilidade econômica do projeto. Na elaboração, o objetivo é eliminar os principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. Na fase de construção, um produto completo é desenvolvido de maneira iterativa até que esteja pronto para ser passado aos usuários, o que ocorre na fase de transição, onde uma versão beta do sistema é disponibilizada. No final da transição pode ser iniciado um novo ciclo de desenvolvimento para a evolução do produto, o que envolveria todas as fases novamente.
Todas as fases têm ao final um marco (milestone) de verificação de quais objetivos da fase foram alcançados.
As disciplinas representam o que deve ser feito pelos responsáveis em termos de atividades e artefatos. O RUP fornece modelos (templates) para cada artefato e roteiros (guidelines) para a execução de suas atividades.
Conceitos chaves do rup:
Processo de Engenharia de Software na visão do RUP:
Como medir o Projeto?
Muitas métricas diferentes podem ser de valor para um processo iterativo-incremental. Apresentaremos como exemplo um conjunto de sete métricas consideradas chaves para qualquer projeto de software e que demonstraram serem úteis na prática. Estes indicadores têm a virtude de serem simples, fáceis de coletar, fáceis de interpretar e difíceis de mal interpretar.
Três são indicadores de gerenciamento e quatro são indicadores de qualidade.
Indicadores de Gerenciamento
1.Trabalho e Progresso. (Trabalho realizado ao longo do tempo);
2.Orçamento e Despesas. (Gastos ao longo do tempo);
3.Alocação e Rotatividade da Equipe. (Mudança de pessoal ao longo do tempo).
Indicadores de Qualidade
1.Fluxo de Mudanças e Estabilidade. (Fluxo de alterações ao longo do tempo);
2.Fragmentação e Modularidade. (Fragmentação média por mudança ao longo do tempo);
3.Retrabalho e Adaptabilidade. (Retrabalho médio por mudança ao longo do tempo);
4.Tempo Médio entre Falhas. (Taxa de defeitos ao longo do tempo).
Ao coletar estes indicadores ao longo do tempo devemos escolher a abrangência da coleta, isto é, definir se estaremos coletando por iteração, por módulo do sistema, por equipe, etc. Recomendamos, no mínimo, a coleta por iteração para acompanhamento do projeto e a coleta por módulo para exame da qualidade do produto.
Práticas de Desenvolvimento
As melhores práticas apresentadas aqui são abordagens comprovadamente eficazes no meio comercial que, quando usadas em conjunto, atingem diretamente a raiz dos problemas do desenvolvimento de software. São consideradas melhores práticas não apenas porque podem ser quantificadas precisamente, mas, principalmente, porque são amplamente utilizadas em empresas de sucesso da indústria de software.
Desenvolver Software Iterativamente
O desenvolvimento clássico de software é baseado no modelo em cascata que constitui em jogar os riscos para serem tratados posteriormente o que acarreta aumento de custo para se concertar os erros de fases anteriores.
Com o desenvolvimento iterativo a identificação dos riscos de projeto é realizada mais cedo no ciclo de vida enquanto ainda é possível atacá-los e tratá-los de maneira eficiente em um curto período de tempo. As soluções oferecidas pelo desenvolvimento de software iterativo:
1.Riscos amenizados no ciclo de vida, uma vez que os elementos são integrados progressivamente;
2.Mudanças de requisitos e táticas, de desenvolvimento e abordagem, são mais facilmente aceitas;
3.O refinamento do produto é realizado mais rapidamente resultando em um produto mais eficiente;
4.Aumenta a capacidade de reuso.
Gerenciar Requisitos
O Gerenciamento de Requisitos busca elencar, documentar, organizar e controlar mudanças ao longo do projeto. Algumas dificuldades na definição de requisitos:
1.Alguns requisitos não são óbvios, podendo vir de várias fontes;
2.Nem sempre estão bem escritos;
3.O número de requisitos pode ser incontrolável, o que dificulta o gerenciamento;
4.Requisitos podem sofrer alterações;
Usar Arquitetura Baseada em Componentes
A arquitetura baseada em componentes tem por objetivo a diminuição do tempo e do custo de um projeto e promove reuso. O foco principal das iterações iniciais do processo é produzir e validar a arquitetura do software, cujo desenvolvimento inicial se apresenta na forma de um protótipo de arquitetura executável para, posteriormente, tornar-se o sistema final.
Modelar Softwares Visualmente
Modelar Softwares Visualmente compreende a utilização de textos e notações de projeto, como a UML, para apresentar a modelagem de um sistema. Facilita a comunicação entre a equipe de projeto e favorece a implementação do sistema. Vantagens da utilização da Modelagem Visual:
1.Explora e compara alternativas de projeto com um baixo custo;
2.Forma uma base para a implementação;
3.Captura requisitos precisamente;
4.Decisões de comunicação sem ambigüidade.
Verificar Qualidade do Software Continuamente
A verificação contínua da qualidade pode ser feita pela produção de um protótipo, utilizando os artefatos completados ao final de cada iteração. Em uma abordagem mais tradicional o teste de integração de um software seria realizado tardiamente no ciclo de vida.
Controlar Mudança
O controle de mudanças apresenta-se nas atividades de controle de arquivos, equipe do projeto, artefatos, espaço de trabalho, desenvolvimento paralelo, integração, entre outras. O controle de mudanças oferece soluções para as raízes dos problemas da construção de um software, como:
1.Um fluxo de trabalho bem definido e que pode ser repetido para requisição de mudanças;
2.Estatísticas de requisição de mudanças servem como métricas para o desenvolvimento de um software futuro;
3.A propagação de mudança é controlável e calculável.
Leonwag's Blog 