Os dados obtidos com os estudos nos deixam estabelecer algumas indicações sem permitir, contudo, nenhuma afirmação ou conclusão acerca do uso dos modelos no contexto de desenvolvimento Web. Para facilitar essa análise vamos tratar os dados quantitativos para cada um dos modelos separadamente e, em seguida, analisar os dados qualitativos de uma forma geral. É importante destacar que a análise a seguir foi influenciada, na maior parte dos casos, pelos dados do terceiro estudo de observação. Entretanto, os dados obtidos no primeiro e segundo estudos reforçam, em vários momentos, os resultados obtidos no terceiro, se observados isoladamente.
2.5.1 Análise dos Resultados Quantitativos Diagrama de Classes
Esse modelo foi o mais manipulado pelas diversas equipes nos três estudos, o que já era de certa forma esperado, haja vista o seu papel de destaque no desenvolvimento de software OO. Os participantes puderam perceber a grande importância de construir esse modelo (Tabela 2-9), mas relataram uma percepção de esforço alta (com viés para média) talvez influenciada pela falta de experiência dos participantes, já que a aplicação não tinha alta complexidade. Essa dificuldade também pode estar relacionada com o entendimento do paradigma OO, pois alguns participantes dos estudos 2 e 3 relataram certa “confusão” entre os paradigmas OO e os modelos ER (Entidades-Relacionamentos). A divisão das tarefas também foi
27 apontada como um fator que trouxe dificuldades no uso desse modelo, já que ela levou à divisão da especificação em casos de uso que foram tratados individualmente pelos desenvolvedores que, por sua vez, perderam a visão geral do domínio necessária para construção e evolução do modelo. O reflexo disso foi que muitos participantes apontaram as reuniões presenciais como um instrumento para mitigar esse risco. Outro ponto levantado foi a dificuldade de criar o modelo conceitual de classes, pois a visão dos casos de uso não proporcionava uma visão geral dos processos de negócio. Daí surgiram algumas sugestões no sentido aprimorar o documento de especificação a fim de incorporar essa informação.
Diagrama de Seqüência
Esse modelo também foi bastante explorado pelos desenvolvedores, porém o grau de importância atribuído pelos participantes foi bem menor se comparado com o modelo de classes (Tabela 2-9). Esse fato surpreende até certo ponto, pois essas duas perspectivas são totalmente complementares e fazem parte da essência do paradigma OO. Esse fato pode ser explicado pela falta de experiência e/ou treinamento/estudo insuficiente (Tabela 2-10), o que pode fazer com que os desenvolvedores tendam a tratar as questões comportamentais prioritariamente através da codificação usando uma linguagem de programação. Seguindo esse raciocínio, a modelagem da estrutura seria importante e essencial como ponto de partida apenas para o processo de codificação. Por outro lado, essa tendência também pode ser alimentada pelo alto grau de esforço percebido na construção desse modelo (Tabela 2-8), o que poderia levar os desenvolvedores a abandoná-lo em função de outra atividade que atinge o mesmo objetivo, mas cuja percepção de esforço é menor.
Diagrama de Atividades
Analisando os trabalhos entregues pelas equipes, verificamos que ora esse diagrama era citado como essencial ora como descartável. Talvez pela falta de um foco bem definido, como ocorre com os diagramas de classe e seqüência, a exploração desse diagrama tenha sido pequena e as percepções tenham sido tão dispersas. Analisando o uso desse diagrama pelas quatro equipes mais bem colocadas, constatamos que ele foi usado como representação gráfica dos casos de uso por duas equipes e como representação gráfica dos processos de negócio por uma equipe (uma das equipes abdicou do seu uso). Entretanto, nenhuma delas declarou que o diagrama era essencial ou ao menos importante. Esse fato nos remete a uma questão mais geral: a percepção da importância pode estar diretamente
28 relacionada à definição de um foco claro e objetivo para o modelo, a partir do qual o desenvolvedor consegue perceber os benefícios e os desdobramentos do seu uso.
Diagrama de Estado
Esse diagrama foi razoavelmente explorado pelas equipes e o seu grau de importância teve um viés de baixa (Tabela 2-9), assim como o esforço percebido pelos participantes (Tabela 2-8). Apesar do domínio da aplicação desenvolvida realmente não exigir máquinas de estado muito aprimoradas, constatamos, através da análise dos diagramas gerados pelas equipes, que o grau de detalhamento desses diagramas não acompanhou o grau de detalhamento do modelo de classes e seqüência, causando um desbalanceamento entre esses modelos em termos de abstração. Isso pode ter sido causado pela falta de experiência dos desenvolvedores e/ou treinamento inadequado (o mesmo ocorreu com os diagramas de seqüência, já que ambos focam no aspecto comportamental). Entretanto, uma dificuldade relatada chamou a atenção: o documento de requisitos. Através da análise dos dados qualitativos foi possível entender a razão dessa dificuldade: alguns participantes relataram que as transições de estado definidas na especificação estavam nas “entrelinhas” das descrições dos casos de uso e sugeriram que tanto a definição dos estados quanto os eventos que disparam a sua transição sejam representados de uma forma mais objetiva para facilitar a construção inicial deste modelo.
Mapa Navegacional
A Tabela 2-6 indica que um número razoável de participantes tentou explorar esse modelo. Contudo, a percepção de esforço alta (Tabela 2-8) aliada ao baixo grau de importância percebido (Tabela 2-9), fez com que as equipes classificassem esse modelo apenas como desejável ou até mesmo descartável. A falta de experiência e/ou treinamento adequado aliadas à baixa aderência da ferramenta CASE à semântica do mapa navegacional, de fato podem ser fatores críticos que explicam essas dificuldades. Porém, o que realmente chama a atenção nesse caso é que os participantes não conseguiram perceber a importância de representar essa perspectiva no desenvolvimento de uma aplicação Web. Em última análise, isso poderia indicar que os participantes não sentiram a necessidade de representar a perspectiva navegacional, ou que as informações relevantes foram ou poderiam ser capturadas em outros modelos. Analisando por outro ângulo, a importância pode não ter sido percebida porque os desdobramentos que a criação desse modelo poderia ter no produto final, em termos de garantia da qualidade ou até mesmo da confecção do produto em si, não foram percebidos pelos participantes. Talvez esse seja um
29 mecanismo natural de corte implicitamente usado pelos desenvolvedores: não vale a pena criar um modelo quando este não é usado de forma direta ou indireta na obtenção do produto final.
Mapa de Atores
A análise dos trabalhos nos permite afirmar que esse diagrama foi efetivamente pouco explorado no contexto de desenvolvimento proposto. Na realidade o mapa de atores só tem sentido se explorado juntamente com o mapa navegacional, já que ambos fazem parte do mesmo método (OOWS). Contudo, as equipes tentaram explorar esse diagrama de forma isolada, o que resultou em um baixo nível de importância percebida.
2.5.2 Análise dos Dados Qualitativos
Os dados qualitativos foram analisados de forma conjunta, sem levar em consideração opiniões específicas acerca de um modelo em particular. A idéia por trás dessa análise foi poder obter um conjunto de categorias e códigos que indicassem facilitadores em um processo de desenvolvimento de aplicações Web dirigido por modelos, que poderiam indicar, em última análise, características a serem observadas e/ou adotadas nesses processos.
A seguir são listadas as categorias, obtidas com a aplicação da codificação aberta e da codificação axial sugeridas por STRAUSS e CORBIN (1998) para o método Grounded Theory, e as principais sugestões relacionadas a elas.
Requisitos
Foram citadas sugestões relacionadas à adequação do documento de requisitos como insumo principal para geração inicial dos modelos. Essas sugestões dizem respeito tanto à necessidade de aprimoramento no nível de detalhamento necessário quanto à estrutura do próprio documento. Também foram citadas a necessidade de apresentar inicialmente uma visão geral dos processos de negócio, assim como o escopo do projeto e as perspectivas de futuras evoluções.
Ferramenta CASE
Foram citadas recorrentemente três sugestões: adequação sintática e semântica aos modelos, interface que privilegie a agilidade na manipulação dos modelos e trabalho colaborativo.
30 Foram citadas a necessidade de processos para verificação da consistência entre os modelos, processos para inspeção dos requisitos e processos para validação dos modelos de navegação junto aos clientes.
Modelos
Foram sugeridas a exploração de transformações (semi) automáticas de modelos, a geração de outros artefatos a partir dos modelos e o reuso de modelos e padrões de projeto.
Processo de Modelagem
A maior parte das sugestões se enquadrou nessa categoria, tais como: definição de heurísticas de apoio à construção dos modelos, critérios para seleção dos modelos mais relevantes de acordo com o contexto de desenvolvimento, critérios para definição do nível de detalhamento a ser utilizado nos modelos de acordo com a complexidade existente em determinada parte da aplicação e a definição de uma ordem para construção/refinamento dos modelos.
Treinamento em Modelagem
As diversas sugestões podem consolidadas como exploração de exercícios e exemplos com ênfase na simulação de situações reais de projeto.