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 estrutura do Processo Unificado

Em artigos anteriores, apresentei o conceito que define o paradigma do Processo Iterativo e os princípios fundamentais que definem uma de suas realizações mais evidentes, o Processo Unificado.

Mas como o UP (do original, em inglês, Unified Process) é estruturado?

Figura 1: Intensidade de cada uma das disciplinas no decorrer das fases em um ciclo.

Pois bem, a vida de um sistema de software é composta por uma série de ciclos. Ao final de cada ciclo, uma versão operacional do sistema é entregue aos interessados. Conforme ilustrado pela figura 1, um ciclo ainda é dividido em quatro fases: Concepção, Elaboração, Construção e Transição.

Resumidamente:

• A Concepção é a fase onde os objetivos do ciclo de vida são identificados. Esta fase diz o que deve ser feito. O domínio é analisado e os requisitos (funcionais e não-funcionais) são compreendidos e selecionados.


• A Elaboração é responsável pela arquitetura do sistema que será distribuído ao final do clico de vida. Esta fase diz como deve ser feito. É importante reforçar que a arquitetura deve suportar todos os requisitos selecionados. Lembre-se que um dos princípios fundamentais do UP é o fato deste ser Centrado em Arquitetura, ou seja, a Elaboração tende a ser uma fase crucial, recheada de desafios e questões complexas.


• Na Construção, como o próprio nome sugere, o sistema é implementado de acordo com o que foi elaborado na fase anterior. Questões puramente técnicas como o encapsulamento de classes lógicas em componentes físicos marcam a fase. O sistema deve possuir a capacidade operacional adequada.


• Por fim, a Transição é marcada pela liberação do produto aos interessados. O projeto deve ser preparado para possíveis ciclos futuros.

Cada fase é composta por uma seqüência de iterações. Tipicamente, a Concepção é composta de uma única iteração e a Transição de no máximo duas. Porém, as fases de Elaboração e de Construção contam com um número maior de iterações.

Uma característica marcante, também ilustrada na figura 1, é o fato de todas as iterações, e conseqüentemente todas as fases, serem atravessadas por todas as disciplinas, com maior ou menor intensidade.

São exatamente as disciplinas que possuem artefatos associados. Artefatos são documentos textuais ou diagramas da UML que facilitam a compreensão do sistema e a comunicação entre os envolvidos. Ou seja, é possível que um artefato de compreensão do domínio seja incrementado em mais de uma fase, mesmo sabendo que o entendimento do domínio é um dos principais objetivos da fase de Concepção.

A maioria dos artefatos produzidos ao longo dos ciclos pertence a um dos seis modelos apresentados na figura 2. Os modelos, contendo todos os seus artefatos, formam a documentação completa do processo de desenvolvimento. Esta documentação deve ser disponibilizada aos envolvidos a cada novo ciclo.

Um modelo por si só também pode ser considerado um artefato, porém, que possui outros artefatos internos, como diagramas completos e textos estruturados. Podemos qualificar um modelo como um agrupamento lógico semanticamente fechado.

Figura 2: Os seis modelos básicos do Processo Unificado.

Mesmo tendo mencionado que uma documentação que compreenda estes seis modelos é tida como completa, podemos adicionar outros documentos que sejam considerados relevantes.

Exemplos de documentos complementares:

• Modelo de Domínio


• Documento de requisitos não-funcionais


• Referências