terça-feira, agosto 15, 2006

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

3 comentários:

Anônimo disse...

Fala Tavão! Parabéms pelo blog.. posta algumas experiencias reais que vc ja passou com processo unificado. Aqui na empresa a gente ja teve mtos problemas depois de ter uma fase de concepção mal feita..
abraço

Anônimo disse...

Leo

Otávio Ferreira disse...

Fala Leo, tudo certo?

Utilizar um processo de desenvolvimento de software nos traz muitas vantagens como, por exemplo, uma melhor organização do trabalho, uma melhor compreensão do domínio, uma melhor comunicação entre os integrantes da equipe e um bom alinhamento entre a equipe e o mundo externo (clientes, patrocinadores etc.).

Mas, ao mesmo tempo, nos trás uma desvantagem muito evidente: o aumento da complexidade. É evidente que o processo se torna um pouco mais burocrático e questões mais complexas tendem a surgir na elaboração dos modelos.

Se colocarmos na balança as vantagens e a desvantagem citada, chegaremos à conclusão que vale a pena adotar um processo.

Não tenho dúvidas que, em algum momento, você deve ter presenciado problemas devido a uma fase de Concepção mal conduzida. Afinal, houve um aumento da complexidade.

Mas tive experiências muito boas. Por exemplo quando conduzi o processo de desenvolvimento de um componente que seria responsável pelo controle de acesso às funcionalidades que qualquer sistema da empresa. É um componente que representa um requisito não-funcional integrante das questões relativas à segurança. Nesta ocasião, a Concepção e principalmente a Elaboração permitiram que o componente cobrisse praticamente todos os cenários onde a segurança era fundamental. Sua utilidade foi tão comprovada que induziu nosso DBA a aprovar algumas mudanças na base de dados que já era estável há pelo menos um ano.

Talvez seja legal você expor as dificuldades que você encontrou para que possamos discuti-las.

É isso ai. Abraços!

 
> blogblogs.com.br