Atividades durante o ciclo de vida:
-
Introdução
-
Atividades da Fase de Iniciação
-
Atividades da Fase de Elaboração
-
Atividades da Fase de Construção
-
Atividades da Fase de Transição
O desenvolvimento baseado em componentes é uma variação do desenvolvimento geral de aplicativos em que:
-
O aplicativo é montado a partir de componentes executáveis separados que são desenvolvidos e
implementados de modo relativo e independente um do outro, possivelmente por equipes diferentes.
-
É possível fazer upgrade do aplicativo em incrementos menores, fazendo upgrade apenas de alguns
componentes que constituem o aplicativo.
-
Os componentes podem ser compartilhados entre os aplicativos, criando oportunidades para reutilização,
mas também criando dependências entre projetos.
-
Apesar de não haver uma relação estrita com o fato de serem baseados em componentes, os aplicativos baseados em
componentes tendem a ser distribuídos.
Em toda esta página, "componente" é utilizado para referir-se a esses componentes desenvolvidos e implementáveis de
modo independente. No entanto, em qualquer outra parte no RUP, utilizaremos o termo "componente" no sentido mais geral,
descrito em Conceito: Componente e qualificaremos conforme necessário.
A adaptação do RUP (Rational Unified Process) para lidar com desafios de desenvolvimento com base em componentes é
discutido a seguir.
O fluxo de trabalho básico para a Fase de Iniciação é
aplicável, com as seguintes extensões ou variações:
Gerenciamento de Projeto
-
Atividade: Conceber Novo Projeto
-
O foco da Tarefa: Desenvolver Caso de Negócio é ajustado para
considerar que a utilização de componentes altera a estrutura do custo de desenvolvimento. Em especial, o custo
de desenvolvimento de componentes diminui, mas há um esforço maior para identificar componentes e garantir que
os componentes selecionados atendam aos requisitos.
-
Atividade: Planejar o Projeto
-
Na Tarefa: Planejar Fases e Iterações, o plano da fase de
Construção pode potencialmente mostrar a divisão do projeto em duas trilhas diferentes, porém paralelas: uma
que desenvolve os componentes específicos do aplicativo e específicos do domínio (organizados nas camadas
superiores da arquitetura - consulte Conceito: Divisão
em Camadas) e uma de componentes não específicos do aplicativo e não específicos do domínio, organizados em
camadas inferiores. Em alguns casos, os componentes reutilizáveis serão desenvolvidos por equipes de
desenvolvimento gerenciadas de modo independente. A decisão de introduzir caminhos paralelos é, em grande
parte, uma questão de equipe e de recursos introduzida por um desejo de gerenciar componentes reutilizáveis
como recursos valiosos, independentes dos aplicativos em que estiverem implementados.
Requisitos
Teste
Ambiente
-
Atividade: Preparar Ambiente para Projeto
-
Ao coletar e preparar diretrizes para o projeto, consulte Tarefa: Preparar Diretrizes para o Projeto para obter
detalhes, considere a estrutura específica de componentes e as restrições impostas por ela. As diretrizes
devem incluir como projetar e codificar utilizando a estrutura. Elas também devem fornecer orientação de teste
sobre como verificar a conformidade com ambos, a própria estrutura do componente e as interfaces
definidas entre os componentes.
O fluxo de trabalho básico para a Fase de Elaboração
é aplicável, com as seguintes extensões ou variações:
Requisitos
-
Atividade: Aperfeiçoar a Definição do Sistema
-
Tarefa: Detalhar os Requisitos de Software adicionalmente
focaliza os requisitos técnicos e não-funcionais e as restrições impostas nos componentes que são construídos
ou comprados. Os requisitos específicos não funcionais a serem considerados são: tamanho, desempenho, memória
ou espaço usado no disco, questões de licença em tempo de execução e restrições semelhantes que influenciarão a
seleção ou a criação do componente.
Análise & Design
-
Atividade: Componentes de Design
-
A Tarefa: Design do Subsistema refina ainda mais o design dos
componentes, identificando classes dentro do componente que fornecem o comportamento real do componente. Nos
primeiros estágios da fase de Elaboração, provavelmente há uma única classe, um tipo de 'proxy de
subsistema/componente' que atua como um stub para simular o comportamento do componente com finalidades de
criação de protótipo de arquitetura. Mais tarde, o comportamento dessa classe é distribuído para uma
colaboração de classes contidas no subsistema. Essas classes contidas são aperfeiçoadas na Tarefa: Design de Classe.
-
Atividade: Projetar o Banco de Dados
-
O foco na elaboração é garantir que a estratégia de persistência seja ajustável e que o design do banco de
dados e o mecanismo de persistência suportem os requisitos de taxa de transferência do sistema. Classes
persistentes são identificadas e mapeadas para o mecanismo de persistência. Os casos de uso intensivo de dados
são analisados para garantir que os mecanismos sejam ajustáveis. Em conjunto com as Atividades de Teste, o
mecanismo de persistência e o design do banco de dados são avaliados e validados.
Implementação
Teste
-
Atividades: Definir a Missão da Avaliação, Verificar a Abordagem do Teste, Testar e Avaliar, Alcançar Missão Aceitável, Melhorar os Ativos do Teste
O foco das atividades de teste na Elaboração é a validação da arquitetura. Para um sistema baseado em
componente, esse foco traduz-se em:
-
utilizar as interfaces entre componentes, para garantir que as fronteiras do componente sejam adequadas
-
maior concentração no teste de desempenho, especialmente nos testes de escala de desempenho, para garantir
que poderá suportar os volumes de transação previstos
É necessário avaliar também todas as suposições básicas existentes na estrutura do componente. Essas incluem,
em geral, a capacidade de ajuste e a taxa de transferência dos mecanismos de gerenciamento de persistência e
transação, em que suposições ocultas feitas pelo designer do mecanismo muitas vezes minam efetivamente a
arquitetura do aplicativo, se ela não entender essas suposições.
Gerenciamento de Projeto
-
Atividade: Planejar Próxima Iteração
Utilizando os subsistemas de implementação como 'unidades lógicas de responsabilidade', o trabalho de
construção pode ser particionado em duas ou mais "trilhas" paralelas: uma com foco na funcionalidade específica
do aplicativo e uma ou mais com foco em componentes genéricos, reutilizáveis. Isso, é claro, depende da
existência de recursos suficientes para obter esforços de desenvolvimento paralelos. A capacidade de dividir as
equipes de desenvolvimento e de trabalhar em paralelo depende inteiramente da estabilidade da arquitetura e,
mais especificamente, da qualidade e estabilidade das interfaces entre componentes. Um esforço concentrado na
fase de Elaboração permitirá essa divisão.
O fluxo de trabalho básico para a Fase de Construção
é aplicável, com as seguintes extensões ou variações:
Gerenciamento de Projeto
-
Atividade: Planejar Próxima Iteração
O planejamento da primeira iteração de construção foi descrito anteriormente, uma vez que ocorre no final da
elaboração. O planejamento de iteração contínua e a capacidade de dividir as equipes de desenvolvimento e de
trabalhar em paralelo dependem inteiramente da estabilidade da arquitetura e da qualidade e estabilidade das
interfaces entre componentes.
Análise & Design
-
Atividade: Aperfeiçoar a Arquitetura e Atividade: Componentes de Design
O foco da construção é a análise do restante dos casos de uso e a identificação de componentes apropriados e
colaborações de componentes que realizam os casos de uso. A arquitetura existente é expandida e concluída, e os
'comportamentos internos' do componente são totalmente projetados e implementados.
-
Atividade: Projetar o Banco de Dados
O foco da construção é a conclusão do design do banco de dados, garantindo que todas as classes persistentes
sejam suportadas pelo banco de dados e pelo mecanismo de persistência. Este trabalho é executado em paralelo e
iterativamente com o trabalho feito em Atividade: Aperfeiçoar a Arquitetura e Atividade: Componentes de Design. A organização ideal é a
integração das equipes de componentes, com coordenação entre as equipes sobre problemas de persistência, para
garantir um bom design do banco de dados.
Implementação
Teste
O teste de desempenho continua sendo importante, mas há um foco crescente no teste funcional. A abrangência da
funcionalidade, o teste de regressão da funcionalidade existente e a conformidade com as expectativas de desempenho
precisam ser tratados.
-
A liberação do produto no ambiente da web tende a ser incremental e contínua e com menos foco na
distribuição tradicional da mídia. O planejamento de release deve ser ajustado de acordo.
-
O suporte à produção é, cada vez mais, o foco da fase.
-
As atividades de conversão de dados são desempenhadas.
|
