para condução do terceiro estudo de caso, descrito a seguir.
4.3
Estudo de caso III - EC-IN
Os objetivos do terceiro estudo de caso são os mesmos dos objetivos do segundo estudo de caso: avaliar comparativamente, entre desenvolvedores o CoMDD com a abordagem tradicional. Entretanto, enquanto o segundo estudo de caso teve um caráter qualitativo, o terceiro estudo de caso tem um caráter também quantitativo. A avaliação também consiste na coleta de opiniões por parte desses usuários.
4.3.1
Descrição dos participantes
O EC-IN teve a participação de 48 pessoas, sendo que 92% delas eram formadas em algum curso de computação, 81% já fizeram ou faziam mestrado/doutorado, 98% já desenvolveram sistemas em equipe, 92% já trabalharam ou trabalham em empresas e 79% dos participantes já trabalharam ou trabalhavam com uma IDE associada a um programa de versionamento. A média de experiência em anos por participante é de 8.37 e a moda é de 8 anos. A Figura 4.3 apresenta o número de pessoas pelo tempo em que elas programam em anos.
Figura 4.3: Experiência em programação dos participantes em anos por quantidade de participantes.
4.3.2
Instruções e Problema Apresentado
Foram apresentados dois vídeos para cada participante. Um vídeo do CoMDD realizando as atividades de edição de modelos com comentário da versão de alteração, comentário na página de edição, comparação entre modelos, retorno para uma versão anterior do modelo e geração de código11. No outro vídeo, foram feitas as mesmas atividades, mas no contexto
do Eclipse+SVN12. Por fim, foi apresentado um questionário.
No Apêndice E está o email enviado solicitando a participação dos desenvolvedores, bem como todas as perguntas feitas aos participantes.
4.3.3
Resultados do EC-IN
Quando os participantes foram questionados sobre qual era o mecanismo de colaboração que eles tinham/tiveram na sua empresa ou na sua equipe de desenvolvimento, ou seja, como eles colaboram na resolução de problemas, foram definidos nove itens a partir das respostas e que assim as classificariam13. São os nove itens:
1. Reuniões:são discussões ou conversas, informais ou não, para solucionar um problema, esclarecer uma dúvida ou distribuir tarefas;
2. Divisão de tarefas: quando há um planejamento do que será feito pela equipe ou por um gerente e então cada membro é responsável por uma tarefa;
3. Sistema de versionamento: quando mencionavam algum programa de versionamento; 4. Email: ou lista de email;
5. Bugger tracker ou issue tracker; 6. Quadro branco;
7. Programação/Revisão em pares; 8. Wiki;
9. Skype.
Essas foram as palavras e/ou expressões mais citadas pelos participantes. Dessa forma, levantou-se o gráfico apresentado na Figura 4.4.
11http://vimeo.com/36209527
12http://vimeo.com/36206167
13A análise dos resultados foi feita a partir da leitura e interpretação das respostas subjetivas, de modo que possi-
bilitasse o agrupamento dos dados e assim extrair uma possível informação. Por exemplo, dada a pergunta "Que tipo de colaboração você tem/teve na sua empresa ou na sua equipe de desenvolvimento. Ou seja, como vocês colaboram na resolução de problemas?"um participante respondeu: "Nas empresas que trabalhei não havia nenhuma metodolo- gia definida de engenharia de software. Nós programávamos individualmente nas máquinas e assim a colaboração geralmente eram em conversas informais". Esta resposta foi classificada como "Reunião".
50 4.3. ESTUDO DE CASO III - EC-IN
Figura 4.4: Formas de colaboração citadas.
Quando os participantes foram questionados quais funcionalidades de uma ferramenta de versionamento eles achavam mais importante e/ou quais funcionalidades eles mais usavam, foram levantadas seis funcionalidades14 (ver Figura 4.5):
1. Rollback: capacidade de reverter um artefato para uma versão anterior;
2. Histórico: ou log de versões, com o intuito de controlar alterações, engloba todas as informações de um commit, como data, autor, comentário etc;
3. Comparação de versões;
4. Mesclagem ou resolução automática de conflitos; 5. Criação de branches;
6. Integração com outras ferramentas, como IDEs, por exemplo.
Quando os participantes foram questionados se usariam o CoMDD no lugar do Eclipse+SVN, algumas respostas foram expressamente sim ou não; entretanto, outras tiveram que ser inter- pretadas se o participante usaria ou não. Dessa forma, 42,22% (19 de 45 respostas válidas) usariam o CoMDD, com ou sem restrições para seu uso e 35,55% não usariam (16 de 45).
Não foi subentendido nada de uma resposta, ou seja, se o participante citasse divisão de tarefas, mas não citasse reuniões ou diálogos ou mencionasse que havia conversas entre os líderes e desenvolvedores, a resposta era classificada apenas como "Divisão de tarefas"e não "Reunião".
14Apenas 25 participantes citaram check-in/check-out e, por isso, essa funcionalidade foi descartada, pois provavel-
mente os participantes acharam que essa funcionalidade já estava implícita, visto que dificilmente alguém que compara versões não irá fazer check-in ou não tenha feito check-out
Figura 4.5: Principais e mais usadas funcionalidades de um sistema de versionamento citadas.
Ou seja, entre os 42,22% que disseram que usariam o CoMDD, alguns deles disseram que precisava melhorar em alguns aspectos, assim como, entre os 35,55% dos que disseram que não usariam o CoMDD, disseram que não usariam por alguns aspectos.
Esses aspectos foram definidos como as barreiras para uso do CoMDD. A Figura 4.6 apre- senta essas barreiras citadas pelos participantes.
Quando os participantes foram questionados se o CoMDD seria capaz de suprir suas ne- cessidades em termos de ferramenta de versionamento, 74% dos participantes disseram que sim; e 72% dos participantes afirmaram que levando em consideração que o CoMDD é um protótipo e não uma ferramenta de produção, ele atende aos propósitos que o Eclipse+SVN traz em termos de desenvolvimento de software e compartilhamento. Se o CoMDD tivesse syntax highligthe autocomplete, 77% dos participantes o usariam satisfeitos e 12% usariam, mas insatisfeitos em termos de versionamento, o que indica que syntax highligth e autocom- pletesão elementos muito importantes nas IDEs.
Dentre os participantes, 84% dos participantes não viam como uma barreira ter que instalar softwares para desenvolver; entretanto, quando questionados se isso seria uma barreira para um não desenvolvedor, 86% disseram que sim.
Quando os participantes foram questionados se usariam o CoMDD para desenvolver usando modelos, o qual é o propósito do CoMDD e não desenvolver usando código fonte, 86% dos participantes disseram que usariam; 72% dos participantes acham o CoMDD uma aborda- gem mais fácil e simples de usar e levando em consideração que o CoMDD é um protótipo
52 4.3. ESTUDO DE CASO III - EC-IN
Figura 4.6: Principais barreiras para o uso do CoMDD citadas.
e não uma ferramenta de produção, 84% dos participantes acham que o CoMDD traria pro- dutividade no desenvolvimento de software em uma equipe.
4.3.4
Opiniões dos Participantes
Serão apresentadas algumas opiniões dos participantes, sendo que cada item é de um parti- cipante selecionado:
– "Talvez aumentaria a produtividade de equipes formadas por desenvolvedores com pouca experiência que não utilizam todos os recursos das ferramentas já disponíveis"; – "Acredito que a ferramenta não seja adequada/ideal para o desenvolvimento de siste-
mas em geral, mas com algumas melhorias poderia ser muito útil na área de ensino de programação, no desenvolvimento em pares (ex: XP), desenvolvimento de exem- plos/snippets e na resolução de alguns bugs mais chatos por uma equipe. No caso de equipes separadas geograficamente, os ganhos seriam ainda maiores. O motivo é que desenvolvedores costumam possuir gosto muito variado pelas ferramentas, e dificil- mente uma equipe completa vai se sentir a vontade utilizando uma única ferramenta para o desenvolvimento, fazendo a produtividade cair. Mesmo dentro de uma mesma ferramenta ou ambiente, é muito comum um alto grau de customização pessoal, que não seria possível nesse caso";
– "Acho mais proveitoso incorporar o CoMDD a uma IDE do que fazer com que ele se comporte como uma";
– "Parabéns pelo trabalho e principalmente pela implementação e pela preocupação em saber o que os desenvolvedores pensam sobre a sua abordagem. Com certeza enriquece muito um trabalho de pesquisa. Mesmo que seja um protótipo, você consegue provar que muito da teoria pode ser aplicada";
– "O seu trabalho tem tudo a ver com um dos itens do manifesto ágil: Indivíduos e intera- ção entre eles mais que processos e ferramentas. Mesmo utilizando uma ferramenta de ES vc consegue de diversas formas promover a colaboração entre os desenvolvedores o que é muito importante";
– "Usabilidade bastante agradável o que facilita na aceitação de uma nova ferramenta"; – "Se a equipe for muito grande, talvez a wiki não seja adequada para o desenvolvimento.
Como a wiki se comporta quando mais de um usuário tenta alterar os mesmo código ao mesmo tempo?";
– "Acho que a comparação entre o CoMDD e o Eclipse/SVN não é justa. Cada uma tem suas vantagens e desvantagens. SVN e Eclipse já vem sendo usados com sucesso há muito tempo, e não precisam de melhorias, pois já fazem muito bem aquilo a que se propõem. Já o uso de uma wiki pode ser uma tendência futura. Talvez com a evolução do software em nuvem leve a uma aplicação tão poderosa quanto o Eclipse. Outra questão que não entendi muito bem é essa parte da geração de código. Os vídeos não explicam isso direito, nem no CoMDD e nem no Eclipse/SVN".