Pacote de posts sobre o Processo Unificado

Meu esforço inicial neste canal de comunicação foi apresentar o Processo Unificado, um framework de apoio ao desenvolvimento de software. Foram apresentadas as cinco disciplinas e as quatro fases do processo.

Na realidade seria possível escrever posts mais detalhados e amplos, mas acredito que não seria o mais adequado para um canal deste tipo. A idéia principal é incentivar a leitura e o debate dos tópicos que formam este processo.

Pacote de posts:

Processos Iterativos de desenvolvimento de software
Princípios Fundamentais do Processo Unificado
A estrutura do Processo Unificado
A disciplina de Requisitos
A disciplina de Análise
A disciplina de Projeto
A disciplina de Implementação
A disciplina de Teste
A fase de Concepção
A fase de Elaboração
A fase de Construção
A fase de Transição

A partir de agora, discutiremos outros temas, como modelagem orientada a objetos! Espero que tenha contribuido, um abraço!

A fase de Transição

Consiste basicamente em entregar uma versão operacional do sistema ao cliente.

Deve-se preparar uma divulgação e uma documentação de usabilidade para o usuário final; ajustar o software no ambiente e, por fim, ministrar treinamentos que sejam necessários.

Como as disciplinas atravessam a fase

As cinco disciplinas podem ocorrer nesta fase, mas o Processo Unificado não se refere especificamente a este tópico. No momento em que o sistema atingir este ponto, ele funcionará comprovadamente.

Avaliação

A avaliação desta fase consiste basicamente em observar se os clientes não tiveram dificuldades na instalação e na usabilidade básica do sistema.

Nesta altura, o Plano de Projeto e os seis principais modelos devem estar finalizados. A documentação completa do processo de desenvolvimento deve ser armazenada e utilizada como base caso um novo ciclo seja necessário.

A fase de Construção

Neste momento do ciclo de vida pode-se dizer que apenas questões técnicas são tratadas. A modelagem, a codificação e os testes dos componentes marcam esta fase.

É a fase onde o Modelo de Implementação e o Modelo de Teste tendem a ser bastante trabalhados, consequentemente, é o momento onde os desenvolvedores e os testadores mais atuam.

É comum que o Modelo de Casos de Uso, o Modelo de Análise, o Modelo de Projeto e o Modelo de Instalação estejam concluídos, apesar de ainda serem refinados nesta fase com eventuais detalhes.

Terá sucesso e poderá ser considerada concluída quando se atinge uma maturidade considerável nos artefatos das disciplinas de Implementação e Teste.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Construção em termos de tarefas:

• Requisitos: Esta disciplina freqüentemente não é trabalhada nesta fase, os requisitos devem estar claros para todos na equipe.


• Análise: Esta disciplina também é pouco trabalhada nesta fase, a arquitetura candidata já cedeu espaço para uma mais sólida.


• Projeto: Refinar os artefatos relativos à arquitetura e à instalação do sistema.


• Implementação: Modelar e codificar os componentes.


• Teste: Verificar os componentes através dos diversos tipos de teste.

Avaliação

Existe apenas uma questão ao final desta fase: O sistema está pronto para ser entregue aos clientes? Caso a resposta seja negativa, será necessário adicionar uma iteração para os ajustes finais.

A fase de Elaboração

O núcleo desta fase é a busca por uma boa arquitetura. No post "Princípios Fundamentais do Processo Unificado" fica clara a preocupação deste processo em prover meios para alcançar altos graus de manutenibilidade, flexibilidade, expansibilidade e reuso.

Esta fase também é marcada pelo gradativo afastamento dos clientes e, conseqüentemente, pela gradativa aproximação de questões mais técnicas.

Lembrando que são as disciplinas que possuem artefatos associados e não as fases, é perfeitamente comum que alguns documentos produzidos com bastante intensidade na fase de Concepção sejam refinados nesta fase, como é o caso do documento de Requisitos Não-Funcionais, pertencente à disciplina de Requisitos.

Porém, de forma mais intensa que a disciplina de Requisitos, as disciplinas de Análise e Projeto são as mais evidentes. Ao longo da fase, espera-se que uma arquitetura candidata seja substituída gradativamente por uma arquitetura mais concreta, ou seja, uma fundação sólida para o sistema.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Concepção em termos de tarefas.

• Requisitos: Refinar os artefatos referentes aos requisitos funcionais e não-funcionais.


• Análise: Refinar os artefatos relativos à arquitetura candidata.


• Projeto: É a principal disciplina desta fase. As tarefas-chave são criar uma arquitetura sólida, tendo como base os diagramas produzidos na disciplina de Análise, e estruturar o cenário da instalação do sistema em componentes de hardware.


• Implementação: Iniciar, ainda que superficialmente, a modelagem de componentização de acordo como o que foi produzido na disciplina de Projeto.


• Teste: Necessária somente se algum componente tiver sido implementado, o que é pouco provável.

Avaliação

Existem algumas questões que auxiliam na avaliação da fase quando se imagina que está concluída:

• Todos entendem e concordam com os requisitos detalhados?


• Existe uma base arquitetônica sólida que possa evoluir à medida que os requisitos são explorados e mais funcionalidades são adicionadas no sistema?


• As estimativas de tempo e custo foram cumpridas?

Se as respostas satisfizerem à maioria dos interessados, a fase pode ser considerada concluída com êxito. Caso contrário, talvez o melhor seja acrescentar mais uma iteração a esta fase para aparar arestas e finalizar o que estiver pendente.

A fase de Concepção

Esta fase é caracterizada pela presença do cliente em entrevistas para que a equipe de desenvolvimento compreenda o domínio. Com base nesta compreensão, são identificados e selecionados os requisitos funcionais, em forma de casos de uso, e os requisitos não-funcionais.

A Concepção deve ser uma fase esclarecedora. Neste momento é fundamental o foco nas metas e nas necessidades dos usuários.

Terá sucesso e poderá ser considerada concluída quando se atinge uma maturidade considerável nos artefatos da disciplina de Requisitos. Desta forma, espera-se que esteja claro qual o sistema a ser construído.

Como as disciplinas atravessam a fase

Os pontos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Concepção em termos de tarefas.

• Requisitos: É a principal disciplina desta fase. As tarefas-chave são chegar a um acordo entre os interessados sobre o contexto do sistema, conforme expresso no Modelo de Domínio, e identificar os requisitos funcionais e não-funcionais.


• Análise: Elaborar, mesmo que de forma breve, uma arquitetura candidata.


• Projeto: Iniciar um esforço mental de unificação dos diagramas relativos à arquitetura candidata.


• Implementação: Frequentemente, nenhuma tarefa relativa a esta disciplina é realizada, a não ser que seja necessário criar um protótipo para satisfazer eventuais preocupações dos clientes.


• Teste: Esta disciplina só será relevante para verificar um possível protótipo que tenha sido criado na disciplina de Implementação.

Avaliação

Existem algumas questões que auxiliam na avaliação da fase quando se imagina que está concluída:

• Está claro o que está dentro e o que está fora do sistema?


• Os requisitos foram compreendidos e todos concordam com eles?


• Existe um esforço inicial de elaboração de uma arquitetura candidata?


• As estimativas de tempo e custo foram cumpridas?

Se as respostas satisfizerem à maioria dos interessados, a fase pode ser considerada concluída com êxito. Caso contrário, talvez o melhor seja acrescentar mais uma iteração a esta fase para aparar arestas e finalizar o que estiver pendente.

A disciplina de Teste

O objetivo fundamental é verificar a qualidade do sistema. Esta disciplina ganha intensidade ao longo da fase de Construção e tende a perder esta intensidade apenas no início da fase de Transição. Ou seja, implementação e teste não devem ser atividades serializadas. Equipes de desenvolvimento e teste podem trabalhar de forma paralela. Em geral é isso o que acontece entre as demais disciplinas também, mas está explicitamente descrito neste post para que alguns paradigmas tradicionais, como este que envolve implementação e teste, sejam esquecidos.

Apenas um artefato é produzido nesta disciplina:

• Modelo de Teste


Este modelo define um Plano de Teste, formado por duas fases principais: testes unitários e testes de integração.

Os teste unitários são fundamentais para garantir que cada um dos componentes integrantes da arquitetura do software esteja se comportando adequandamente. Este tipo de teste consiste na criação de casos de teste.

Cada caso de teste possui uma responsabilidade bem específica, geralmente a verificação da execução de um método do componente. O caso de teste deve prever a execução de todos os caminhos possíveis a serem percorridos durante a execução. É importante que o caso de teste também preveja variações nos dados recebidos (dados normais, dados limite e dados ruins).

Vamos supor que um determinado componente da arquitetura do seu sistema seja responsável por cálculos matemáticos complexos. Certa operação deste componente se propõe a calcular o valor fatorial de um número inteiro qualquer. Por se tratar de um cálculo que envolve valores muito altos, a operação possui um tratamento para considerar apenas os valores entre 1 e 100. Neste caso, dados normais são valores como 20, 50, 70. Já os dados limites, compreendem valores como 0, 1, 2, 99, 100, 101. Por fim, os dados ruins seriam números como -10, -1, 110, 200.

Após validar os componentes, estes devem ser integrados.
Os testes de integração podem ser orientados por casos de teste. Porém, neste caso, procuramos validar comportamentos mais abstratos, de maior granularidade.

O Engenheiro de Teste é um profissional especializado em metodologias para este fim. No exterior, esta é uma posição de muito prestígio em uma equipe de desenvolvimento, com plano de carreira bem definido e alta remuneração. É o profissional que efetivamente autoriza a publicação de um determinado sistema.

Infelizmente, esta realidade não é percebida em nosso país...

A disciplina de Implementação

O objetivo fundamental nesta disciplina é construir uma versão operacional do sistema a ser entregue aos clientes. Caso o projeto encontre-se no primeiro ciclo, é comum que esta versão do sistema seja beta, ou seja, será disponibilizada para avaliação.

Quando esta disciplina aumenta sua intensidade, o projeto provavelmente está na fase de Construção e as discussões passam a ser puramente técnicas. Neste estágio a arquitetura é desenhada em termos de componentes.

A criação do código-fonte também é uma atividade desta disciplina.

Dois artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Implementação


Este modelo é formado por pacotes de implementação. Cada pacote representa um agrupamento lógico de diagramas de componentes da UML. Estes diagramas são responsáveis por discriminar os relacionamentos existentes entre os componentes. Predominantemente, são modeladas as dependências e as conexões entre interfaces exigidas e interfaces fornecidas. Cada componente pode compreender mais de uma classe de projeto.


Figura 1: Principal elemento dos diagramas de componentes da UML: componente.


Este modelo pode ser considerado correto quando contem todos os componentes necessários para realizar as funcionalidades especificadas pelos casos de uso e os requisitos não-funcionais.


• Códio-fonte


É a realização tecnológica dos modelos na linguagem de programação escolhida.

É importante que um padrão de codificação seja seguido e o código comentado para facilitar a leitura em futuras manutenções. Os modelos e o código devem sempre estar sincronizados, refletindo as mais recentes atualizações.