Solutions de géométrie basale z b

Esta seção explica o procedimento investigatório de acordo com a metodologia adotada para este trabalho. Neste é encadeado um conjunto de atividades que norteiam a execução da pesquisa. As análises e as interpretações são apresentadas nos próximos capítulos.

4.3.1 Definição do alcance

Em seu trabalho, Basili e Rombach (1988), apresentam o GQM (Goal/Question/Metric) como um recurso para definir metas mensuráveis para projetos. Afirmam, Basili e Rombach (1988), que para isso procura-se fazer o refinamento dos objetivos por meio de um conjunto de questões capazes de refletirem as métricas buscadas. Segundo Bocco, Cruz-Lemus e Velthuis (2014), em um experimento a definição do alcance define os objetivos do experimento. O mesmo autor, recomenta o uso do recurso GQM apresentado por Basili e Rombach (1988). O Quadro 11 apresenta uma adaptação de uma planilha GQM relatada por Bocco, Cruz-Lemus e Velthuis (2014):

Questões Respostas

O que analisar? As interações entre os sites de desenvolvimento; Com qual o

propósito?

verificar a aderência de um protocolo de comunicação, conforme proposto pelo capítulo 3;

Sobre qual assunto?

o conjunto de dados, gerados a partir de um experimento simulando um projeto, são analisados. Tal conjunto compreende a interação humana entre os stakeholders composta por mensagens e artefatos;

Ponto de vista?

interações são analisadas externamente ao ponto de vista dos envolvidos no projeto. Tal observação propicia uma análise independente da sua execução. Desta maneira, acredita-se que o protocolo, proposto neste trabalho, tenha uma aderência equivalente em um cenário real;

Contexto?

o contexto analisado incorpora práticas de gestão de projetos, tem como aplicação um ambiente de desenvolvimento distribuído de software. Neste sentido, o estudo aborda as interações entre partes fisicamente e/ou temporalmente distantes. A comunicação decorrente das interações entre os membros de um mesmo site não é abordado neste.

Quadro 11 - Aplicação da planilha GQM Fonte: Bocco, Cruz-Lemus e Velthuis (2014)

4.3.2 Planejamento

Planejar a pesquisa, para este trabalho significa encadear as ações que serão conduzidas na execução da pesquisa. Trata-se do encadeamento de atividades, conforme descrito por Yver e Murthy (2013) tem como propósito guiar o pesquisador na busca pela solução de seu problema.

Para a validação deste protocolo, foi executado um teste experimental e um segundo, a execução do experimento propriamente dito.

4.3.2.1 Teste Experimental

Após a delimitação do protocolo, um dos problemas identificados emergentes foi a capacidade de rastrear a comunicação existente em um projeto. Para a validação do mesmo é preciso que toda a comunicação existente em um projeto seja mapeada dentro da estrutura do protocolo. A partir deste problema, o teste experimental foi conduzido com o propósito de verificar a possibilidade do rastreamento da interação entre os sites.

A fim de garantir condições próximas às esperadas para o projeto, durante a seleção dos participantes, buscou-se pessoas com conhecimentos na área de informática para o teste experimental. O teste foi aplicado em um conjunto de pessoas composto por 1 professor e 3 alunos, sendo que 2 destes alunos eram do curso de graduação em Engenharia de Computação da UTFPR, pertencentes aos períodos finais do curso; e 1 do Programa de Pós-Graduação em Informática (PPGI) também da UTFPR.

O objetivo deste teste foi simular a execução do projeto a fim de determinar a viabilidade e a confiabilidade dos aspectos instrumentais e os fundamentos utilizados na aplicação do experimento. Desta forma, mesmo os alunos não entregando um produto final exequível, foi possível obter respostas afirmativas às estas dúvidas. É importante reafirmar que o propósito deste foi validar a instrumentação e também estabelecer um baseline para o projeto.

Ao fim do teste experimental verificou-se que a metodologia era aplicável ao projeto. Pois, em uma menor escala, consegui-se atingir os objetivos conjecturados

para este. No entanto, também se verificou a necessidade de realizar alguns ajustes quanto:

a) identificação dos sites: percebeu-se a necessidade de definir nomes mais intuitivos aos sites, pois durante o experimento houve confusões entre os participantes ao identificar quem fazia as solicitações e quem as atendia;

b) identificação das peças: devido a um alto grau de semelhança entre diversas peças, que foram distribuídas e posteriormente negociadas entre os sites, houve a necessidade de mudar o sistema de identificação, que antes tratava-se apenas de um mostruário impresso, contendo apenas as imagens. Optou-se pelo mesmo mostruário que, além da imagem, continha um numero identificador de cada peça.

4.3.2.2 Projeto

O experimento foi aplicado em conjunto com alunos do PPGI da UTFPR, Campus Cornélio Procópio divididos em 4 equipes de 3 e 4 pessoas. Neste, todos os discentes selecionados são profissionais atuantes no mercado de TI, com aproximadamente 3 anos de experiência. Esta seleção permitiu que as interações realizadas entre as equipes fossem geradas a partir de profissionais de mercado com experiência em desenvolvimento de software.

O projeto utilizado no experimento foi configurado para ser executado entre as 4 equipes remotas. O projeto apresentou um cenário problema, em uma primeira reunião presencial com todos os envolvidos e em uma segunda etapa, foram separados fisicamente com o propósito de desenvolver um produto final. Um kit robótico Lego Mindstorms fui utilizado com a intenção de instigar e configurar o projeto de maneira lúdica. Processos de ensino relativos à gestão de projetos é desenvolvido constantemente pelo grupo de pesquisa sobre gestão da tecnologia da informação (GTI4) que apresenta resultados parciais Frontiers in Education

Conference 2015 (FIE) (FABRI; L’ERARIO, 2015).

O Quadro 12 sintetiza os propósitos do projeto. Este quadro indica os objetivos do projeto. Resumidamente, os participantes do experimento precisavam, _____________

4

Disponível em: <http://dgp.cnpq.br/dgp/espelhogrupo/9117429043346548>. Acesso em: 07/07/2016.

ao final das atividades, entregar um produto robô capaz de resolver um dado problema. Precisaram montar o robô e também desenvolver o software para o mesmo.

Objetivo do

projeto Desenvolver um robô, montar e desenvolver o software. Configuração

física do Robô

Documentação disponibilizada pela Lego. Cada equipe recebeu na primeira reunião: a parte que deve montar e um conjunto de peças aleatórias

Software

Um problema especificado e enviado para as equipes. Cada equipe desenvolve um segmento do software. Para a codificação o LeJos foi utilizado.

Restrições impostas

Um processo deve ser seguido para o desenvolvimento do produto final. A entrega de alguns artefatos é obrigatória, vide Quadro 13.

Quadro 12 - Propósitos do projeto

Figura 10 - Sequência dos passos para desenvolvimento do projeto.

A Figura 10 indica o macroprocesso a ser seguido pelos sites para a criação do produto final. Para cada uma das etapas, um conjunto de artefatos foi definido como itens obrigatórios, ou seja, as equipes deveriam entregar. A apresentação do macroprocesso foi executada na primeira reunião com todos os membros de todas as equipes. O Quadro 13 indica o conjunto de artefatos obrigatórios para cada uma das atividades do macroprocesso.

Atividade Objetivo Artefatos

Planejamento

As equipes devem preparar a montagem do robô. Cada equipe recebeu uma especificação de uma parte do robô e um conjunto de pecas aleatórias. Também recebeu uma lista contendo o custo destas peças.

Estrutura Analítica do Projeto; Estimativa de custo e tempo.

Montagem

Os sites devem negociar com outras equipes os componentes que lhe faltam. Cada site deve montar a parte que lhe foi incumbida e ligar componentes mecânicos e eletrônicos do robô.

Uma equipe deve integrar todos os componentes.

Fluxo de caixa; Relatório de montagem parcial; Relatório de integração final.

Validação da montagem

A validação da montagem não pode ser executada pelo grupo que efetuou a integração final dos componentes. Relatório de validação final. Desenvolvimento do Software Processo exigido: a) especificação de requisitos; b) definição arquitetônica;

c) codificação (pelo menos 3 grupos ativamente envolvidos);

d) integração.

O software será desenvolvido em Java, utilizando LeJOS (Lego Java Operating System)

Especificação dos Requisitos. Casos de uso; Diagrama de classes (implementação); Relatório de distribuição de tarefas (baseado no diagrama de classes). Teste do software

Nesta atividade uma equipe deve implantar o

software no Robô, executar o teste e retroalimentar o processo de desenvolvimento, se for o caso.

Validação do teste.

Entrega final Uma equipe deve entregar o produto final na sala de reuniões.

Robô com o Software Instalado.

Quadro 13 - Conjunto de artefatos obrigatórios

Além das 4 equipes, responsáveis pelas atividades descritas no Quadro 13, dois sites adicionais foram criados. O primeiro, denominado logística, cuja responsabilidade é o transporte de recursos físicos (componentes mecânicos e elétricos) do robô. O segundo o Orquestrador do projeto.

Nas primeiras atividades do processo, os sites precisaram negociar componentes. Tal negociação envolvia preço dos componentes e o custo do transporte. O site Logística deslocava componentes entre um site e outro. Desta maneira durante a execução do experimento os sites não tinham contato presencial entre os membros de grupos distintos.

O site Orquestrador foi responsável em atender dúvidas pertinentes ao projeto e a execução do processo. Havia um repositório contendo os modelos de documentação, a base histórica e os tutoriais, referentes ao desenvolvimento do software e montagem do produto. Para viabilizar o monitoramento de todas as interações, todos os grupos utilizaram uma conta já cadastrada em um ambiente de

groupware. Tal ambiente permitiu os participantes utilizarem email, chat e

execução do projeto. Tais visitas visaram a coleta dados associados às questões humanas como o relacionamento intra e extra site dos stakeholders; e também auxiliar em possíveis problemas ligados à técnica ou tecnologia utilizada para a comunicação.

Criou-se um cliente fictício para no projeto. A função deste personagem era a determinação do escopo e das restrições do projeto. Estas restrições impossibilitou que o produto fosse desenvolvido e entregue a partir de uma única equipe e obrigou-as a se comunicarem a fim de negociarem peças e serviços, gerando interações necessárias para a coleta dos dados objetivados pelo projeto. Estas condições propiciaram uma relação de parceria e de competição entre os

sites, característica presente em um cenário real de mercado (KAHAI; CARROLL;

JESTICE, 2007).

A Figura 11, indica o processo de execução do experimento, separado em 6 etapas. A primeira etapa contempla a definição dos grupos e a localização física de cada participante. A segunda etapa representa uma reunião presencial com todos os envolvidos. Nesta é apresentado o projeto e os artefatos iniciais de cada site. Os participantes são isolados em salas separadas na etapa 3. A etapa 4 representa a execução do projeto (montagem e desenvolvimento do software). A etapa 5 representa a entrega do produto final, enquanto que a próxima etapa, a 6, contempla o encerramento do projeto.

Figura 11 - Processo de execução do experimento

4.3.3 Hipótese

As hipóteses são suposições que compõem a base da investigação científica a ser comprovada. Trata-se de uma formulação genérica sobre os possíveis relacionamentos das variáveis existentes no universo objeto de pesquisa. As hipóteses são estabelecidas como respostas temporárias e plausíveis às situações intrínsecas. Sua comprovação se dá por meio de pesquisas (MARCONI; LAKATOS, 2003).

Na consolidação do protocolo, proposto no capítulo 3, considerou-se a premissa que em todo projeto de DDS se executa procedimentos de comunicação é verdadeira. Tal ponderação é constatada nos trabalhos de Goncalves, Dos Santos e L’Erario (2013); e Goncalves et al. (2013, 2014). A questão principal, investigada neste trabalho desencadeia as hipóteses, alicerçadas nas teorias apresentadas no capítulo 2 – revisão bibliográfica. A questão principal deste trabalho é: É possível

sistematizar a comunicação em projetos de desenvolvimento distribuído de software em uma estrutura de camadas?

A partir desta pergunta levantou-se a hipótese que será tratada neste trabalho:

Para avaliação desta hipótese, um conjunto de questões foi desenvolvido e apresentado por meio do Quadro 14. As resoluções de tais questões levantam os indícios que permearão a validação da hipótese.

H0 A comunicação pode ser sistematizada com a estrutura de camadas proposta

P1 Existem indícios de que não seja possível a estruturação da comunicação em camadas?

P2

Os resultados obtidos por meio dos trabalhos anteriores (GONCALVES; DOS SANTOS; L’ERARIO, 2013), (GONCALVES et al., 2014) e (GONCALVES et al., 2013) se mantém em camadas mais superiores? Tais resultados são limitados ao escopo de uma

interação?

P3 Como analisar informações obtidas a partir de interações entre sites?

P4 É possível delimitar as funcionalidades de cada camada, de maneira que tais

funcionalidades intercomunicam somente com suas adjacentes?

Quadro 14 - Perguntas investigadas para a hipótese 0 – H0

4.3.4 Variáveis

Marconi e Lakatos (2003), asseguram que, em um ambiente de pesquisa, as variáveis são os objetos conceituais que expressam valores como quantidades, qualidades, características, e outros. Segundo Bocco, Cruz-Lemus e Velthuis (2014), em um experimento pode-se encontrar diversos tipos de variáveis como as independentes, as dependentes, as aleatórias, as controladas e as extrínsecas. O Quadro 15apresenta as definições dos tipos citados:

Tipos de

variáveis Definições

independente

trata-se de um elemento determinante para o resultado; pode interferir no comportamento outra variável (dependente);pode ser manipulada pelo investigador a fim de garantir vinculação entre os resultados obtidos a um fenômeno observado ou a ser descoberto (MARCONI; LAKATOS, 2003);

dependente

representa aquilo que se deseja descobrir; é influenciada por variáveis independentes a medida que o investigador manipula esta variável (independente) (MARCONI; LAKATOS, 2003);

aleatórias não são controladas, devem ser tratadas como um acaso, um erro aleatório (BOCCO; CRUZ-LEMUS; VELTHUIS, 2014);

controladas com baixa ou nenhuma possibilidade de sofrer influência por outras variáveis, considerada um variável independente (MARCONI; LAKATOS, 2003);

Extrínseca

variável externa ao experimento, utilizada para verificar erros na compreensão da relação entre uma variável independente e dependente (MARCONI; LAKATOS, 2003).

Quadro 15 - Definições das variáveis Fonte: Marconi e Lakatos (2003)

Neste experimento, foram definidas 3 variáveis independentes, ou seja, aquelas manipuladas pelo investigador para estudar seus efeitos sobre as variáveis dependentes que estão sendo observadas; e estão relacionadas à configuração do projeto, que o tornou semelhante ao DDS:

a) dispersão física: como apresentado na seção 4.3.2 deste capítulo, os sites foram separados fisicamente e a comunicação entre eles deu-se por apenas por meio de

groupwares;

b) controle quanto às técnicas e tecnologias de comunicação: de acordo com a seção 4.3.6, durante a execução foram utilizadas 4 ferramentas para comunicação sendo email, mensagens instantâneas e videoconferência; acesso a servidor de arquivos e reuniões presenciais com o site Orquestrador, sendo que este último tipo só acorreu com o Orquestrador a fim de apresentar diretivas de execução do projeto; c) as regras de construção do robô: de acordo com as regras apresentadas a seção 4.3.2 deste capítulo, o cliente fictício condicionou que o robô não deveria ser construído em sua totalidade por um único site.

Com a finalidade de validar a hipótese H0, apresentada por meio do Quadro 14 da seção anterior, foram criadas 4 variáveis dependentes:

a) identificação de propósitos: como afirmado no capítulo 2, embora os estudos de Fuks et al. (2008) é utilizado para embasar este trabalho, e que nestes estudos ele aponta propósitos bem definidos, neste trabalho compreende-se a diversidade e quantidade dos propósitos estão relacionados às peculiaridades do projeto. Para este estudo almeja-se identificar a quantidade e os tipos de propósitos gerados no experimento. Tal medida é um estímulo para as comparações futuras na replicação deste experimento;

b) unidade de comunicação: esta variável tem sua métrica como verdadeiro, falso ou parcialmente verdadeiro. É identificada a partir do resultado das interações entre os sites. O estudo dela permeia a possibilidade da estruturação do protocolo, ou constata que tal protocolo seja improvável uma vez que o experimento não possibilitou tal mapeamento;

c) diversidade de técnicas e tecnologias utilizadas para interações para um mesmo propósito: esta variável mede a quantidade de reconfigurações da classe de transmissão para um mesmo propósito. Caso seu valor seja igual ou maior que 1,

entende-se que houve a estruturação da segunda camada do protocolo que, de acordo com a Figura 5 do capítulo 3, denomina-se classe de transmissão;

d) avaliação da maturidade da comunicação: esta variável pode assumir valores de 1 a 5 e deriva-se da aplicação do método de avaliação da maturidade da comunicação definido por Goncalves et al. (2013). Usada para quantificar e classificar a comunicação na estruturação do protocolo.

4.3.5 Seleção dos Sujeitos e Configuração da Amostragem

Conforme indicado na seção 4.3.2 deste capítulo, a amostragem deste experimento foi composta por alunos do PPGI, que estão atuantes no mercado de TI há pelo menos 3 anos. Todos contemplam experiência no desenvolvimento de projetos. Por uma questão de privacidade os participantes tiveram seus nomes omitidos.

Os alunos foram divididos, de maneira aleatória, em grupos de pelo menos 4 pessoas por site. Cada grupo tinha autonomia na execução de tarefas, precisavam apenas seguir o macroprocesso, descrito por meio da Figura 8.

No total foram criados 4 grupos e não houve um grupo com mais de 4 pessoas, portanto, no que tange às questões quantitativas e qualitativas, o experimento foi equilibrado.

É importante salientar que os participantes foram condicionados a resolverem um problema, que foi desenvolver um projeto. Não foi mencionado a eles que a comunicação gerada entre os sites seria avaliada, portanto, não houve interferência no projeto, com relação a comunicação.

4.3.6 Instrumentação

O processo de execução do experimento, objeto deste trabalho, necessitou de amparo instrumental. Tal amparo cobriu as seguintes arestas do processo:

a) providenciar mecanismos de comunicação entre todos os sites por meio do uso de groupwares: neste caso, todos os sites devem acessar um mesmo ambiente de CSCW/Groupware, com o propósito de gerar interações e obter respostas sobre as

circunstancias que envolvem as negociações. O ambiente configurado deve propiciar as interações síncrona e assíncrona entre todos os grupos; e possibilitar a troca de artefatos;

b) possibilitar a coleta de todas as interações entre os sites: após a execução do projeto, a instrumentação deverá permitir que todos os dados e artefatos trocados entre os sites sejam armazenados em uma planilha cuja indexação denota a temporalidade da execução das interações;

c) possibilitar a coleta das informações referentes ao acesso dos sites na base de conhecimento: o acesso dos sites à base de conhecimento deve ser monitorado temporalmente para que fosse possível a manipulação dos dados.

Após a definição dos requisitos de instrumentação, as seguintes ferramentas foram utilizadas na execução do experimento:

a) Google - Gmail e Hangout: as contas foram criadas previamente e o histórico de mensagens foi armazenado. Os participantes puderam efetuar interações com apoio de videoconferência, email e chat;

b) Moodle: utilizado para servir como base de conhecimento composta por modelos, tutoriais e históricos pode ser utilizada pelos participantes. Além disso, o Moodle gerou um relatório de acesso a estes recursos.

5 RESULTADOS

Este capítulo apresenta o resultado da aplicação do processo apresentado no capítulo 4. Aqui são apresentados aspectos mais técnicos no que tange a obtenção, tratamento e análise dos dados como proposto pelo item d da seção 4.2 do capítulo 4 ao apresentar os constructos do método de pesquisa. Também são apresentados detalhes da execução do experimento.

Dans le document The DART-Europe E-theses Portal (Page 116-122)