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.

A disciplina de Projeto

Esta disciplina é a principal responsável pela elaboração da arquitetura. Ela utiliza-se dos artefatos produzidos na fase de Análise como base para a elaboração de uma arquitetura baseada em classes de projeto, ou classes concretas. Em geral procura-se unificar os diagramas e não mais manter um para cada caso de uso. Neste estágio é preciso ter uma idéia mais ampla da arquitetura como um todo, inclusive no que diz respeito a questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

A disciplina de Projeto é fundamental em uma metodologia centrada em arquitetura. Realizar bem as tarefas neste momento pode garantir um bom tempo de resposta nas atualizações do software futuramente.

Questões como distribuição de objetos e utilização de frameworks também são consideradas.

Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionados e se complementam.

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

• Modelo de Projeto:


Este modelo é formado por pacotes de projeto. Cada pacote representa um agrupamento lógico de diagramas estáticos, como o diagrama de classes, e dinâmicos, como o diagrama de seqüência e o diagrama de objetos.

Os diagramas estáticos são responsáveis por discriminar os relacionamentos entre as classes de projeto. Deve-se buscar um baixo acoplamento.

Já os diagramas dinâmicos exibem como cada uma das classes de projeto se comporta em tempo de execução. Técnicas como a Inversão de Dependência só podem ser visualizadas em diagramas deste tipo.


• Modelo de Instalação:


Define a organização física do sistema em termos de nós computacionais, os quais são peças de hardware que representam um recurso, como um servidor, uma estação de trabalho ou algum outro software.

Os componentes que formam a arquitetura residem nos nós computacionais. A listagem dos componentes deve ser apresentada no interior de cada nó.

O principal artefato deste modelo é o diagrama de instalação da UML, que discrimina como os nós se relacionam. Os diagramas podem ser agrupados logicamente em pacotes, denominados pacotes de instalação.

Outro objetivo deste modelo é apresentar ao cliente qual a infra-estrutura necessária para a correta execução do software. Este tipo de informação, quando entregue ao final da fase de Elaboração, faz que o cliente tenha tempo para preparar o ambiente.

A disciplina de Análise

É comum dizer que esta disciplina do Processo Unificado tem como foco principal realizar o primeiro “corte” na arquitetura. Em geral, cada caso de uso selecionado é analisado em termos de classes de análise. Ou seja, temos uma primeira representação estática dos casos de uso, uma arquitetura candidata.

Por ainda não serem classes de projeto (ou concretas), esta estrutura estática sofrerá alterações em iterações futuras. Mas, de certa forma, o processo de desenvolvimento começa a se distanciar dos clientes e a ganhar um foco mais técnico. Este fato está ilustrado na figura 1 do post “A estrutura do Processo Unificado”. Nela podemos perceber que enquanto a curva da Análise vai se intensificando, a curva dos Requisitos perde intensidade. Neste momento, provavelmente o processo encontra-se no inicio da fase de Elaboração.

Um artefato principal é produzido durante esta disciplina:

• Modelo de Análise


Este modelo é formado por pacotes de análise. Cada pacote representa um agrupamento lógico de diagramas de robustez da UML desenhados com classes de análise (ou objetos de Jacobson – Sim, ele mesmo, um dos criadores da UML!), e relacionamentos.




Figura 1: Objetos de Jacobson.



Cada classe de análise é classificada como Fronteira, Controle ou Entidade. Fronteira é um tipo de classe que interage com o ator. O Controle detém o conhecimento necessário para a correta execução do caso de uso, possui lógica. Já a Entidade, representa um conceito do domínio, muitas vezes é mapeada em uma tabela de banco de dados.

A disciplina de Requisitos

O foco desta disciplina do Processo Unificado é trabalhar para construir o sistema certo. No inicio do primeiro ciclo de um projeto, ainda não se sabe exatamente qual o sistema a ser construído. O domínio é obscuro e a descrição dos requisitos pelos clientes pode vir acompanhada de ambigüidades, contradições e redundâncias.

A Engenharia de Requisitos, um dos braços da Engenharia de Software, é uma ciência destinada exclusivamente à compreensão das metas e das necessidades dos clientes em um projeto de desenvolvimento de software. As práticas, técnicas e ferramentas providas por esta ciência são grandes aliadas para um bom trabalho nesta disciplina.

Grupos como “The Requirements Engineering Specialist Group”, conferências internacionais e periódicos acadêmicos nos dão idéia da amplitude da Engenharia de Requisitos. Neste artigo vamos nos reter a discutir as atividades básicas executadas na disciplina. Em artigos futuros poderemos nos aprofundar neste tema tão complexo.

Um ponto interessante é perceber que ciências sociais, ciência cognitiva e relacionamento interpessoal são características importantes em um Engenheiro de Requisitos. Neste momento do processo, existe uma forte interação deste profissional com o cliente e é preciso preparo para identificar as ambigüidades, as contradições e as redundâncias que eventualmente aparecem.

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

• Modelo de Domínio:


Este modelo é responsável por exibir os conceitos principais do domínio em que o software está inserido e como estes se relacionam.

É frequentemente representado por diagramas de classes conceituais da UML, ou seja, não são classes de projeto. Alguns conceitos são mantidos e tornam-se classes de projeto na elaboração da arquitetura em iterações futuras, porém, é comum que algumas classes sejam apenas conceituais e não participem do software efetivamente.

Este modelo nos permite compreender com mais clareza o cenário em que os clientes estão envolvidos. Também é utilizado como fonte de inspiração para a nomenclatura de classes em iterações futuras.


• Modelo de Casos de Uso:


Deve ser visto como uma guia para todo o processo de desenvolvimento, representa a força condutora. A idéia principal é identificar os requisitos funcionais do sistema.

Uma vez que um dos princípios fundamentais do Processo Unificado é ser dirigido por casos de uso, temos idéia do quão fundamental é este modelo.

É formado por pacotes de casos de uso, representando, cada um deles, um agrupamento lógico de diagramas de casos de uso da UML. Complementando o modelo, existem descrições textuais estruturadas para cada caso de uso. As descrições devem possuir, pelo menos, as seguintes informações: nome do caso de uso, ator principal, pré-condições, pós-condições, fluxo básico e fluxos alternativos de execução.


• Requisitos Não-Funcionais:


Em 1992, Robert Grady listou cinco grupos de categorização de requisitos. A lista foi denominada FURPS, acrônimo com o seguinte significado, conforme o original em inglês:


• Functionality: Requisitos funcionais.


• Usability: Requisitos de usabilidade, como recursos de ajuda e acessibilidade.


• Reliability: Requisitos de confiabilidade, como capacidade de recuperação após falha.


• Performance: Requisitos de desempenho, como tempo de resposta e disponibilidade.


• Supportability: Requisitos de suporte, como facilidade de manutenção/configuração e internacionalização.


Como os requisitos funcionais já são cobertos pelo Modelo de Casos de Uso, o documento de requisitos não-funcionais deve conter apenas os quatro grupos restantes, ou seja, uma lista URPS.


• Referências:


Este documento é apenas uma sugestão e pode ser formado por três seções: Glossário, Premissas e Referências bibliográficas e eletrônicas.

O Glossário descreve os principais termos a serem utilizados no sistema. Cria um padrão de nomenclatura a ser utilizado pela equipe de desenvolvimento nos diálogos e na elaboração dos diversos artefatos durante o projeto. Frequentemente é uma derivação do Modelo de Domínio.

As Premissas são considerações que justificam algumas características do sistema. A idéia é fornecer um histórico dos pensamentos e das discussões ocorridas durante o desenvolvimento. Esta seção deve auxiliar na manutenção do sistema.

As Referências biográficas apontam quais os livros que auxiliaram no desenvolvimento pela sua teoria. Analogamente, as Referências eletrônicas apontam as páginas da Internet que foram utilizadas em eventuais pesquisas.

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

Princípios Fundamentais do Processo Unificado

O Processo Unificado, uma realização do Processo Iterativo de Desenvolvimento de Software, possui três princípios fundamentais.

A estabilização e a consagração deste processo no mercado devem-se, principalmente, a estes princípios. São eles:

Dirigido por Casos de Uso

Para compreender o conceito "Caso de Uso", é importante conhecer o conceito "Ator". Um ator pode ser entendido com uma pessoa ou uma entidade não-humana que interage com o sistema, mas está fora dele. O exemplo mais comum de ator é o próprio usuário, porém, bancos de dados e outros sistemas também podem ser considerados atores.

Pois bem, um caso de uso é uma seqüência de ações executadas por atores e pelo sistema, a fim de satisfazer metas e necessidades destes atores.

Os casos de uso compõem a força condutora de todo o processo de desenvolvimento, desde a captação inicial de requisitos até a aceitação do código-fonte, por várias razões:

• Primeiramente por serem expressos sob a perspectiva do usuário, em textos descritivos na língua local do cliente. Os textos devem ser intuitivos e óbvios para o leitor.


• Outro ponto fundamental é que permitem uma compreensão direta dos requisitos do sistema. Os casos de uso não devem apresentar ambigüidades, redundâncias ou contradições. Devem especificar um contrato a ser aceito e seguido pelos integrantes da equipe de desenvolvimento e pelos clientes.


• Permitem também um alto grau de rastreamento de requisitos nos diversos modelos que são desenvolvidos posteriormente. Manter os casos de uso à mão durante todo o processo por ser decisivo para o aceite da solução.


• Por fim, os casos de uso facilitam a distribuição de tarefas e a alocação de trabalho.

Centrado em Arquitetura

A arquitetura é a organização fundamental do sistema como um todo. Possui elementos estáticos e dinâmicos que explicitam exatamente como cada componente é construído e como este se relaciona com os demais.

Uma boa arquitetura deve prover um alto grau de manutenibilidade. Este fato é fundamental para que a equipe de desenvolvimento possa atender as demandas que surgem em um intervalo de tempo cada vez menor, principalmente após a adoção da Internet como canal de comunicação primário.

Inúmeras corporações modelam seus negócios de acordo com a tecnologia disponível, inviabilizando a inovação, mutação e, em alguns casos, até o crescimento do negócio. Segundo constatado por Paul Strassmann em 1997, na realidade uma situação inversa deveria ser empregada, onde as seguintes características sustentariam a ideal postura de um departamento de Tecnologia da Informação em uma organização: deveria agregar real valor ao plano de negócios, não deveria resistir às mudanças e deveria combater qualquer tipo de resistência a elas, pois são necessárias.

Partindo deste ponto de vista, é essencial que o software se adapte ao modelo de negócios estipulado em uma corporação. Porém, como modelos de negócios são mutáveis, a arquitetura do software em questão deve ser flexível o suficiente para acompanhar tais mudanças e expansível o suficiente para permitir o crescimento.

Um alto grau de modularidade pode ser um grande aliado no alcance de altos graus de manutenibilidade, flexibilidade e expansibilidade.

Um módulo pode ser entendido como uma porção de código encapsulada, coesa e fracamente acoplada. Já o grau de modularidade estima a coerência de utilização de módulos na arquitetura de um sistema, obedecendo cinco critérios e seis princípios, descritos por Bertrand Meyer em 1988, exibidos nas listagens abaixo:

• Critérios:




• Decomposição: Capacidade de dividir o problema inicial em subproblemas, ou módulos, isolados.


• Composição: Capacidade de reutilização dos módulos na construção de novos sistemas, possivelmente em ambientes ligeiramente diferentes.


• Entendimento: Capacidade de compreensão dos módulos de forma individual por um leitor humano.


• Continuidade: Capacidade de alteração dos módulos sem impacto nos demais, mantendo a arquitetura e as relações.


• Proteção: Capacidade de suporte a condições anormais dos módulos, limitando o escopo de um erro ao próprio módulo e protegendo o restante do sistema.




• Princípios:




• Unidade modular sintática: Um módulo deve corresponder a uma unidade sintática da linguagem.


• Poucas interfaces: Um módulo deve se comunicar com a menor quantidade de módulos possível, evitando recursão.


• Interfaces pequenas: Um módulo deve trocar a menor quantidade de informações possível com outro.


• Interfaces explícitas: A comunicação entre dois módulos deve ser explícita e clara.


• Informações ocultas: Os dados de um módulo devem ser privados, com raras exceções de dados públicos.


• Aberto e fechado: Aberto para pequenas alterações (sem impacto nas interfaces) e fechado, sugerindo sua completude e disponibilidade de uso.

Ainda tendo em vista o grau de modularidade, uma arquitetura deve ser elaborada considerando diversos níveis de abstração. Quanto menor a abstração de um componente, maior será seu potencial de reuso. Esta característica fundamental pode ser alcançada através da utilização de frameworks, um conjunto de classes abstratas e concretas com alto grau de especialização.

Reunindo todo este conhecimento, somos capazes de minimizar a existência de três propriedades internas indesejáveis na arquitetura:

• Rigidez: A manutenção em um determinado ponto do sistema obriga ao desenvolvedor ajustar outras localidades diretamente relacionadas, gerando uma cadeia de manutenção. Suas conseqüências são conhecidas como “efeito dominó”.


• Fragilidade: A manutenção em um determinado ponto do sistema gera problemas em outro ponto não relacionado, muitas vezes distante do local da alteração. Suas conseqüências são conhecidas como “efeito borboleta-maremoto”, nomenclatura extraída da Teoria do Caos. Esta teoria defende que o simples bater de asas de uma borboleta em um extremo do mundo, pode ser o estopim de um tornado no outro extremo.


• Imobilidade: Ao tentar reutilizar um componente já desenvolvido, classes não pertencentes a este impossibilitam a ação, dado o forte acoplamento existente. Suas conseqüências são conhecidas como “efeito banana-gorila”.

Iterativo e Incremental

Cada projeto é dividido em iterações. Cada iteração pode ser considerada um miniprojeto de curta duração que tem por objetivo oferecer uma melhora incremental ao sistema.

São benefícios desta forma de organização:

• É um progresso lógico para que uma arquitetura robusta seja alcançada. Durante as iterações iniciais, uma arquitetura candidata é proposta. Sua evolução será uma fundação sólida para o restante do sistema.


• Em contraste com metodologias que seguem o paradigma do Processo Cascata, onde todos os requisitos são levantados no inicio e nunca mais revisados, o Processo Unificado prevê a negociação progressiva de requisitos, priorizando aqueles que representam riscos mais significativos ao projeto.


• Possibilita maior flexibilidade para que mudanças ocorram no plano de atuação da equipe de desenvolvimento. Uma avaliação ao final de uma iteração permite isolar um eventual problema identificado e lidar com ele em uma escalada reduzida, sem propagar seus efeitos.


• Caso o incremento de uma iteração seja um componente ou módulo, este é integrado aos demais existentes. Uma integração muitas vezes representa a conquista de mais um requisito. A evolução do trabalho torna-se mais evidente aos interessados.


• Por fim, a natureza iterativa permite que novos integrantes da equipe de desenvolvimento iniciem suas atividades sem que sejam submetidos a treinamentos extensos que cubram todo o projeto.

Processos Iterativos de desenvolvimento de software

Contextualização

A Crise do Software é realidade desde meados da década de 70. Clientes insatisfeitos, atrasos nos prazos, custo infinito e produto final com baixa qualidade são apenas algumas características que marcam esta crise.

Apesar da evolução tecnológica e das iniciativas de intelectuais como Barry Boehm na década de 80 e Gustav Karner na década de 90, que propuseram métodos de estimativas, atualmente permanecem raros os exemplos de projetos de software desenvolvidos fora dos padrões da crise descrita.

No combate ao cenário caótico, tornam-se necessárias a criação e a adoção de metodologias que auxiliem os projetos de desenvolvimento. Desta forma, é possível gerenciar a crise. Algumas tentativas foram propostas.

Na década de 80 surgiu um tipo de processo conhecido como Processo Cascata (do original, em inglês, Waterfall Process). É constituído basicamente por cinco fases seqüenciais: descoberta de requisitos, desenho, implementação, teste e implantação. Com sua utilização, percebeu-se que o processo não atendia completamente as necessidades dos profissionais. A constante mudança de requisitos, a divisão inflexível das atividades e a rigidez imposta colaboraram para o fracasso do processo.

Já no início da década de 90, um tipo de processo conhecido como Processo Espiral surgiu como uma boa solução aos problemas identificados no Processo Cascata, pois protótipos são construídos a cada ciclo e refinados nas fases seguintes. Este processo permite que as fases sejam definidas de acordo com objetivos do projeto. Porém, a má adequação ao paradigma de orientação a objetos determinou o fracasso deste processo. O modo procedimental de criação de software já não era suficiente na resolução de problemas complexos ou, pelo menos, extensos.

A solução definitiva, consolidada no final dos anos 90, foi a criação de um tipo de processo conhecido como Processo Iterativo. Neste, a cada iteração os modelos são refinados e, ao final de cada ciclo, um protótipo é entregue aos stakeholders, os interessados no projeto.

O paradigma do Processo Iterativo e suas realizações

O Processo Iterativo define um paradigma, ou seja, uma forma de pensar. Este não pode ser considerado um processo completo de desenvolvimento de software, pois não discrimina as atividades necessárias para que este objetivo seja alcançado.

Uma realização desta forma de pensar é o Processo Unificado (UP), que se encaixa na definição geral de um processo completo: um conjunto de atividades executadas para transformar um conjunto de requisitos em um sistema de software. Entretanto o Processo Unificado também é uma estrutura genérica de processo que pode ser customizada adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos recursos disponíveis para um projeto. Também pode sofrer alterações de acordo com a filosofia da empresa que o emprega. O Processo Unificado da Rational (RUP), por exemplo, é uma versão especializada do Processo Unificado que adiciona elementos a sua estrutura genérica. Surgiu dos esforços de Ivar Jacobson, Grady Booch e James Rumbaugh em 1998 na Rational, recentemente adquirida pela IBM.

O Microsoft Solutions Framework (MSF), que também se encaixa na definição geral de um processo completo, já é uma outra realização do paradigma do Processo Iterativo. Surgiu da vasta experiência em desenvolvimento de software adquirida pela Microsoft ao longo de sua existência. Uma vantagem evidente na utilização desta metodologia é alcançada para as equipes que utilizam ou utilizarão o Visual Studio 2005 Team System, pois esta ferramenta possui dois methodology templates que podem ser adequados de acordo com as necessidades ou utilizados como fundação na criação de uma versão especializada do processo.

Conclusão

Apesar de existirem esforços e iniciativas na unificação dos processos completos de desenvolvimento de software, o que realmente aconteceu foi o estabelecimento de um paradigma como sendo o mais correto no gerenciamento da crise do software.

Note que eu utilizei a palavra “gerenciamento” e não “solução”. Este tipo de crise não pode ser extinta, ela existe toda a vez que uma equipe não se baseia em uma metodologia comprovadamente eficaz (cenário ainda muito comum no mercado brasileiro). O termo “gerenciamento” refere-se à possibilidade de medir, de forma controlada e adaptativa, o tempo e o custo de um projeto.

Realmente a unificação apenas do paradigma me parece mais correta do que a unificação dos processos completos, dado que cada empresa possui sua filosofia e o processo ocorre internamente. O mesmo não acontece com as linguagens de modelagem, que foram unificadas na UML para que as empresas possam compartilhar modelos e componentes.

Já que a adoção de uma metodologia é necessária, selecione aquela que se encaixe melhor no projeto e nos recursos disponíveis. Considere também a ferramenta de desenvolvimento utilizada como fator de decisão. Por fim, tenha em mente que a criação de uma metodologia também é bem-vinda, contanto que siga o paradigma iterativo.

Novo canal de discussão para Engenharia de Software!

A primeira postagem, como não poderia deixar de ser para um Engenheiro de Software, é um típico "Hello, World!".

A idéia deste canal é promover a democratização, a discussão e a difusão dos conceitos que formam a Engenharia de Software.

Fiquem à vontade...

Um abraço a todos, Otávio Ferreira.