O Processo RUP
Fases
Fase de Concepção / Iniciação: Nesta fase do RUP são abrangidas as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, assim como suas origens e provisões, 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: Nesta fase é criada a baseline da arquitetura do sistema, abrangendo 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?" deverão ser esclarecidas nesta fase, onde a estabilidade da arquitetura do projeto devera ser desenvolvida e avaliada através de um ou mais protótipos de arquitetura
Fase de Construção: É a fase da conclusão do desenvolvimento, ou aquisição dos componentes de Software com base na arquitetura baseline elaborada na fase anterior. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento e gerenciamento de componentes e outros recursos do sistema e no controle de operações, afim de otimizar os lucros, programação e a qualidade . É na fase de Construção que a maior parte de codificação ocorre.
Fase de Transição: É a fase com objetivo de entrega do software ao usuário final e a fase de testes e correções com base nos feedbacks do usuario. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final através de atividades que incluem o treinamento dos usuários finais, testes da versão beta do sistema, visando garantir que o software possua o nível adequado e aceitável de qualidade.
Disciplinas
Uma disciplina é um conjunto de atividades relacionadas a uma área de interesse importante em todo o projeto. O principal objetivo do agrupamento de atividades em disciplinas é ajudar a compreender o projeto a partir de uma perspectiva em cascata tradicional . Por exemplo, geralmente é mais comum executar determinadas atividades de requisitos em coordenação direta com as atividades de análise e de design. A separação dessas atividades em disciplinas distintas facilita a compreensão, mas dificulta a programação.
Modelagem de Negócios: Definimos a arquitetura de negócios como um conjunto organizado de elementos com relacionamentos transparentes uns com os outros que, juntos, formam um todo definido pela correspondente funcionalidade. Os elementos representam a estrutura organizacional e comportamental de um sistema e mostra abstrações dos principais processos e estruturas do negócio. Nesta fase é criado o Organograma da organização dos processos, a elaboração da visão estrutural da organização, da cultura da mesma, assim como o desenvolvimento das habilidades da equipe e na definição dos mecanismos e padrões e a serem aplicados.
Requisitos: 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
Análise e Design: Mostra como o sistema vai ser realizado, de forma que o mesmo execute as tarefas e funções especificadas nas descrições dos casos de uso criado, e que cumpra todas as necessidades preestabelecidas, e estável quando ocorrem mudanças dos requisitos funcionais
Implementação: Define a organização do código , em termos de subsistemas de implementação organizadas em camadas, implementa classes e objetos em termos de componentes e realiza testes nos componentes desenvolvidos como unidade, alem de integrar os resultados produzidos em sistemas executáveis.
Teste: Verifica a interação entre objetos, a integridade adequada de todos os componentes do software e se todos os requisitos foram implementados.Também identifica e garante que os defeitos sejam corrigidos antes da implantação do software, re-análisados e encerrados. 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
Implantação: Sistemas são realizados através da aplicação de componentes. O processo descreve como a reutilização de componentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o sistema mais fácil de manter e aumentar as possibilidades de re-utilização.Autor: Anderson De Vasconcelos Sant'Ana
Artigos Relacionados
Processo De Teste De Software
Estratégia De Testes
A Essencialidade Da Engenharia De Software
Engenharia De Componentes
Engenharia De Software
O Processo De Levantamento De Requisitos Na Modelagem De Sistemas De Informação.
Engenharia De Software - Visão Geral