Planejamento

O planejamento de nosso estudo de caso inclui a descrição das questões de pesquisa, dos sujeitos que participaram do estudo, do objeto utilizado, das unidades de análise, dos artefatos avaliados e dos critérios de avaliação, assim como dos procedimentos empregados para coleta de dados.

Questões de Pesquisa

Para alcançar os objetivos propostos, nosso estudo de caso deve responder às seguintes questões de pesquisa:

1. Quando adotamos POP, os estudantes documentam requisitos?

2. Quais tipos de defeitos são mais comuns nos documentos de especificação produzidos pelos estudantes que adotam POP?

3. Ao concluir o ciclo de POP, os programas produzidos pelos estudantes atendem aos requisitos requeridos pelo cliente-tutor?

4. Quais as dificuldades apresentadas pelos estudantes ao praticarem as atividades de POP? 5. Quais as dificuldades apresentadas pelos clientes-tutores para a condução de POP em sala de

aula?

Para responder às três primeiras questões de pesquisa, nós adotamos os critérios descritos na Seção Artefatos Avaliados e Critérios de Avaliação, descrita na página 41. Para responder às duas últimas questões, além da observação, nós adotamos dois questionários: um, aplicado aos estudantes; e outro, aos clientes-tutores. Nós apresentamos os questionários no Apêndice D.

Sujeitos

Nós aplicamos POP com os estudantes matriculados na disciplina de Laboratório de Programação I1, período 2009.1, do curso de Ciência da Computação da UFCG. Esta disciplina possuía três turmas, sendo a terceira turma composta apenas por estudantes repetentes.

Em nosso estudo, nós consideramos apenas os estudantes iniciantes, que compunham as Turmas 1 e 2. Considerando que a divisão dos estudantes por turma ocorre de forma aleatória e que o mesmo

4.1 Estudo de Caso 1 40

tratamento (POP) foi aplicado, igualmente, em ambas as turmas, nós não faremos distinções entre as Turma 1 e 2. Portanto, nossos sujeitos foram 70 estudantes iniciantes de programação.

Objeto

O objeto usado no estudo de caso foi uma lista de problemas, contendo três problemas mal definidos, os quais deveriam ser especificados e solucionados pelos estudantes seguindo a metodologia POP. Nós utilizamos três problemas a fim de permitir que aprendizagem dos estudantes fosse reforçada pela repetição das atividades do ciclo de resolução de problemas.

Nos Quadros 4.1, 4.2 e 4.3, nós apresentamos os enunciados desses problemas. Para solucioná- los, os programas dos estudantes teriam que atender a 17, 12 e 26 requisitos, respectivamente. Nós descrevemos esses requisitos no Apêndice E.

Quadro 4.1: Problema 1 – Poupança programada.

Enunciado

Em função da crise financeira mundial tem crescido os investimentos na poupança programada, pois é um investimento rentável e com baixíssimo risco. Um professor de administração financeira da UFCG deseja simular investimentos na poupança programada para ensinar seus alunos a driblarem a crise. Faça um programa que atenda a solicitação desse professor, considerando que a poupança rende 5% ao mês, sendo tempo e capital programados pelo investidor com isenção total do imposto de renda.

Defeitos

Esse problema apresenta falta de informações, ambigüidades e informações irrelevantes.

Falta de Informações: não são informadas quais são as entradas, saídas e como elas devem ser formatadas; quais os cálculos que devem ser efetuados e as restrições que o programa deve obedecer. Também não está claro o tipo de rendimento da poupança;

Informações Ambíguas: a expressão “sendo tempo e capital programados pelo investidor com

isenção total do imposto de renda” refere-se ao fato de que a poupança programada é um investi-

mento que tem isenção do imposto de renda? ou, que somente pode aplicar na poupança o investidor isento do imposto de renda?

Informações irrelevantes:a frase inicial que fala da crise mundial é desnecessária para o entendi- mento e resolução do problema. Ela foi inserida apenas para deixar o problema mais interessante.

Unidade de Análise

Conforme definido em POP, a especificação dos requisitos deve ser realizada em grupo e a implemen- tação, individualmente. Assim, nosso estudo de caso possui duas unidades de análise: o grupo; e o

4.1 Estudo de Caso 1 41

Quadro 4.2: Problema 2 – Freqüência das palavras.

Enunciado

Um professor de português precisa de um programa que dado um parágrafo, apresente com que freqüência as palavras se repetem.

Defeitos

Falta de Informações: não são informadas, por exemplo, as formatações de entrada e saída; se há limites para o tamanho do parágrafo; se caracteres especiais e números devem ou não ser aceitos; ou, se deve haver distinção de caracteres maiúsculos e minúsculos.

Quadro 4.3: Problema 3 – Jogo da forca.

Enunciado

Este mesmo professor de português gostaria de desenvolver uma atividade lúdica e educativa com seus alunos e por isso deseja que você faça um programa para adivinhação de palavras, similar ao jogo da forca.

Defeitos

Falta de Informações: não são informadas, por exemplo, as formatações de entrada e saída; se a forca deve ser jogada por dois jogadores humanos or entre um humano e a máquina; se deveria existir uma base de dados de palavras e se a escolha delas deveria ser feita de forma randômica; se haveria necessidade de armazenar login e pontuação dos jogadores.

estudante, individualmente.

Artefatos Avaliados e Critérios de Avaliação

Nós avaliamos a versão final de dois artefatos: documentos de especificação e programas. Para cada artefato, os procedimentos para avaliação, assim como os critérios adotados são definidos como segue. Documento de Especificação. Para avaliação dos documentos de especificação nós adotamos duas variáveis: requisitos documentados (RD) e requisitos documentados corretamente (RC). Para analisá-las, nós realizamos inspeções nos documentos de especificação dos estudantes utilizando a técnica de leitura baseada em defeitos (Defect-Based Reading – DBR) [Porter et al. 1995]. Nós escolhemos esta técnica por considerá-la simples de ser aplicada e adequada ao nosso estudo, uma vez que era nosso propósito detectar os defeitos comuns nas especificações dos estudantes.

Na versão original de DBR, a detecção de defeitos era realizada em documentos de requisitos des- critos em SCR [Heninger 1980], uma notação formal para sistemas de controle de processo dirigido a eventos.

No nosso caso, nós fizemos uma adaptação desta técnica. Nós utilizamos documentos de especi- ficação escritos em linguagem natural e a técnica foi adotada para focar sobre uma classe de defeitos

4.1 Estudo de Caso 1 42

em um conjunto pré-definido de requisitos. Este conjunto refere-se aos requisitos que os programas deveriam atender para solucionar os problemas propostos, conforme descrevemos no Apêndice E.

Para classificar os tipos de defeitos presentes nos documentos de especificação dos estudantes, nós adotamos uma versão simplificada da taxonomia de defeitos definida por Shull et al. [2000] que é apresentada no Quadro 4.4. Para aumentar a fidelidade da avaliação, os documentos foram inspecionados por duas pessoas, trabalhando juntas.

Quadro 4.4: Taxonomia de defeitos.

Tipo Descrição

Requisito Omitido Algum requisito que foi omitido no documento de especificação. Requisitos Ambíguo Algum requisito que foi descrito no documento de especificação

de forma ambígua, causando duplo sentido.

Requisito Contraditório Dois requisitos que se contradizem mutuamente ou expressão ações que não podem ser ambas corretas.

Requisito Incorreto Algum requisito que consta no documento de especificação, mas não descreve corretamente o problema.

Requisito Irrelevante Algum requisito que consta no documento de especificação, mas não é importante, nem necessário ao entendimento do problema.

Nós definimos as variáveis requisitos documentados (RD) e requisitos documentados correta-

mente (RC) como segue:

• Requisitos Documentados (RD): corresponde a porcentagem de requisitos documentados pelo

grupo de estudantes.

RD = QRD

QRR× 100% Na qual:

– QRD : Quantidade de requisitos documentados pelo grupo de estudantes;

– QRR: Quantidade de requisitos de referência, estabelecidos na especificação de cada programa, conforme consta no Apêndice E.

• Requisitos Documentados Corretamente (RC): corresponde a porcentagem de requisitos docu-

4.1 Estudo de Caso 1 43

RC = QRD− QRDf

QRD × 100%

Na qual:

– QRD : Quantidade de requisitos documentados pelo grupo de estudantes;

– QRDf: Quantidade de requisitos documentados com defeito, contemplando requisitos

ambíguos, contraditórios, incorretos e irrelevantes, conforme Quadro 4.4.

Programas. Nós avaliamos os programas dos estudantes levando em consideração a variável

requisitos atendidos (RA) que é descrita como segue.

• Requisitos Atendidos (RA): corresponde a porcentagem de requisitos corretamente implemen-

tados (atendidos) pelo programa do estudante.

RA = QRA

QRR× 100% Na qual:

– QRA : Quantidade de requisitos atendidos (implementados) pelo programa do estudante; – QRR: Quantidade de requisitos de referência, estabelecidos na especificação de cada

programa, conforme consta no Apêndice E.

Coleta de Dados

No estudo de caso, nós coletamos os seguintes dados: (i) documentos de especificação dos gru- pos; (ii) código fonte dos programas e testes automáticos dos estudantes; (iii) diálogos dos estu- dantes registrados nos grupos de discussão; (iv) respostas aos questionários aplicados aos estudantes e clientes-tutores (Apêndice D); e, (v) anotações sobre o comportamento dos estudantes durante a realização das atividades de POP.