RELATRIO TCNICO

RTES590/02



Introduo
Engenharia de Software Experimental

Guilherme Horta Travassos
ght@cos.ufrj.br

Dmytro Gurov

Edgar Augusto Gurgel do Amaral


Programa de Engenharia de Sistemas e Computao
COPPE / UFRJ






Rio de Janeiro, 2002
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
2
Contedo
1. INTRODUO.................................................................................................................................. 3
2. OBJETIVOS DA EXPERIMENTAO........................................................................................ 5
3. DESCRIO GERAL DA EXPERIMENTAO........................................................................ 7
3.1 VOCABULRIO DA EXPERIMENTAO .................................................................................. 7
3.2 PRINCPIOS DA ORGANIZAO DO EXPERIMENTO................................................................ 9
3.3 MEDIO ............................................................................................................................. 10
3.4 VALIDADE ............................................................................................................................ 12
4. TIPOS DE EXPERIMENTOS ....................................................................................................... 15
5. PROCESSO DE EXPERIMENTAO........................................................................................ 19
5.1 METODOLOGIA.................................................................................................................... 19
5.2 FASES DO EXPERIMENTO ..................................................................................................... 21
5.3 EMPACOTAMENTO............................................................................................................... 23
6. CONCLUSES................................................................................................................................ 26
REFERNCIAS................................................................................................................................... 28
GLOSSRIO DE PALAVRAS EM INGLS................................................................................... 30
ANEXO 1: O ESTUDO EXPERIMENTAL...................................................................................... 31
ANEXO 2: CONCEITOS ENVOLVIDOS NUM PACOTE DE EXPERIMENTO...................... 49

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
3
1. INTRODUO

Experimentao o centro do processo cientfico. Somente experimentos verificam as teorias.
Somente experimentos podem explorar os fatores crticos e dar luz ao fenmeno novo para que as
teorias possam ser formuladas e corrigidas. Experimentao oferece o modo sistemtico, disciplinado,
computvel e controlado para avaliao da atividade humana. Novos mtodos, tcnicas, linguagens e
ferramentas no deveriam ser apenas sugeridos, publicados ou apresentados para venda sem
experimentao e validao. Portanto, preciso avaliar novas invenes e sugestes em comparao
com as existentes.
Quando falamos de Engenharia de Software, a discusso concentra-se em se podemos
consider-la cincia ou engenharia. Esta questo refere o duplo carter do software. Por um lado, a
Engenharia de Software considera o processo de criao do produto (software) e desse ponto de vista
ela possui as caractersticas explicitas de produo ou engenharia. Por outro lado, os aspectos
relacionados a time-to-market e competio exigem a melhoria contnua e seqencial da qualidade do
processo e do produto. neste contexto que a parte cientifica de Engenharia de Software se apresenta.
Portanto, as metodologias especficas so necessrias para ajudar a estabelecer uma base de
engenharia e de cincia para a Engenharia de Software. Existem quatro mtodos relevantes para
conduo de experimentos na rea de Engenharia de Software: cientfico, de engenharia, experimental,
e analtico [Wohlin00].
O mtodo cientfico observa o mundo, sugere o modelo ou a teoria de comportamento, mede e
analisa, verifica as hipteses do modelo ou da teoria. Isto um paradigma indutivo. Esse mtodo pode
ser utilizado quando se tenta entender, por exemplo, o processo, o produto de software, ambiente. Ele
tenta extrair do mundo algum modelo que possa explicar um fenmeno, e avaliar se o modelo
realmente representativo para o fenmeno que est sob observao. Isto uma abordagem para
construo de modelos.
O mtodo de engenharia observa as solues existentes, sugere as solues mais adequadas,
desenvolve, mede e analisa, e repete at que nenhuma melhoria adicional seja possvel. Isto uma
abordagem orientada melhoria evolutiva que assume a existncia de algum modelo do processo ou
produto de software e modifica este modelo com propsito de melhorar os objetos do estudo.
O mtodo experimental sugere o modelo, desenvolve o mtodo qualitativo e/ou quantitativo,
aplica um experimento, mede e analisa, avalia o modelo e repete o processo. Isto uma abordagem
orientada melhoria revolucionria. O processo se inicia com o levantamento de um modelo novo,
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
4
no necessariamente baseado em um modelo j existente, e tenta estudar o efeito do processo ou
produto sugerido pelo modelo novo.
O mtodo analtico (ou matemtico) sugere uma teoria formal, desenvolve a teoria, deriva os
resultados e se possvel, compara-a com as observaes empricas. Isto um mtodo dedutivo que no
precisa de um projeto experimental no sentido estatstico, mas oferece uma base analtica para o
desenvolvimento de modelos.
Supe-se que a abordagem mais apropriada para a experimentao na rea de Engenharia de
Software seja o mtodo experimental que considera a proposio e avaliao do modelo com os
estudos experimentais. Entretanto, existe a possibilidade da utilizao de outros mtodos. s vezes
necessrio aplic-los para a resoluo dos problemas de Engenharia de Software. Por exemplo, o
mtodo cientfico pode ser utilizado para compreender a maneira como o software est sendo
construdo por uma organizao para ver se a ferramenta pode ser utilizada para automatizar o
processo; o mtodo de engenharia ajuda a demonstrar que uma ferramenta possui um desempenho
melhor do que outra; o mtodo analtico pode provar modelos matemticos para conceitos, como o
crescimento da confiabilidade, a complexidade do software, o projeto ou cdigo propenso a erro.
importante notar que experimentos no provam nada. verdade que nenhum experimento
oferece prova com certeza absoluta. Os experimentos verificam a previso terica de encontro
realidade. A comunidade aceita uma teoria se todos os fatos conhecidos dentro de seu domnio possam
ser deduzidos da teoria, possui uma verificao experimental extensa e prediz o novo fenmeno
corretamente.
Uma informao mais detalhada a respeito do papel da experimentao na rea de Engenharia
de Software pode ser encontrada em [Basili96].
Com a finalidade de exemplificar conceitos bsicos relacionados experimentao este relatrio
tcnico apresenta a definio e a anlise de um estudo que foi conduzido durante o primeiro curso de
Engenharia de Software Experimental no terceiro bloco aulas de 2001 na COPPE / UFRJ, Programa de
Engenharia de Sistemas e Computao.
O objetivo principal do estudo definir se o curso bsico de Engenharia de Software oferece as
competncias necessrias ao desenvolvimento de software pessoal do ponto de vista dos seus alunos.
Os participantes escolhidos para o estudo foram os alunos da ps-graduao do curso de Engenharia
de Software. Os questionrios utilizados para a coleta de dados so baseados nas competncias do
currculo mnimo da SBC (http://www.sbc.org.br).
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
5
2. OBJETIVOS DA EXPERIMENTAO

Os objetivos relacionados execuo de experimentos em Engenharia de Software so a
caracterizao, avaliao, previso, controle e melhoria a respeito de produtos, processos, recursos,
modelos, teorias entre outros. A importncia e o esforo aumentam de um experimento com o objetivo
"caracterizao" a um experimento com o objetivo "melhoria". Isso significa que bastante simples
conduzir um experimento com a finalidade de caracterizao respondendo questes do tipo "o que est
acontecendo?". mais difcil medir algo, por exemplo, um processo ou produto e defini-lo "quo bom
isto?". Os experimentos com a finalidade de previso alm da medio precisam de meios de
estimativa para mostrar a possibilidade de:"posso estimar algo no futuro?". Para atender a finalidade
de controle deve existir a possibilidade de gerenciar os atributos de um processo ou produto e dar a
resposta a "posso manipular o evento?". Finalmente, a finalidade da melhoria supe que possamos
caracterizar, avaliar, predizer e controlar, e h os objetivos da melhoria de um processo ou produto que
possam ser atingidos respondendo a ltima questo "posso melhorar o evento?".
Um exemplo da definio dos objetivos de um estudo experimental se encontra no Anexo 1 (1.1
1.3).
A literatura oferece algumas outras definies dos objetivos da experimentao em Engenharia
de Software. Em [Conradi01] so listados:
Para compreender a natureza dos processos da informao os pesquisadores devem
observar o fenmeno, encontrar explicao, formular a teoria, e verific-la.
A experimentao pode ajudar a construir uma base de conhecimento confivel e reduzir
assim incerteza sobre quais teorias, ferramentas, e metodologias so adequadas.
A observao e experimentao podem levar a novos e teis meios da introspeco, e abrir
novas reas de investigao. A experimentao pode encontrar novas reas onde a
engenharia age lentamente.
A experimentao pode acelerar o processo eliminando abordagens inteis e suposies
errneas. A experimentao ajuda tambm a orientar a engenharia e a teoria nas direes
promissoras de pesquisa.
Os experimentos podem ser custosos, mas um experimento significativo geralmente pode
se encaixar no oramento de um pequeno laboratrio. Por outro lado, um experimento caro
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
6
pode valer a pena muito mais do que seu custo e, por exemplo, oferecer companhia
liderana de trs, quatro ou cinco anos sobre a competio.
O crescimento do nmero de trabalhos cientficos com uma validao emprica
significativa possui a boa chance de acelerar o processo de formao da Engenharia de
Software como cincia. As idias duvidosas sero rejeitadas mais rapidamente e os
pesquisadores podero concentrar-se nas abordagens promissoras.
A tecnologia vem se modificando rapidamente. As mudanas sempre trazem ou eliminam
as suposies. Os pesquisadores devem ento antecipar as mudanas nas suposies e
aplicar os experimentos para explorar as conseqncias dessas mudanas.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
7
3. DESCRIO GERAL DA EXPERIMENTAO
3.1 Vocabulrio da experimentao
Os elementos principais do experimento so as variveis, os objetos, os participantes, o contexto
do experimento, hipteses, e o tipo de projeto do experimento.
H dois tipos de variveis do experimento: dependentes e independentes. As variveis
independentes referem-se entrada do processo de experimentao. Essas variveis tambm se
chamam "fatores" e apresentam a causa que afeta o resultado do processo de experimentao. O
prprio valor de um fator se chama "tratamento". As variveis dependentes referem-se sada do
processo de experimentao. Essas variveis apresentam o efeito que causado pelos fatores do
experimento. O prprio valor de uma varivel dependente se chama "resultado".
A Figura 1 apresenta os relacionamentos entre os conceitos descritos acima.
O anexo 1 (2.5) contm um exemplo da descrio das variveis.
O objeto uma ferramenta usada para verificar o relacionamento causa-efeito numa teoria.
Durante a execuo do experimento os tratamentos esto sendo aplicados ao conjunto dos objetos e
assim o resultado est sendo avaliado.
Observao
Causa Efeito
Tratamento Resultado
Teoria
Construo
causa-efeito
Construo
tratamento-resultado
Varivel independente Varivel dependente
Objetivos de experimento
Execuo de experimento
Figura 1. Os conceitos de um experimento [Wohlin00]
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
8
Os objetos junto com o sistema de medio e diretrizes da execuo do experimento compem a
instrumentao do experimento. O anexo 1 (2.2 e 3.1-3.2) apresenta um exemplo de instrumentao.
Os participantes so os indivduos que foram especialmente selecionados da populao sob
interesse para conduzir o experimento. Isso significa que para generalizar os resultados de um
experimento a uma populao desejada, o conjunto de participantes deve ser representativo para
aquela populao. Para atingir a meta mencionada os parmetros como o modo de seleo dos
participantes e o tamanho do conjunto selecionado que influem o resultado do experimento, devem ser
considerados. A princpio, quanto maior a variedade da populao tanto maior deve ser o tamanho do
conjunto de participantes.
O anexo 1 (2.4) contm um exemplo da descrio da seleo dos participantes.
O contexto do experimento composto das condies em que o experimento est sendo
executado. O contexto pode ser caracterizado de acordo s trs dimenses:
In-vitro vs. In-vivo. ........................O primeiro refere-se experimentao no laboratrio sob as
condies controladas. O segundo considera o estudo de um
projeto real.
Alunos vs. Profissionais.................Define a equipe que vai executar o experimento.
Problema de sala de aula vs.
Problema real .................................Mostra o tamanho do problema que est sendo estudado.
Especfico vs. Geral. ......................Mostra se os resultados do experimento so vlidos para um
contexto particular ou para o domnio da Engenharia de
Software inteiro.
O anexo 1 (2.3) contm um exemplo da descrio do contexto do experimento.
Um experimento geralmente formulado atravs de hipteses. A hiptese principal se chama
hiptese nula e declara que no h nenhum relacionamento estatisticamente significante entre a causa e
o efeito. O objetivo principal do experimento , ento, rejeitar a hiptese nula a favor de uma ou
algumas hipteses alternativas. A deciso sobre rejeio da hiptese nula pode ser tomada baseado nos
resultados da sua verificao utilizando um teste estatstico.
A verificao das hipteses sempre lida com algum tipo de risco que implica que um erro pode
acontecer. O erro do primeiro tipo (type-I-error) acontece quando o teste estatstico indica o
relacionamento mesmo que no exista nenhum relacionamento real. A probabilidade do erro desse tipo
pode ser avaliada como:
P (type-I-error) = P (H0 rejeitada |H0 verdadeira)
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
9
O erro do segundo tipo (type-II-error) acontece quando o teste estatstico no indica o
relacionamento mesmo que efetivamente exista um relacionamento. A probabilidade de erro desse tipo
pode ser avaliada como:
P (type-II-error) = P (H0 no rejeitada |H0 falsa)
O tamanho do erro durante a verificao das hipteses depende da potncia do teste estatstico.
A potncia do teste implica a probabilidade de que o teste vai encontrar o relacionamento mesmo que
a hiptese nula seja falsa. A potncia pode ser avaliada como:
Potncia = P (H0 rejeitada |H0 falsa) = 1 - P (type-II-error).
O teste estatstico com a maior potncia deve ser escolhido. Informao mais detalhada a
respeito de testes e potncia dos testes pode ser encontrada em [Miller97].
O anexo 1 (2.1) apresenta a descrio da hiptese nula e das hipteses alternativas do estudo.
O projeto do experimento determina a maneira como um experimento ser conduzido. A deciso
sobre alocao dos objetos e dos participantes feita nesse momento. Tambm a maneira como os
tratamentos sero aplicados aos objetos definida.
A combinao dos objetos, participantes e tratamentos se chama teste experimental ou "trial". A
quantidade e a seqncia dos testes experimentais definem o projeto do experimento. A informao
mais detalhada a respeito do projeto do experimento pode ser encontrada em [Juristo98].

3.2 Princpios da organizao do experimento
A experimentao na Engenharia de Software quanto a experimentao em geral, presume um
conjunto dos princpios que devem ser considerados ao longo do processo de organizao e execuo
do experimento tal como no tempo da anlise e interpretao dos resultados (veja seo 5.2).
Os princpios gerais da organizao do experimento so a aleatoriedade, o agrupamento
(blocking), e o balanceamento.
Todos os mtodos estatsticos utilizados para a anlise emprica requerem que a observao seja
feita a partir das variveis independentes e aleatrias. Para atingir essa exigncia usa-se aleatoriedade.
A aleatoriedade implica que a alocao dos objetos e dos participantes e a ordem da execuo dos
testes experimentais sejam aleatrias. A aleatoriedade utilizada para evitar o efeito de algum fator
que de outra maneira possa estar presente, e tambm para selecionar os participantes que sejam
representativos para a populao do interesse.
Se houver um fator no projeto do experimento que provavelmente tenha um efeito sobre o
resultado, mas esse efeito no interessante para os pesquisadores, o agrupamento deve ser utilizado.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
10
O agrupamento sistematicamente elimina o efeito indesejado durante a comparao dos tratamentos.
Dentro do bloco o efeito indesejado indiferente e pode ser eliminado da considerao. O
agrupamento aumenta a preciso do experimento.
Se o experimento est organizado de uma forma que todos os tratamentos tm o nmero dos
participantes igual, o projeto do experimento balanceado. O balanceamento desejvel porque isso
simplifica e melhora a anlise estatstica dos dados experimentais.
Os princpios descritos na maior parte se referem ao projeto do experimento. Outro princpio
importante da experimentao que se refere potncia dos resultados do experimento a repetio do
experimento. Um experimento deve ser adequadamente empacotado para permitir a outros
investigadores reproduzir os resultados. A repetio importante porque implica que as variveis
imprevistas no esto afetando os resultados, e assegura que no h nenhuma confuso entre dois
efeitos. Os resultados dos experimentos no podem ser amplamente aceitados sem que a repetio
interna ou externa seja aplicada. A informao mais detalhada a respeito da essncia da repetio dos
experimentos pode ser encontrada em [Brooks96].
Alm disso, h alguns princpios que devem ser considerados a respeito das caractersticas
particulares da experimentao na rea de Engenharia de Software.
O controle local se refere habilidade de modificao do tratamento aplicado a cada objeto. Por
exemplo, o estudo de caso geralmente tem o controle fraco sobre os tratamentos. O controle local o
maior problema da experimentao na cincia de computao desde que a maioria dos tratamentos
incorre em despesas de custo ou de tempo significativas.
Tambm importante considerar o impacto que o dado projeto do experimento tem sobre os
resultados do experimento. O mtodo de investigao pode ser passivo, ou seja, o objeto est sendo
estudado sem qualquer efeito sobre o objeto em si, ou ativo, ou seja, a interao com o objeto afeta o
seu comportamento.

3.3 Medio
A medio a parte central de um estudo experimental. A medio definida como o
mapeamento do mundo experimental para o mundo formal ou relacional. O objetivo principal desse
mapeamento caracterizar e manipular os atributos das entidades empricas da maneira formal. Ao
invs de fazer o julgamento diretamente a partir das entidades reais, os nmeros ou smbolos esto
atribudos a essas entidades, e o julgamento feito a partir desses nmeros e smbolos. O nmero ou
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
11
smbolo atribudo entidade por meio do mapeamento se chama medida. O atributo da entidade que
est sendo medida se chama mtrica.
O anexo 1 (1.4 e 2.2) apresenta um exemplo das mtricas usadas durante a coleta dos dados
experimentais.
O mapeamento pode ser feito de vrias maneiras. Os mapeamentos diferentes do mesmo atributo
se chamam escalas. A transformao de uma escala da medio para outra se chama rescaling ou
transformao admissvel. Se a afirmao verdadeira mesmo aps uma medida ser transformada em
escala diferente, essa afirmao chamada significativa, no caso contrrio chamada sem significado.
Existem quatro tipos de escalas: nominal, ordinal, intervalo, e razo. A escala nominal apresenta
o atributo de uma entidade como o nome ou smbolo. A classificao das entidades pode ser feita a
partir dos atributos nominalmente mapeados. A escala ordinal ordena as entidades segundo um critrio
definido. Nesse caso, as afirmaes como maior do que ou mais complexo do que podem
ser feitas. A escala do intervalo ordena os valores da mesma forma que a escala ordinal, mas
acrescenta a noo da distncia relativa entre as entidades. Na escala razo existe o valor do zero
significativo e a razo entre medidas significativa. A possibilidade de produzir as afirmaes
significativa, chamada tambm a potncia da escala cresce da escala nominal escala razo.
H duas dimenses das medidas: objetiva e subjetiva, direta e indireta. Se o valor da medida
depende somente do objeto em si a medida objetiva. A medida objetiva pode ser tomada vrias vezes
e o mesmo valor ser sempre recebido. Se o valor da medida depende ao mesmo tempo do objeto e da
perspectiva na qual o valor foi tomado, a medida subjetiva. A medida subjetiva pode tomar os
valores diferentes se medir o objeto vrias vezes. A medida direta aquela que no envolva a medio
de outros atributos. A medida indireta derivada das medidas de outros atributos.
Alm disso, a medio na Engenharia de Software caracterizada em termos dos atributos
internos e externos. Um atributo interno pode ser medido em termos do objeto em si. Esses atributos
geralmente so das medidas diretas. Um atributo externo pode ser medido somente a respeito dos
atributos de outros objetos. Os atributos externos so das medidas indiretas e devem ser derivados dos
atributos internos.
A medio na Engenharia de Software na maioria dos casos utiliza as prprias mtricas do
software. As mtricas do produto so usadas para medir o produto intermedirio ou final. As mtricas
do processo medem as caractersticas do processo do desenvolvimento de software. As mtricas do
recurso so usadas para medir os objetos tais como equipe, hardware, ferramentas, etc. necessrios ao
desenvolvimento de software.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
12
O objetivo principal da medio na Engenharia de Software aumentar a compreenso do
processo e do produto, control-los definindo antecipadamente as atividades corretivas e identificar as
possveis reas de melhoria.
A medio a base da abordagem bottom-up para melhoria do processo do desenvolvimento de
software. Essa abordagem implica a anlise detalhada das prticas de software, a seleo dos objetivos
de melhoria derivados dessa anlise, e a gerncia das atividades de melhoria sustentadas pela medio.
Um exemplo da abordagem descrita o Paradigma da Melhoria da Qualidade (Quality Improvement
Paradigm - QIP). QIP apresenta um framework do processo de melhoria sustentado pelos princpios do
paradigma Goal/Question/Metric (GQM). A informao mais detalhada a respeito da aplicao da
medio na melhoria do processo do desenvolvimento de software dirigida pelos objetivos pode ser
encontrada em [Solingen99]. A informao geral a respeito da aplicao da medio na rea de
Engenharia de Software pode ser encontrada em [SEL95].

3.4 Validade
A questo fundamental a respeito dos resultados do experimento quo validos so eles. Os
resultados devem ser vlidos para a populao da qual o conjunto de participantes foi recebido.
interessante tambm generalizar os resultados para uma populao mais ampla. Os resultados possuem
a validade adequada se so vlidos para a populao a qual tendem ser generalizados.
H quatro tipos da validade dos resultados do experimento: a validade de concluso, a validade
interna, a validade de construo, e a validade externa.
A validade de concluso relacionada habilidade de chegar a uma concluso correta a respeito
dos relacionamentos entre o tratamento e o resultado do experimento. Durante a avaliao da validade
de concluso necessrio considerar os conceitos como a escolha do teste estatstico, a escolha do
tamanho do conjunto dos participantes, a confiabilidade das medidas, e a confiabilidade da
implementao dos tratamentos.
Alguns problemas podem acontecer quando se lida com a validade da concluso. Se a potncia
do teste estatstico baixa, existe o risco alto que concluses errneas sejam tiradas. Alguns testes tm
condies especificas, por exemplo, a respeito da distribuio normal do conjunto dos participantes.
Os pesquisadores podem influenciar os resultados tentando receber o resultado especfico. As medidas
podem envolver o julgamento humano e, assim, os resultados diferentes podem ser recebidos caso um
objeto seja medido vrias vezes.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
13
A validade interna define se o relacionamento observado entre o tratamento e o resultado
causal, e no o resultado da influncia de outro fator que no controlado ou mesmo no foi medido.
Durante a avaliao da validade interna uma maior ateno deve ser prestada aos participantes, ou
seja, seleo da populao, maneira da diviso nas classes, ao modo da aplicao dos tratamentos,
e aos aspectos sociais.
Os problemas ou riscos relacionados a esse tipo de validade so ligados aos participantes. Por
exemplo, os participantes podem ficar cansados ou desanimados ou, ao contrrio, podem aprender ao
longo do estudo. A seleo dos voluntrios pode formar o conjunto dos participantes que no so
representativos para a populao. Uma instrumentao inadequadamente preparada pode ocasionar um
mal-entendido e afetar os resultados negativamente. Os grupos dos participantes podem produzir os
resultados diferentes por causa do comportamento e as habilidades diferentes. Os participantes que
receberam o tratamento menos interessante ou menos desejado, podem ser motivados a reduzir ou
inverter os resultados do experimento. Alm disso, aqueles que receberam o tratamento menos
interessante, podem deixam de terminar o estudo ou executar o estudo com o desempenho pior do que
sempre.
A validade de construo considera os relacionamentos entre a teoria e a observao, ou seja, se
o tratamento reflete a causa bem e o resultado reflete o efeito bem. Durante a avaliao da validade da
construo os aspectos relevantes ao projeto do experimento e os fatores humanos devem ser
considerados. Os problemas surgem por causa do comportamento incorreto do lado dos participantes
ou do experimentador. O experimento pode ser sub-representado e no oferecer a imagem completa da
teoria. Os participantes possam ser envolvidos em vrios estudos e, portanto, o efeito seja o resultado
da combinao dos tratamentos. Os participantes possam basear o seu comportamento nas suposies
sobre as hipteses. O ser humano sempre est tentando parecer melhor quando est sendo avaliado. Os
pesquisadores podem afetar os resultados (vis) projetando o estudo baseado naquilo que eles esperam
do experimento.
A validade externa define as condies que limitam a habilidade de generalizar os resultados de
um experimento para a prtica industrial. Durante a avaliao da validade externa a interao do
tratamento com as pessoas, o lugar e o tempo devem ser considerados. Os problemas podem acontecer
devido populao dos participantes no ser representativa populao sob interesse, a
instrumentao no ser adequada prtica industrial, e o experimento pode ser executado num dia ou
tempo especial que venha afetar os resultados.
A prioridade dos tipos da validade determinada segundo os objetivos da experimentao. Para
verificao de uma teoria a ordem da importncia dos tipos da validade : interna, construo,
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
14
concluso, e externa. Para os experimentos aplicados, que so o alvo da maioria dos experimentos na
rea de Engenharia de Software, a ordem da importncia dos tipos da validade : interna, externa,
construo, e concluso.
O anexo 1 (2.7) apresenta os exemplos de todos os tipos da validade. Informao adicional a
respeito da validade pode ser encontrada em [Wohlin00].
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
15
4. TIPOS DE EXPERIMENTOS
Os diferentes tipos de classificao dos experimentos foram descritos por vrias fontes. O
grande nmero de classificaes existe, provavelmente, porque a experimentao ainda uma
abordagem nova na rea de Engenharia de Software. O tipo de experimento mais apropriado em uma
situao concreta vai depender, por exemplo, dos objetivos do estudo, das propriedades do processo de
software usado durante a experimentao, ou dos resultados finais esperados.
Ao mesmo tempo, a classificao dos experimentos est sempre relacionada aos conceitos das
estratgias empricas. Em sntese, a literatura descreve trs principais estratgias experimentais:
Survey;
Estudo de caso;
Experimento.
As caractersticas principais usadas para diferenciar essas estratgias so o controle de execuo,
o controle de medio, o custo de investigao e a facilidade de repetio. Alm disso, o risco est
sendo considerado como uma caracterstica importante. essencial escolher uma estratgia, que seja
mais conveniente, baseado em custo e risco, e na maioria dos casos melhor comear em uma escala
menor acrescentando-a medida que o conhecimento aumente e o risco diminua.
O Survey uma investigao executada em retrospectiva. O Survey conduzido quando
algumas tcnicas ou ferramentas j tenham sido utilizadas. Os objetivos do survey so:
descritivo, por exemplo, determinar a distribuio de atributos ou caractersticas;
explanatrio, por exemplo, explicar porque os desenvolvedores escolheram uma das
tcnicas;
explorativo, por exemplo, um estudo preliminar para uma investigao mais profunda.
Os meios principais para coletar a informao quantitativa e qualitativa preliminar so os
questionrios. O Survey possui habilidade de levantar o grande nmero de variveis a serem avaliadas.
Entretanto, necessrio visar-se na recuperao de um volume maior da compreenso de um nmero
menor das variveis porque isso vai simplificar o trabalho analtico. O survey no oferece nenhum
controle sobre a execuo ou medio e sempre impossvel manipular as variveis.
Estudo de caso utilizado para monitorar os projetos, atividades e atribuies. Os estudos de
caso visam observar um atributo especfico e estabelecer o relacionamento entre atributos diferentes.
H trs maneiras de arranjar o estudo de caso:
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
16
a comparao dos resultados de usar os mtodos novos de encontro a baseline da
companhia que est expressa em valores mdios dos projetos da companhia;
Projetos semelhantes (sister projects), que implicam a comparao dos resultados de
projetos similares um dos quais usa uma tecnologia nova e o outro usa uma tecnologia
atual;
aplicao de um mtodo aleatoriamente atribudo a um projeto da companhia e no
atribudo aos outros.
O nvel de controle num estudo de caso baixo, mas ao contrrio de survey, o estudo de caso
possui o controle sobre a medio das variveis. O maior problema do estudo de caso a possibilidade
de fatores de confuso (confounding factors), ou seja, difcil diferenciar o efeito proveniente de um
fator do efeito proveniente de outro fator.
O experimento geralmente realizado em laboratrio e oferece o maior nvel de controle. O
objetivo do experimento manipular uma ou algumas variveis e manter as outras fixas medindo o
efeito do resultado. Os experimentos podem ser feitos in-vitro sob condies de laboratrio ou in-vivo
sob condies normais (veja Seo 3.1). Os experimentos so apropriados para confirmar as teorias,
confirmar o conhecimento convencional, explorar os relacionamentos, avaliar a predio dos modelos,
ou validar as medidas. A maior fora do experimento encontra-se no controle total sobre o processo e
as variveis e na possibilidade de ser repetido.
A comparao das estratgias experimentais est na Tabela 1.

Tabela 1. A comparao das estratgias empricas.
Fator Survey Estudo de caso Experimento
O controle da execuo Nenhum Nenhum Tem
O controle da medio Nenhum Tem Tem
O controle da investigao Baixo Mdio Alto
Facilidade da repetio Alta Baixa Alta
Custo Baixo Mdio Alto

De acordo com as estratgias experimentais existem trs principais mtodos para coleta de
dados:
histrico;
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
17
de observao;
controlado.
O mtodo histrico utilizado para coletar os dados experimentais dos projetos que j tenham
sido terminados. Os dados j existem e preciso analis-los. O mtodo de observao coleta os dados
relevantes enquanto o projeto est sendo executado. O mtodo oferece o controle fraco sobre o
processo de desenvolvimento. O mtodo controlado prov as instncias mltiplas de uma observao
oferecendo a validade estatstica dos resultados do estudo.
Na literatura estes mtodos esto ainda divididos em subtipos com a finalidade de uma maior
especializao e preciso.
Por exemplo, existe a seguinte classificao dos mtodos [Zelkowitz98]:
O mtodo histrico: pesquisa bibliogrfica, lies aprendidas, anlise esttica;
O mtodo de observao: o monitoramento do projeto, estudo de caso, afirmao, estudo
de campo;
O mtodo controlado: repetio, sinttico, anlise dinmica, simulao.
Outra classificao considera as caractersticas do contexto do experimento, ou seja,
diferenciao dos tipos de experimentos dependendo da quantidade dos objetos e participantes
envolvidos no estudo. Nesse caso, a classificao apresenta uma matriz 2x2 (Tabela 2).

Tabela 2. A classificao de estudos experimentais dependendo da quantidade dos objetos e
participantes [Wohlin00].
Nmero de objetos
1 2 ou mais
1

Estudo de nico objeto Estudo da variao de objetos
N

m
e
r
o

d
e

p
a
r
t
i
c
i
p
a
n
t
e
s

2

o
u

m
a
i
s

Estudo de objeto com vrios testes Estudo agrupado por objetos e participantes

A classificao pode tambm considerar como os dados experimentais foram medidos. H nove
tipos de estudos agrupados em trs categorias gerais:
O estudo qualitativo;
O estudo quantitativo;
Benchmarking.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
18
O estudo qualitativo est relacionado pesquisa sobre os objetos quando os resultados so
apresentados em termos naturais. Informaes mais detalhadas e alguns exemplos sobre estudos
qualitativos na rea de Engenharia de Software podem ser encontrados em [Seaman99]. O estudo
quantitativo geralmente conduzido atravs um experimento controlado. Uma das vantagens do
estudo controlado que os dados qualitativos promovem a comparao e a anlise estatstica.
Benchmarking utilizado para a medio do desempenho dos diferentes produtos de software.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
19

5. PROCESSO DE EXPERIMENTAO
5.1 Metodologia
Um experimento deve ser tratado como um processo da formulao ou verificao de uma
teoria. A fim de que o processo oferea os resultados vlidos, ele deve ser propriamente organizado e
controlado ou, pelo menos, acompanhado. Com o propsito de atingir estes objetivos vrias
metodologias de organizao dos experimentos foram elaboradas. Para serem comparadas as
metodologias da experimentao possuem diferentes caractersticas como, por exemplo, as fases do
processo de experimentao, a maneira da transformao dos conceitos abstratos do domnio s
mtricas concretas, o objetivo principal da experimentao, as ferramentas do empacotamento, etc.
Um bom exemplo da metodologia da experimentao avanada o Paradigma da Melhoria da
Qualidade (Quality Improvement Paradigm - QIP) [Basili94]. A essncia dessa metodologia est na
melhoria contnua do processo do desenvolvimento de software.
A metodologia define os seis passos que terminam resultando em um ciclo da melhoria do
processo completo. O ciclo se inicia com a caracterizao do processo de negcio necessria para a
compreenso do ambiente e a definio dos objetivos bsicos. A seguir os objetivos quantitativos so
estabelecidos com a propsito de demonstrar as expectativas razoveis da experimentao. Baseado na
caracterizao e nos objetivos definidos o processo da melhoria apropriado escolhido tomando em
considerao a consistncia entre os objetivos. O processo do desenvolvimento de software oferece,
alm do prprio software, o feedback do projeto que representa a informao recolhida. Essa
informao serve como a base para a anlise, ou seja, a avaliao das prticas atuais, a determinao
dos problemas, a proposio da melhoria futura. Finalmente, toda informao relevante est
empacotada para utilizao futura.
O QIP ligado ao conceito da Fbrica da Experincia [Basili94] que o conjunto das
ferramentas para o armazenamento, a modificao, e a retirada da informao do projeto empacotada.
Isso significa que alm do armazenamento passivo dos dados experimentais, a Fbrica de Experincia
pode processar os pedidos do projeto atual oferecendo a informao relevante dos projetos
semelhantes. A Figura 2 apresenta a estrutura da Fbrica da Experincia.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
20
Um outro instrumento ligado a QIP a abordagem Goal/Question/Metric (GQM) [Solingen99].
A abordagem oferece o processo da melhoria com o modelo da medio baseado em camadas. A
definio e a interpretao do processo da experimentao so divididas em camadas conceitual,
operacional, e quantitativa. A definio usa a abordagem top-down: o estabelecimento dos objetivos, a
formulao das questes, e elaborao das mtricas. A interpretao usa a abordagem bottom-up: a
medio para receber os dados experimentais, a formulao das respostas para as questes baseada nos
dados experimentais, e o agrupamento das respostas para demonstrar o grau do de sucesso dos
objetivos estabelecidos.
A Figura 3 apresenta o processo principal da abordagem GQM.
Os objetivos principais definidos por GQM so compreender, controlar, e melhorar. Esses
objetivos so focados nos quatro fatores: o custo, o risco, o tempo, e a qualidade. Juntando os
objetivos e os fatores os investigadores recebem o aumento da compreenso do produto e do processo
de software, o produto e o processo se tornam controlados, e, finalmente, as atividades de melhoria do
produto e do processo de software esto sendo definidas.
Fbrica de Experincia A organizao do projeto
1. Caracterizar

2. Estabelecer os
objetivos
3. Escolher o
processo
4. Execute 7. Analisar

Suporte
ao projeto
A base da
experincia
6. Empacotar
Figura 2. Fbrica de Experincia [Wohlin00].
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
21
A abordagem GQM composta de quatro fases:
A fase do planejamento, quando o projeto da medio est selecionado, definido,
caracterizado, e planejado, resultando em o plano do projeto;
A fase da definio, quando o programa da medio conceitualmente preparado, ou seja,
os objetivos, as questes, as mtricas e as hipteses so estabelecidos;
A fase da coleta de dados, quando a coleta de dados experimentais efetivamente feita
resultando em conjunto de dados prontos para a interpretao;
A fase da interpretao, quando os dados so processados a respeito das mtricas,
questes, e objetivos definidos.
Uma parte essencial da abordagem GQM a anlise custo-benefcio que est utilizada para
avaliar se o benefcio estimado supera o custo total.
O anexo 1 (1.3 e 1.4) apresenta um exemplo da definio de um estudo realizada de acordo com
os princpios da abordagem GQM.

5.2 Fases do experimento
O processo da execuo de um experimento presume a realizao de diferentes atividades. O
nmero e a complexidade dessas atividades podem variar de acordo com as caractersticas do estudo.
A literatura apresenta cinco fases gerais que sempre esto presentes num processo da experimentao.
A definio a primeira fase onde o experimento expresso em termos dos problemas e
objetivos. A fase de planejamento vem em seguida onde o projeto do experimento determinado, a












Planejamento



Coleta de dados empricos






Definio Interpretao
Objetivo
Questo
Mtrica
Alcano do
objetivo
Resposta
Medio
Coleta de dados
O

p
l
a
n
o

d
o

p
r
o
j
e
t
o

Figura 3. O processo principal da abordagem GQM [Solingen99]
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
22
instrumentao considerada e os aspectos da validade do experimento so avaliados. A execuo do
experimento segue o planejamento. Nesse momento os dados experimentais so coletados para serem
analisados e avaliados na fase de anlise e interpretao. Finalmente, os resultados so apresentados e
empacotados durante a fase da apresentao e empacotamento.A negligncia de qualquer dessas fases
acarreta em resultados errneos e precisa de modificaes no trabalho que j tinha sido feito, o que
difcil ou, s vezes, impossvel de realizar. Por exemplo, possvel fazer as modificaes nos objetivos
e no plano do experimento somente antes da execuo do experimento. Seno, o mesmo experimento
pode ser conduzido s com os participantes novos. De qualquer maneira, as modificaes trazem a
perda do tempo, de esforos, e de recursos.
A fase de definio descreve os objetivos, o objeto do estudo, o foco da qualidade, o ponto de
vista, e contexto. Como resultado, a fase de definio fornece a direo geral do experimento, o seu
escopo, a base para a formulao das hipteses e as notaes preliminares para a avaliao da
validade. A definio dos objetivos pode ser apresentada de acordo com a seguinte estrutura:

Analisar ..........................................<Objeto do estudo>
Especifica entidades que sero estudadas ao longo do
experimento.
Com o propsito de........................<Objetivo>
Define a inteno da realizao do experimento. Geralmente
escolhida da lista enumerada: caracterizar, avaliar,
predizer, controlar, ou melhorar.
Com respeito a ...............................<O foco da qualidade>
Indica o principal aspecto da qualidade que est sendo
estudado, por exemplo, eficincia, confiabilidade,
produtividade.
Do ponto de vista ...........................<Perspectiva>
Especifica o ponto de vista que os resultados do
experimento sero interpretados, por exemplo,
desenvolvedor, consumidor, gerente.
No contexto de ...............................<Contexto>
Especifica o ambiente onde o experimento est sendo
executado.

O anexo 1 (1.3) apresenta essa estrutura da definio preenchida.
A fase de planejamento implementa a fundao do experimento. Nesse momento acontecem a
seleo do contexto, a formulao das hipteses, a seleo das variveis, a seleo dos participantes, o
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
23
projeto do experimento, preparao conceitual da instrumentao, a considerao da validade do
experimento. O resultado dessa fase apresenta o experimento totalmente elaborado e pronto para
execuo.
O anexo 1 (2.1 2.7) contm a descrio dos resultados da fase do planejamento.
O aspecto mais importante da fase da execuo que a parte humana entra no jogo nesse
momento. Os participantes devem ser preparados para a experimentao do ponto de vista moral e
metodolgica para evitar os resultados errneos devido ao mal-entendido ou falta de interesse. A
coleta de dados deve ser realizada de maneira que no cause efeito significativo ao processo sendo
estudado. Finalmente, a validao preliminar dos dados experimentais se realiza.
Os resultados da fase de anlise e interpretao oferecem as concluses sobre a possibilidade da
rejeio da hiptese nula usando a estatstica descritiva, a reduo do conjunto de dados, e a
verificao das hipteses. Nesse momento, os aspectos mais importantes so eliminar dados fora da
distribuio normal (outliers), escolher o teste estatstico apropriado, explicar os resultados
considerando os aspectos da validade, realizar a anlise custo-benefcio, e interpretar corretamente os
resultados negativos.
O anexo 1 (4.1 4.6) apresenta um exemplo da anlise e da interpretao dos resultados do
estudo experimental.
A fase menos elaborada da metodologia da experimentao na rea de Engenharia de Software
a fase da apresentao e empacotamento. Os aspectos gerais a respeito de empacotamento sero
discutidos na seo seguinte.

5.3 Empacotamento
Como mencionado em seo 4.2 uma das caractersticas mais importantes do experimento a
necessidade da sua repetio. Com a repetio os pesquisadores adquirem o conhecimento adicional a
respeito dos conceitos estudados, e recebem os resultados que so iguais ou diferentes dos resultados
do experimento original. De qualquer maneira, o aumento das repeties traz o aumento do
aprendizado dos conceitos investigados e, tambm, a calibrao das caractersticas do experimento.
O pr-requisito necessrio para a repetio do experimento da alta qualidade o seu
empacotamento propriamente realizado.
O empacotamento padronizado dos dados experimentais pode servir como base para a criao
das bibliotecas de experimentao. Para uma organizao concreta, banco de dados com a informao
emprica organizada dessa forma pode abrir a possibilidade de armazenar os artefatos diferentes desde
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
24
as idias e as hipteses at os resultados e experincias finais dos projetos realizados. Isso sem dvida
vai ajudar a reutilizar os as descobertas nos estudos futuros, providenciar os meios para a classificao
dos dados experimentais e a criao dos relatrios detalhados com os resultados confiveis.
Um exemplo da metodologia que considera a construo da base do conhecimento foi
mencionado na seo 5.1 e descrita com o maior detalhamento em [Basili94].
Uma idia evolucionria do banco de dados experimentais a organizao dos servidores
distribudos que devem armazenar os dados experimentais a respeito da rea da experimentao
particular ou da famlia dos experimentos. Isso vai motivar o surgimento dos novos aspectos para a
padronizao do processo de empacotamento, porque o contedo e os formatos da apresentao da
informao emprica podem ser bastante distintivos mesmo para domnios semelhantes.
possvel tambm a criao dos servidores regionalmente orientados. Esses servidores podem
focar-se no armazenamento de informao a respeito dos experimentos conduzidos dento de uma
regio particular. Mas esses tipos de servidores vo trazer novos desafios por causa das diferenas de
lngua, cultural, poltica etc., requerendo o ajustamento das normas. A metodologia que trata da
organizao dos servidores distribudos foi elaborada recentemente e descrita com o detalhamento
maior em [Conradi01].
O estado de arte atual a respeito de empacotamento de experimentos indica a ausncia de
normas internacionais aprovadas. De um lado, isso estimula a evoluo dessa parte da Engenharia de
Software experimental fornecendo as boas oportunidades e atraindo a ateno dos pesquisadores. Por
outro lado, o grande nmero de caminhos possveis da evoluo se transforma numa certa anarquia
trazendo a discordncia sobre a interpretao dos conceitos relevantes ao empacotamento, o contedo
timo do pacote, e os meios da apresentao do pacote.
A tendncia comum e fundamental para a maioria das prticas de investigao nessa rea a
necessidade da existncia de um modelo elaborado para tratar os seguintes aspectos:
A comunidade do processo do experimento.
Essa comunidade inclui no s os pesquisadores que preparam e executam os experimentos,
analisam e apresentam os resultados, mas tambm os participantes que realizam as atribuies,
oferecidas ao longo da execuo do experimento, e os possveis usurios da informao emprica que
no participam diretamente no processo do experimento, mas usam os resultados do experimento para
os seus estudos, pesquisas ou necessidades industriais.
A organizao do experimento.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
25
A organizao do experimento inclui o conjunto total das informaes a respeito do projeto do
experimento, a preparao dos participantes, a preparao da instrumentao, as diretrizes para a
execuo do experimento, etc.
Os artefatos do experimento.
Os artefatos incluem a descrio da instrumentao usada para a coleta dos resultados puros
durante a execuo do experimento. Dependendo do tipo e dos objetivos do experimento, o papel do
artefato do experimento pode ser cumprido pela documentao do projeto do desenvolvimento de
software, cdigo fonte, mdulos executveis, ou algo outro que possa ajudar a coletar a informao.
Os resultados do experimento.
Os resultados incluem a descrio detalhada dos resultados recebidos. Os resultados so
apresentados como: dados puros, dados refinados sem outliers, e dados analisados (depois da
aplicao da estatstica descritiva e os testes estatsticos). Os dados analisados podem ser utilizados
para verificar as hipteses e fazer as concluses a respeito do atendimento dos objetivos. Alm disso,
os resultados devem ser apresentados de acordo com o conjunto de forma que incluam a informao
geral sobre os resultados do experimento, a informao sobre o processo de experimentao, a lista
dos problemas e as questes que devem ser resolvidas nos prximos estudos.
Os conceitos mencionados acima possibilitaram a criao do modelo de empacotamento dos
estudos experimentais que ajuda a organizar a informao dos experimentos conduzidos de uma
maneira estruturada e unificada. O anexo 2 apresenta os conceitos envolvidos num pacote de
experimento. Detalhes adicionais do modelo podem ser encontrados em [Amaral02].
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
26
6. CONCLUSES

O relatrio tcnico oferece discusso sobre os conceitos bsicos da organizao de estudos
experimentais na rea de Engenharia de Software. Experimentao oferece o modo sistemtico,
disciplinado, computvel e controlado para avaliao da atividade humana. Novas invenes e
sugestes no devem ser apenas sugeridas, publicadas ou apresentadas para venda, mas pelo menos
devem ser comparadas com as existentes.
Existem quatro mtodos relevantes para conduo de experimentos na rea de Engenharia de
Software: cientfico, de engenharia, experimental e analtico. A abordagem mais apropriada para a
experimentao na rea de Engenharia de Software o mtodo experimental que considera a
proposio e avaliao do modelo com os estudos experimentais.
Os objetivos relacionados execuo de experimentos em Engenharia de Software so a
caracterizao, avaliao, previso, controle e melhoria a respeito de produtos, processos, recursos,
modelos e outros resultados e atividades do processo de desenvolvimento de software.
H trs estratgias empricas bsicas que descrevem trs modos gerais de organizao e
execuo dos estudos experimentais: survey, estudo de caso e experimento. De acordo com as
estratgias empricas existem trs principais mtodos de coleta de dados: histrico, de observao, e
controlado. Um estudo experimental completo, na verdade, deve ser realizado considerando todas as
estratgias e utilizar os diferentes mtodos de coleta de dados, por exemplo, adquirir a informao
inicial utilizando um survey, elaborar uma teoria atravs de um experimento controlado e verificar a
teoria proposta em condies reais por meio de um estudo de caso.
Qualquer estudo experimental presume um relacionamento causa (representado por tratamentos)
- efeito (representado por resultados). Os conceitos envolvidos num estudo experimental
independentemente da estratgia incluem variveis dependentes e independentes, objeto(s),
participantes, contexto, hipteses nula e alternativa(s), e o projeto de estudo.
Trs princpios bsicos: aleatoriedade, agrupamento, e balanceamento, so utilizados durante
realizao de um estudo experimental. Alm disso, alguns princpios adicionais tambm podem ser
considerados dependendo das caractersticas do estudo.
Ao longo do processo de realizao de um estudo experimental um conjunto de parmetros deve
ser medido.A medio a parte importante de qualquer estudo incluindo os estudos qualitativos
porque oferece os meios para obteno de dados necessrios para verificao de hipteses. Uma
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
27
caracterstica importante a respeito da medio a escala da medio. So quatro tipos de escala:
nominal, ordinal, intervalo e razo.
Os resultados de estudo devem ser vlidos. Isso significa que para um estudo ter uma
importncia cientfica ou industrial, seus resultados devem ser considerados segundo quatro tipos de
validade: de concluso, interna, externa e de construo, que apresentam, respectivamente, os aspectos
a respeito da anlise estatstica, o relacionamento tratamento-resultado, a generalizao dos resultados
a uma populao maior, a relao entre a teoria e observao. Os aspectos de validade so
considerados logo na fase de planejamento do estudo e depois so utilizados durante a anlise dos
resultados.
Com o propsito de atingir estes objetivos vrias metodologias de organizao dos experimentos
foram elaboradas. Um exemplo da metodologia da experimentao avanada o Paradigma da
Melhoria da Qualidade (QIP). A essncia dessa metodologia est na melhoria contnua do processo do
desenvolvimento de software. O QIP ligado ao conceito da Fbrica de Experincia que representa o
conjunto das ferramentas para armazenamento, modificao, e retirada da informao empacotada do
projeto. Um outro instrumento ligado a QIP a abordagem Goal/Question/Metric (GQM) que
apresenta um modelo da medio baseado em: objetivos, questes e mtricas.
O nmero e a complexidade de atividades ao longo do processo de realizao de um estudo
experimental podem variar de acordo com as caractersticas do estudo. A literatura apresenta cinco
fases gerais que sempre esto presentes num processo da experimentao: definio, planejamento,
execuo, anlise e apresentao e empacotamento.
A fase menos tratada na literatura a fase de empacotamento. Entretanto essa fase importante
porque a repetio de um estudo experimental s pode acontecer caso todos os aspectos incluindo o
projeto, a instrumentao, as observaes sobre a execuo, os resultados, estejam adequadamente
empacotados.
A aplicao da abordagem emprica em grande parte determina o futuro da cincia de
Engenharia de Software. O grande nmero de descobertas sem validao emprica perde seu
significado e no pode entrar como um elemento inerente na estrutura da cincia e ainda pode causar a
demora no desenvolvimento da cincia direcionando os pesquisadores nos caminhos que na verdade
no tm futuro.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
28
REFERNCIAS

[Amaral02] AMARAL, E. A. G.; TRAVASSOS, G. H. Em busca de uma abordagem para
Empacotamento de Experimentos em Engenharia de Software. In. Anais da 2a JIISIC
- JORNADA IBERO-AMERICANA DE ENGENHARIA DE SOFTWARE E
ENGENHARIA DE CONHECIMENTO, 2002, Salvador, 2002.
[Basili93] Basili, V., The Empirical Paradigm in Software Engineering, Experimental
Software Engineering Issues: Critical Assessment and Future Directives, Spring-
Verlag, #706, Lectural Notes in CS, University of Maryland, 1993.
[Basili94] Basili, V., Caldeira, G., Rombach, H., Experience Factory, Encyclopedia of
Software Engineering, ed. J.J. Marciniak, Vol.I, Wiley, pp. 469-476, 1994.
[Basili96] Basili V., The Role of Experimentation in Software Engineering: Past, Present,
Future, Proceedings of the 18th International Conference on Software Engineering,
1(2), pp. 133-164, 1996.
[Brooks96] Brooks, A., Dali, J., Miller, J., Roper, M., Wood, M., Replication of Experimental
Results in Software Engineering, Technical Report ISERN-96-10, International
Software Engineering Research Network (ISERN), University of Strathclyde, 1996.
[Conradi01] Conradi,R., Basili, V., Carver, J., Shull, F., Travassos, G., A Pragmatic Document
Standards for an Experience Library: Roles, Documents, Contents and Structure.,
Technical Report CS-TR-4235, University of Maryland, April 2001.
[Juristo98] Juristo, N., Moreno, A., An Adaptation of Experimental Design to the Empirical
Validation of Software Engineering Theory, 23
nd
Annual NASA Software
Engineering Workshop, USA, December 1998.
[Miller97] Miller, J., Dali, J., Wood, M., Roper, M., Brooks, A., Statistical power and its
Subcomponents Missing and Misunderstood Concepts in Empirical Software
Engineering Research, Information and Software Technology, Vol. 39, No. 4, pp.
285-295, 1997.
[Seaman99] Seaman, C., Qualitative Methods in Empirical Studies of Software Engineering,
IEEE Computer, Vol. 25, No. 4, July/August 1999.
[SEL95] Software Measurement Guidebook. Revision 1, Software Engineering Laboratory,
University of Maryland, 1995
[Shull01] Shull, F., Carver, J., Travassos, G., An Empirical Methodology for Introducing
Software Processes, Proceedings of the ESEC/FSE-9, Austria, September 2001.
[Solingen99] Solingen, R., Berghout, E., The Goal/Question/Metric Method: a Practical Guide for
Quality Improvement of Software Development, the McGraw-Hill Companies, UK,
1999.
[Tichy98] Tichy, W., Should Computer Scientists Experiment More?, IEEE Computer, Vol.
31, No 5, pp. 32-39, 1998.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
29
[Wohlin00] Wohlin, C., Runeson, P., Hst, M., Ohlsson, M., Regnell, B., Wessln, A.,
Experimentation in Software Engineering: an introduction, Kluwer Academic
Publishers, USA, 2000.
[Zelkowitz98] Zelkowitz, M., Wallace, D., Experimental Models for Validating Technology, IEEE
Computer, Vol.31, No.5, pp. 23-31, 1998.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
30
GLOSSRIO DE PALAVRAS EM INGLS
Baseline........................ o conjunto de medidas que descrevem as caractersticas usuais ou tpicas. Em
relao aos estudos experimentais a baseline descreve, por exemplo, o projeto
mdio de uma organizao e utilizado com a finalidade de comparao com
outros projetos dessa organizao.
Benchmarking.............. o processo de execuo de dois ou mais sistemas com a finalidade de
comparar as caractersticas desses sistemas, principalmente, o desempenho.
Blocking....................... uma tcnica de organizao do estudo experimental utilizado quando um
fator no projeto do experimento provavelmente tem um efeito sobre o
resultado, mas esse efeito no interessante para os pesquisadores. Blocking
presume agrupamento de participantes e atribuio de tratamentos que
sistematicamente eliminam o efeito indesejado durante a comparao dos
tratamentos.
Bottom-up .................... uma tcnica da organizao de alguma atividade como estudo, planejamento,
desenvolvimento, entre outros, quando o processo comea no mais baixo nvel
continuamente aumentando o nvel at chegar ao mais alto nvel.
Confounding factor ...... o aspecto que provavelmente causa o efeito em vez de fator(es)
considerado(s) no projeto de estudo experimental.
Feedback ...................... o conjunto de informaes sobre o processo ou resultados de estudo que
sero utilizados para calibrao do projeto de estudo.
Framework................... uma estrutura de sistema ou processo que deve ser instanciada. O processo de
instanciao presume especializao, parametrizao, implementao dos
elementos da estrutura entre outros.
Outlier ..........................so os dados recebidos durante o estudo experimental que representam a
informao falsa ou extremamente diferente do que foi esperado e dos
resultados mdios do estudo, por exemplo, devido a mal-entendimento.
Rescaling...................... a transformao de uma escala de medio para outra.
Survey .......................... uma das estratgias empricas que realiza uma pesquisa retrospectiva sobre
um assunto que j tinha acontecido. Os meios principais de survey so
entrevistas ou questionrios. A traduo possvel para portugus Pesquisa
de Campo.
Time-to-market ............ um dos fatores chaves que mudaram o conceito do desenvolvimento de
software. Implica que o desenvolvimento de software deve ser organizado a
produzir os produtos ou artefatos de software considerando as foras do
mercado.
Top-down..................... uma tcnica de organizao de alguma atividade como estudo, planejamento,
desenvolvimento, entre outros, quando o processo comea no mais alto nvel e
vem diminuindo o nvel de detalhamento at chegar ao nvel desejado.
Toy problem................. o modelo de sistema utilizado num estudo experimental para tentar concluir
sobre alguns aspectos de sistema real. Um exemplo a organizao do projeto
universitrio com a finalidade de estudar um sistema real (industrial).
Type-I-error.................. o tipo de erro que pode acontecer durante a verificao de hiptese nula
quando o teste estatstico indica o relacionamento mesmo que no exista
nenhum relacionamento real.
Type-II-error ................ o tipo de erro que pode acontecer durante a verificao de hiptese nula
quando o teste estatstico no indica o relacionamento mesmo que
efetivamente exista um relacionamento.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
31
ANEXO 1: O ESTUDO EXPERIMENTAL

O ROTEIRO DO ESTUDO
1. DEFINIO DOS OBJETIVOS ................................................................................................... 32
1.2 OBJETIVO GLOBAL: ............................................................................................................. 32
1.3 OBJETIVO DA MEDIO:...................................................................................................... 32
1.3 OBJETIVO DO ESTUDO: ........................................................................................................ 33
1.4 QUESTES:........................................................................................................................... 33
2. PLANEJAMENTO.......................................................................................................................... 34
2.1 DEFINIO DAS HIPTESES................................................................................................. 34
2.2 DESCRIO DA INSTRUMENTAO ..................................................................................... 35
2.3 SELEO DO CONTEXTO...................................................................................................... 36
2.4 SELEO DOS INDIVDUOS................................................................................................... 37
2.5 VARIVEIS............................................................................................................................ 37
2.6 ANLISE QUALITATIVA........................................................................................................ 38
2.7 VALIDADE ............................................................................................................................ 38
3. OPERAO..................................................................................................................................... 40
3.1 QUESTIONRIO DO PERFIL DO PARTICIPANTE................................................................... 40
3.2 QUESTIONRIO DE COMPETNCIAS.................................................................................... 41
3.3 RESULTADO DO ESTUDO ...................................................................................................... 42
4. ANLISE E INTERPRETAO DOS RESULTADOS............................................................. 44
4.1 VALIDAO DOS DADOS....................................................................................................... 44
4.2 ESTATSTICA DESCRITIVA ................................................................................................... 44
4.3 APLICAO DO TESTE ESTATSTICO ................................................................................... 46
4.4 ANLISE QUANTITATIVA ..................................................................................................... 47
4.5 ANLISE QUALITATIVA........................................................................................................ 47
4.6 VERIFICAO DAS HIPTESES............................................................................................. 48

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
32
1. DEFINIO DOS OBJETIVOS
1.2 Objetivo global:
Definir se o curso bsico de Engenharia de Software (ES) oferece competncias necessrias para
desenvolvimento de software pessoal do ponto de vista dos seus alunos.

1.3 Objetivo da medio:
Tendo como base as competncias do currculo mnimo da SBC, caracterizar:
1. Quais so as competncias que os alunos recebem:
quais so as competncias oferecidas pelo curso bsico de ES que os alunos
consideram teis para o desenvolvimento de software pessoal;
quais so as competncias oferecidas pelo curso bsico de ES que os alunos
consideram inteis para o desenvolvimento de software pessoal.
2. Quais so as competncias que os alunos recebem com contedo inadequado:
quais so as competncias que necessitam melhor detalhamento;
quais so as competncias que apresentam o detalhamento excessivo.
3. Quais so as competncias que os alunos gostariam de receber alm das oferecidas pelo
curso bsico de ES.

Currculo Mnimo
da SBC
Curso
Competncias teis
Competncias
inteis
Modificao
necessria
Modificao
no
necessria
Gostariam
de receber
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
33
1.3 Objetivo do estudo:
Analisar as competncias oferecidas aos alunos
Com o propsito de caracterizar
Com respeito interseo com as competncias do currculo mnimo da SBC
Do ponto de vista do desenvolvedor de software pessoal
No contexto de alunos de curso bsico de ES.

1.4 Questes:
Q1: Existem competncias de ES listadas no currculo mnimo da SBC que no fazem parte do curso
bsico de ES?
Mtrica: A lista de competncias de ES do currculo mnimo da SBC que no fazem parte do curso
bsico de ES.
Q2: Existem competncias de ES listadas no currculo mnimo da SBC e oferecidas pelo curso bsico
de ES que so consideradas inteis pelos alunos?
Mtrica: A lista de competncias de ES do currculo mnimo da SBC que fazem parte do curso bsico
de ES e so consideradas inteis pelos alunos desse curso
Q3: Existem competncias listadas no currculo mnimo da SBC, oferecidas pelo curso bsico de ES e
consideradas teis pelos alunos, cujo detalhamento deve ser modificado?
Mtrica: A lista de competncias de ES do currculo mnimo da SBC que fazem parte do curso bsico
de ES e so consideradas teis pelos alunos desse curso cujo detalhamento deve ser modificado
Q4: Existem competncias de ES listadas no currculo mnimo da SBC que no fazem parte do curso
bsico de ES, mas que os alunos gostariam de receber porque consideram teis para
desenvolvimento de software pessoal?
Mtrica: A lista de competncias de ES do currculo mnimo da SBC que no fazem parte do curso
bsico de ES.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
34
2. PLANEJAMENTO
2.1 Definio das Hipteses
Hiptese nula (H0): As competncias oferecidas para os alunos do curso bsico de ES so similares
s competncias de ES que o currculo mnimo da SBC considera fundamental para o desenvolvimento
de software
C
a
competncias oferecidas para os alunos do curso bsico de ES;
C
c
competncias de ES do currculo mnimo da SBC.
H0: C
c
(C
a
C
c
) =

Hiptese alternativa (H1) A lista de competncias oferecidas para os alunos do curso bsico de ES
diferente da lista de competncias de ES que o currculo mnimo da SBC considera fundamental para o
desenvolvimento de software.
C
a
competncias oferecidas para os alunos do curso bsico de ES;
C
c
competncias de ES do currculo mnimo da SBC.
H1: C
c
(C
a
C
c
)

Hiptese alternativa (H2): Na lista de competncias oferecidas para os alunos do curso bsico de ES
e que fazem parte do currculo mnimo da SBC existem competncias que os alunos consideram
inteis para o desenvolvimento de software pessoal.
C
a
competncias oferecidas para os alunos do curso bsico de ES e que fazem parte do currculo
mnimo da SBC;
C
au
competncias oferecidas para os alunos do curso bsico de ES e que fazem parte do currculo
mnimo da SBC, que os alunos consideram teis para desenvolvimento de software pessoal.
H2: C
a
(C
a
C
au
)

Hiptese alternativa (H3): Na lista de competncias oferecidas para os alunos do curso bsico de ES,
que fazem parte do currculo mnimo da SBC e consideradas teis para desenvolvimento de software
pessoal, existem competncias cujo detalhamento deve ser modificado para atingir o nvel esperado
pelos desenvolvedores de software pessoal.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
35
C
au
competncias oferecidas para os alunos do curso bsico de ES, que fazem parte do currculo
mnimo da SBC e consideradas teis para desenvolvimento de software pessoal;
C
aun
competncias oferecidas para os alunos do curso bsico de ES, que fazem parte do currculo
mnimo da SBC e so consideradas teis para o desenvolvimento de software pessoal, cujo
detalhamento no precisa de modificao.
H3: C
au
(C
au
C
aun
)
Hiptese alternativa (H4): Na lista de competncias no oferecidas para os alunos do curso bsico de
ES existem competncias que os alunos gostariam de receber.
C
na
competncias no oferecidas para os alunos do curso bsico de ES (C
na
C
c
(C
a
C
c
))
C
g
competncias no oferecidas para os alunos do curso bsico de ES que os alunos gostariam de
receber.
H4: C
na
(C
na
C
g
)

2.2 Descrio da instrumentao
Para cada competncia que o currculo mnimo da SBC considera fundamental para o
desenvolvimento de software oferecer escolha:

Presena da competncia (P) Utilidade da competncia (U)
Adequao do nvel de
detalhamento da competncia (A)
1. No oferecida pelo curso e
no gostaria de receber.
2. No oferecida, mas gostaria
de receber.
3. Oferecida, parcialmente.
4. Oferecida.
1. No til.
2. Provavelmente til, mas
ainda no apliquei.
3. til e j apliquei em
diferentes projetos.
1. O detalhamento deve ser
aumentado.
2. O detalhamento no precisa ser
modificado.
3. O detalhamento deve ser
diminudo.

Para cada competncia aplicar teste estatstico Chi-2 para definir:
se pode considerar que essa competncia fornecida;
se pode considerar que essa competncia til.
se pode considerar que o detalhamento da competncia no precisa de modificao.
Resultado: N competncias com valores (P;U;A)
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
36
onde P presena {0 no oferecida;1 - oferecida}; U utilidade {0 no til;1 -
til}; A adequao {0 o nvel adequado,1 o nvel no adequado}.
Mtricas

N
o
P U A Descrio da competncia Questes
1 0 0 0 no oferecida, no til, a modificao no necessria. Q1, Q4
2 0 0 1 no oferecida, no til, a modificao necessria. N/A
3 0 1 0 no oferecida, til, a modificao no necessria. Q1, Q4
4 0 1 1 no oferecida, til, a modificao necessria. Q1, Q4
5 1 0 0 oferecida, no til, a modificao no necessria. Q2
6 1 0 1 oferecida, no til, a modificao necessria. Q2
7 1 1 0 oferecida, til, a modificao no necessria. Q3
8 1 1 1 oferecida, til, a modificao necessria. Q3

2.3 Seleo do contexto
O contexto pode ser caracterizado conforme quatro dimenses:
o o processo: on-line / off-line;
o os participantes: alunos / profissionais;
o realidade: o problema real / modelado;
o generalidade: especifico / geral.
Nosso estudo supe o processo off-line porque os alunos no esto sendo entrevistados durante todo o
tempo do curso, mas em um certo instante. Os participantes so os alunos que esto realizando o curso.
O estudo modelado porque as competncias dos alunos no so caracterizadas durante a resoluo do
problema real, mas utilizando as notas subjetivas. As competncias dos alunos do certo curso so
comparadas com as competncias listadas no currculo da SBC, ento, o contexto possui o carter
especifico.

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
37
2.4 Seleo dos indivduos
Como participantes para o estudo se prope utilizar os alunos de ps-graduao, graduao ou alunos
de 2o grau da rea de Engenharia de Software. Assume-se que esses indivduos esto disponveis para
o estudo e a maioria deles desenvolve software pessoal.
Seria conveniente utilizar para o estudo os alunos que esto realizando alguns de cursos bsicos na
rea de Engenharia de Software. Nesse caso, dependendo do tamanho da turma, possvel usar uma
das tcnicas (probabilstica ou no-probabilstica) para escolha dos indivduos.
Supe-se propor aos participantes o questionrio que tem como objetivo caracterizar sua formao do
ponto de vista acadmico, experincia, tipo de curso entre outros para analisar os dados e reduzir o
vis.

2.5 Variveis
Varivel independente:
A lista de competncias de ES do currculo mnimo da SBC.

Variveis dependentes:
1. A similaridade entre competncias oferecidas para os alunos do curso bsico de ES e competncias
de ES do currculo mnimo da SBC.
Pode receber os valores:
Igual, quando todas as competncias tm o valor PUA = {1, X, X} (mtricas 5-8);
Diferente, quando todas as competncias tm o valor PUA = {0, X, X} (mtricas 1-4).
Similar, quando no se cumprem as condies de Igual e Diferente. O grau de similaridade
pode ser avaliado como:
{1, X, X} / ({0,X,X} + {1,X,X}) * 100%
2. A utilidade de competncias similares. Mostra a parte til das competncias oferecidas pelo curso
bsico de ES:
Parte til: {1, 1, X} / {1, X, X} * 100%
Parte intil: {1, 0, X} / {1, X, X} * 100%

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
38
3. A adequao de competncias similares. Mostra a parte adequada das competncias oferecidas
pelo curso bsico de ES:
Parte adequada: {1, X, 0} / {1, X, X} * 100%
Parte inadequada: {1, X, 1} / {1, X, X} * 100%


2.6 Anlise qualitativa
Para analisar a informao referente s competncias no oferecidas para os alunos do curso bsico de
ES, mas que os alunos gostariam de receber, se prope aplicar a anlise qualitativa. Essa anlise deve
apresentar a lista de competncias de ES do currculo mnimo da SBC, que no so oferecidas para os
alunos do curso bsico de ES, mas que os alunos consideram necessrias para desenvolvimento de
software pessoal e gostariam de receber realizando o curso.
Assim, essa anlise deve considerar competncias com valor PUA = {0, X, X} (mtricas 1-4) e a
opo No oferecida, mas gostaria de receber para presena da competncia.

2.7 Validade
Validade interna: como mencionado no parte Seleo dos indivduos para o estudo se prope a
utilizar os alunos da rea de Engenharia de Software, que geralmente costumam desenvolver software
pessoal. Assim, assume-se que eles so representativos para a populao dos desenvolvedores de
software pessoal.
Alm disso, para reduo da influncia dos fatores que no so interesse do nosso estudo e, portanto,
para aumento da validade interna do estudo supe-se utilizar os dados do questionrio para diviso dos
participantes em grupos conforme a suas caractersticas individuais.
Validade de concluso: para receber os valores da presena, utilidade e conformidade o teste
binomial ser utilizado. A verificao de hiptese ser feita por meio de simples demonstrao de
presena ou no de competncias nas listas que representam os variveis independentes.
Validade de construo: esse estudo est caracterizado pela conformidade das competncias listadas
no currculo mnimo da SBC com as competncias reais necessrias para desenvolvimento de software
pessoal. O currculo mnimo da SBC representa a lista de competncias que os especialistas na rea de
computao devem possuir para mostrar o desempenho adequado do ponto de vista da SBC. As
competncias, que tm o maior relacionamento com desenvolvimento de software pessoal do ponto de
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
39
vista dos pesquisadores, foram escolhidas do conjunto total de competncias do currculo mnimo da
SBC.
Validade externa: como foi mencionado nas partes Seleo dos indivduos e Validade interna os
participantes do estudo em geral podem ser considerados representativos para a populao dos
desenvolvedores de software pessoal. Para avaliao do nvel de envolvimento no processo de
desenvolvimento de software pessoal os dados do questionrio conforme a experincia dos
participantes podem ser analisados.
Os materiais utilizados no estudo podem ser considerados representativos e em tempo para o
problema sob anlise, porque se compem das competncias do currculo mnimo atual da SBC
relacionadas ao desenvolvimento de software.
As caractersticas temporrias no devem ser o problema, porque os materiais do a possibilidade de
conduzir o estudo durante a meia-hora. Alm disso, o estudo ser realizado quando os participantes
estiverem realizando algum curso e, geralmente, estiverem envolvidos no desenvolvimento de
software.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
40
3. OPERAO
3.1 Questionrio do Perfil do Participante

Marque um X sobre a opo que melhor representar sua formao.

FORMAO
Instituio.
Pblica
Particular
Tipo de curso.
Engenharia.
Informtica / Cincia da computao.
Matemtica
Outros.
Acadmica:
Ensino Mdio Tcnico
Universitria
Ps-graduao

EXPERINCIA PROFISSIONAL
Tempo de experincia:
Seis meses.
Entre seis meses e dois anos.
Entre 2 e 4 anos
Entre 4 e 6 anos
Acima de 6 anos
Como voc classificaria a sua experincia em desenvolvimento de software.
Baixa
Media
Alta


Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
41
3.2 Questionrio de Competncias
Sob o ponto de vista de desenvolvimento de software pessoal e considerando o tipo de curso que voc
indicou acima, por favor, avalie e marque as colunas correspondentes segundo as escalas abaixo, a
presena, utilidade e adequao quanto ao detalhamento que lhe foi apresentado durante o curso, das
competncias listadas no questionrio:
Presena Utilidade Adequao do nvel de detalhamento
1 No oferecida durante os cursos e
no gostaria de receber.
2 No oferecida, mas gostaria de
receber.
3 Oferecida, parcialmente.
4 Oferecida.
1 No se demonstrou til.
2 Provavelmente til, mas ainda no
apliquei.
3 til e apliquei em muitos projetos.
1 O detalhamento deve ser aumentado.
2 O detalhamento no precisa ser
modificado.
3 O detalhamento deve ser diminudo.

Presena Utilidade Adequao
N Competncia Descrio
1 2 3 4 1 2 3 1 2 3
Processo


1
Qualidade do
produto
capaz de avaliar a qualidade de um produto de
software utilizando-se de normas apropriadas; capaz
de empregar os modelos de medio.

2
Interface homem-
mquina
capaz de avaliar e propor mudanas na interface de
um produto de software, sob o ngulo da usabilidade.

Processo


3
Modelos de ciclo
de vida
capaz de identificar situaes e de empregar
adequadamente os diversos tipos de modelos de ciclo de
vida

4
Gerenciamento
de configurao
capaz de definir atividades tcnicas e organizacionais
relacionadas a identificao, controle,

5
Garantia da
qualidade
capaz de estabelecer processos, mtricas e avaliaes
que possibilitem e garantam a qualidade de software.

6
Melhoria de
processo
possui conhecimento dos modelos de melhoria de
qualidade de software (ex: CMM e SPICE).

7 Padres
possui conhecimento sobre padres de desenvolvimento
de software e consegue empreg-los.

8
Engenharia
reversa
capaz de analisar um sistema de forma a identificar
seus componentes e suas inter-relaes; e de criar
representaes de maior nvel de abstrao.

9 Reengenharia
capaz de examinar um sistema e de reconstitu-lo em
uma nova forma considerando sua respectiva
redocumentao, redefinio de objetivos.

10
Planejamento do
desenvolvimento
capaz de definir um planejamento de software
utilizando-se de tcnicas apropriadas (ex: tcnicas de
estimativas e de medio, PERT, CPM,)

Tecnologia

11 Programao
capaz de identificar os diversos tipos de paradigmas de
programao (ex: procedural, funcional, orientado a
objetos).

12
Ferramentas
CASE
capaz de utilizar uma ferramenta CASE para auxlio
na construo de software

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
42
3.3 Resultado do estudo
Dados de estudo crus

Presena Utilidade Adequao
N Competncia Descrio
1 2 3 4 1 2 3 1 2 3
Processo


1
Qualidade do
produto
capaz de avaliar a qualidade de um produto de
software utilizando-se de normas apropriadas; capaz
de empregar os modelos de medio.
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
2
Interface homem-
mquina
capaz de avaliar e propor mudanas na interface de
um produto de software, sob o ngulo da usabilidade.
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Processo


3
Modelos de ciclo
de vida
capaz de identificar situaes e de empregar
adequadamente os diversos tipos de modelos de ciclo de
vida

xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxx
xxx
4
Gerenciamento
de configurao
capaz de definir atividades tcnicas e organizacionais
relacionadas a identificao, controle,
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Xxx
xxx
xx
5
Garantia da
qualidade
capaz de estabelecer processos, mtricas e avaliaes
que possibilitem e garantam a qualidade de software.
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Xxx
xxx
6
Melhoria de
processo
possui conhecimento dos modelos de melhoria de
qualidade de software (ex: CMM e SPICE).
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
7 Padres
possui conhecimento sobre padres de desenvolvimento
de software e consegue empreg-los.
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxx
xxx
8
Engenharia
reversa
capaz de analisar um sistema de forma a identificar
seus componentes e suas inter-relaes; e de criar
representaes de maior nvel de abstrao.
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxx
xxx
9 Reengenharia
capaz de examinar um sistema e de reconstitu-lo em
uma nova forma considerando sua respectiva
redocumentao, redefinio de objetivos.
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Xxx
xxx
10
Planejamento do
desenvolvimento
capaz de definir um planejamento de software
utilizando-se de tcnicas apropriadas (ex: tcnicas de
estimativas e de medio, PERT, CPM,)
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Xxx
xxx
Tecnologia


11 Programao
capaz de identificar os diversos tipos de paradigmas de
programao (ex: procedural, funcional, orientado a
objetos).

xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Xxx
xxx
12
Ferramentas
CASE
capaz de utilizar uma ferramenta CASE para auxlio
na construo de software

xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx

Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
43
Perfis dos participantes

Experincia
Instituio Curso Acadmica
anos nvel
Numero do
participante
(1-2) (1-4) (1-3) (1-5) (1-3)
1 1 2 2 3 1
2 1 2 2 2 1
3 1 2 2 3 2
4 1 2 2 3 2
5 1 2 2 3 2
6 1 2 3 5 2
7 1 2 2 2 1
8 1 2 2 3 2
9 1 1 2 2 1
10 1 2 3 5 3
11 1 2 2 2 1
12 1 2 3 2 1
13 1 1 3 1 1
14 1 2 2 5 2

Legenda:
Instituio Curso Acadmica Experincia (anos) Experincia (nvel)
1 Publica 1 Engenharia 1 Tcnico 1 Menos 6 meses 1 Baixo
2 Particular 2 Informtica 2 Universitria 2 6meses - 2anos 2 Mdio
3 Matemtica 3 Ps-graduao 3 2 anos 4 anos 3 Alto
4 Outros 4 4 anos 6 anos
5 6 anos e mais

0
1
2
3
4
5
6
13 2 7 9 11 12 1 3 4 5 8 14 6 10
Academica
Anos de experiencia
nivel de experiencia
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
44
4. ANLISE E INTERPRETAO DOS RESULTADOS
4.1 Validao dos dados
Algumas respostas dos participantes esto erradas do ponto de vista dos valores vlidos de PUA.

Participante Resposta Valor PUA
5 4 {0, 0, 1}
7 6, 10 {0, 0, 1}
8 4 {0, 0, 1}

O participante 14 no respondeu a pergunta 10 e seus dados foram eliminados da anlise estatstica.

4.2 Estatstica descritiva
Medidas de tendncia central. Como os valores Presena, Utilidade e Adequao so da escala
ordinal, possvel definir somente as mtricas de moda e mediana.

Competncias
1 2 3 4 5 6 7 8 9 10 11 12
mediana 3 3 4 2 3 2 2 2 2 3 4 3
Presena
moda 3 4 4 1 3 {1,3} {2,3} 2 2 4 4 3

Competncias
1 2 3 4 5 6 7 8 9 10 11 12
mediana 2 3 3 2 2 2 2 2 2 2 3 3
Utilidade
moda 2 2 3 2 2 2 2 2 2 2 {3,4} 3

Competncias
1 2 3 4 5 6 7 8 9 10 11 12
mediana 1 1 2 1 1 1 1 1 1 2 2 1
Adequao
moda 1 1 2 1 1 1 1 1 1 {1,2} 2 {1,2}
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
45
Considerando respostas recebidas durante o estudo e utilizando os resultados de estatstica descritiva
podemos dividir as perguntas nos 3 grupos:
(valores nas tabelas significam: P - presente:no_presente; U - til:intil; A - adequado:inadequado)

1. Competncias aprendidas e no utilizadas
N
o
Competncias P U A Caracterstica
1 Qualidade do produto 11:2 12:1 4:9
5
Garantia da
qualidade (processo)
9:4 10:3 4:9
10
Planejamento do
desenvolvimento
7:6 8:5 6:7
As competncias so recebidas parcialmente ou
plenamente durante o curso;
As competncias so consideradas teis, mas a
maioria (12, 10, 8) ainda no utilizou para
desenvolvimento de software pessoal;
O detalhamento deve ser modificado,
provavelmente para entender onde elas podem
ser utilizadas.

2. Competncias mal-entendidas
N
o
Competncias P U A Caracterstica
4
Gerenciamento de
configurao
4:9 9:2 3:10
6
Modelos de melhoria
de processo
6:7 12:1 5:8
7 Padres 6:7 13:0 4:9
8 Engenharia reversa 2:11 13:0 3:10
9 Reengenharia 4:9 11:2 5:7
A maioria dos participantes no recebeu as
competncias durante o curso, mas gostaria de
receber;
As competncias so consideradas teis, mas
quase todos (7, 10, 11, 12, 8) ainda no
utilizaram para desenvolvimento de software
pessoal;
O detalhamento deve ser modificado, porque
mesmo que os participantes receberam alguma
informao sobre essas competncias o
detalhamento no adequado para utilizao.

3. Competncias aprendidas
N
o
Competncias P U A Caracterstica
2
Interface homem-
mquina
8:5 13:0 4:9
3
Modelos de ciclo de
vida
12:1 13:0 8:5
11 Programao 13:0 13:0 8:5
12 Ferramentas CASE 11:2 13:0 6:7
Todas as competncias so recebidas durante o
curso e maioria dos participantes recebeu essas
competncias plenamente;
As competncias so consideradas teis e a
maioria dos participantes (7, 8, 12, 9) j utilizou
essas competncias para desenvolvimento de
software pessoal;
O detalhamento quase no precisa de
modificao exceo de Interface homem-
mquina, cujo detalhamento deve ser aumentado.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
46
4.3 Aplicao do teste estatstico
Para cada competncia foi aplicado o teste estatstico Chi-2 para definir:
se pode considerar que essa competncia fornecida;
se pode considerar que essa competncia til.
se pode considerar que o detalhamento da competncia no precisa de modificao.
Como o teste Chi-2 considera comparao das distribuies podemos comparar a distribuio de
respostas dos participantes com a distribuio ideal, i.e. quando todos participantes responderam
igualmente que competncia recebida, til e no precisa de modificao.
No incio precisamos encontrar os valores Chi-2 para todas possveis distribuies de respostas para
poder tentar concluir sobre presena, utilidade e adequao de cada competncia.

Distribuio
Resposta
real ideal
Total
positiva m 13 13+m
negativa n 0 n
Total 13 13 26

Assim, tivemos
Distribuio (+7):(-6) (+8):(-5) (+9):(-4) (+10):(-3) (+11):(-2)
Valor Chi-2

6.80 6.19 4.72 3.39 2.16


Como valor Chi-2 para grau de liberdade 2 5.99, concluirmos que as competncias com distribuio
das respostas (+9):(-4), (+10):(-3), (+11):(-2), (+12):(-1) e (+13):(-0) podem receber os valores
Presena, Utilidade = {1} e o valor Adequao = {0}. Para as competncias com outras
distribuies das respostas os valores Presena, Utilidade = {0} e o valor Adequao ={1}.

Competncias
1 2 3 4 5 6 7 8 9 10 11 12
Presena 1 0 1 0 1 0 0 0 0 0 1 1
Utilidade 1 1 1 1 1 1 1 1 1 1 1 1
Adequao 1 1 1 1 1 1 1 1 1 1 1 1
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
47
4.4 Anlise quantitativa
Para verificar a similaridade entre competncias oferecidas para os alunos do curso bsico de ES e
competncias de ES do currculo mnimo da SBC necessrio calcular o valor de varivel dependente
1. Os conjuntos de competncias oferecidas para os alunos do curso bsico de ES e competncias de
ES do currculo mnimo da SBC no podem ser considerados iguais (a quantidade de competncias
com o valor PUA {1, X, X} = 5 < 12), nem diferentes (a quantidade de competncias com o valor
PUA {0, X, X} 7 <12). Assim, precisamos calcular o grau de similaridade segundo a formula do
varivel 1:
grau de similaridade = 5 / 12 * 100% = 41,7%

Para verificar a utilidade de competncias similares, i.e. competncias listadas no currculo mnimo da
SBC e que so oferecidas pelo curso bsico de ES, necessrio calcular o valor de varivel
dependente 2:
Parte til das competncias similares: 5 / 5 * 100% = 100%
Parte intil das competncias similares: 0 / 5 * 100% = 0%

Para verificar a adequao de competncias similares, i.e. se o nvel de detalhamento de competncias
precisa ser modificado, necessrio calcular o valor de varivel dependente 3:
Parte adequada das competncias similares: 0 / 5 * 100% = 0%
Parte inadequada das competncias similares: 5 / 5 * 100% = 100%

4.5 Anlise qualitativa
Para verificar se existem competncias de ES listadas no currculo mnimo da SBC que no fazem
parte do curso bsico de ES, mas que os alunos gostariam de receber porque consideram teis para
desenvolvimento de software pessoal, foi feita a anlise qualitativa.
A tabela abaixo mostra as competncias no oferecidas pelo curso bsico de ES:
Competncia 2 4 6 7 8 9 10
A quantidade total de participantes que no
receberam competncia.
4 9 7 7 11 9 6
A quantidade de participantes que no receberam
competncia, mas gostariam de receber.
1 3 2 4 7 7 3
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
48
Assim podemos concluir, que as competncias 8 (Engenharia reversa) e 9 (Reengenharia) provocam
interesse dos alunos, que no receberam essas competncias durante o curso bsico de ES, mais do que
as outras competncias que no foram oferecidas pelo curso bsico de ES. Isso pode ser explicado pelo
contedo dessas competncias. A informao sobre Engenharia reversa e Reengenharia,
provavelmente, no est sendo oferecida em geral ou oferecida com pouco detalhamento pelo curso
bsico de ES e assim chama ateno dos alunos. Outras competncias no oferecidas pelo curso bsico
de ES, provavelmente, so conhecidas aos alunos, mas a falta de exemplos ou experincia de aplicao
dessas competncias reduz a interesse dos alunos.

4.6 Verificao das hipteses
Hiptese nula (H0): Para verificar a hiptese nula precisamos responder a questo Q1 utilizando a
mtrica M3. O resultado do teste Chi-2 mostra que 7 das 12 competncias no podem ser considerados
como oferecidas pelo curso bsico de ES para os alunos. Assim, podemos fazer concluso, que a lista
de competncias oferecidas para os alunos do curso bsico de ES diferente da lista de competncias
de ES que o currculo mnimo da SBC considera fundamental para o desenvolvimento de software
(hiptese alternativa H1).
No podemos dizer que na lista de competncias oferecidas para os alunos do curso bsico de ES e
que fazem parte do currculo mnimo da SBC existem competncias que os alunos consideram inteis
para o desenvolvimento de software pessoal (hiptese alternativa H2) porque, respondendo a questo
Q2 (mtrica M5) o resultado do teste Chi-2 mostra, que nenhuma das 12 competncias pode ser
considerada como intil.
Finalmente, podemos fazer concluso, que na lista de competncias oferecidas para os alunos do
curso bsico de ES, que fazem parte do currculo mnimo da SBC e consideradas teis para
desenvolvimento de software pessoal, existem competncias cujo detalhamento deve ser modificado
para atingir o nvel esperado pelos desenvolvedores de software pessoal (hiptese alternativa H3)
porque , respondendo a questo Q3 (mtrica M7) o resultado do teste Chi-2 mostra, que todas as 12
competncias precisam de modificao.
Para fazer concluses relevante hiptese alternativa (H4) a anlise qualitativa foi feita. Os resultados
da anlise mostraram que 2 competncias no oferecidas pelo curso bsico de ES provocaram interesse
dos alunos. Assim podemos concluir, que na lista de competncias no oferecidas para os alunos do
curso bsico de ES existem competncias que os alunos gostariam de receber (hiptese alternativa
H4).
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
49
ANEXO 2: CONCEITOS ENVOLVIDOS NUM PACOTE DE EXPERIMENTO

Classe Descrio
Aggregated Results Define os objetivos e hipteses para combinar os resultados de uma
famlia de experimentos repetidos ou similares.
Aggregator Combina os resultados de uma famlia de experimentos similares ou
repetidos.
Analyze Documents Descreve informaes de Anlise como os Casos de Uso da UML e
comentrios.
Assignment Description Descreve informaes sobre os exerccios usados atravs do
experimento.
Code Descreve informaes sobre os programas, funes e interfaces usados
no experimento.
Comments Descreve os comentrios sobre os resultados do experimento.
Component Descreve informaes sobre componentes como bibliotecas e
"componentes de prateleira", usados no experimento.
Course Training Notes Descreve conceitos, termos relevantes e informaes de notas de aulas,
cursos e treinamentos.
Data Descreve informaes sobre os dados resultantes de um experimento.
Defect List Template um template utilizado para descrever os defeitos encontrados em um
experimento.
Defect Lists Descreve os defeitos encontrados no experimento, atravs de uma lista.
Design Documents Descreve informaes de Projeto como Diagramas de Classe da UML.
Documentation Descreve informaes sobre os artefatos no executveis.
Domain Business Model Descreve informaes sobre o Modelo de Negcios.
Domain Description Descreve o domnio da aplicao para o qual os artefatos foram
construdos.
Experiment Artifact Descreve os artefatos do experimento usados em um experimento.
Podendo ser de trs tipos: Template, Measurement ou Guidelines.
Experiment Document Representa os diferentes tipos de documentos utilizados no experimento.
Pode ser de um dos seguintes tipos: Experiment Organization, Result
Forms ou Instrumentos.
Experiment Organization Representa os conceitos relacionados descrio dos documentos de um
experimento.
Experiment Package Representa o pacote contendo as informaes e documentos relativos ao
experimento ou ao conjunto de experimentos.
Experiment Performers Representa as pessoas que executam os experimentos. Eles podem ser de
trs tipos: Profissional, Student ou Industrial Developer.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
50
Experimental Design Descreve informaes sobre o estudo experimental, os participantes, os
artefatos de software, mecanismos do processo, requisitos e hipteses,
projeto experimental, variveis dependentes e independentes, questes e
mtricas, questes no respondidas, questes em aberto e caminhos de
validao.
Experimental Designer Define, projeta e executa um novo experimento.
Experimental Procedure Descreve os procedimentos e aes que devem ser realizados para
execuo de um experimento.
Experimental Raw Results So os resultados crus, que podem estar armazenados em uma planilha
ou em um banco de dados.
Experimental Refined
Results
Descreve os dados analisados provenientes dos resultados crus e que so
sintetizados em Aggregated Results.
Final Report Explica o mtodo utilizado no experimento, bem como a tcnica utilizada
e o que pode ser melhorado.
Function Descreve as funes utilizadas em um artefato de software para produzir
um experimento.
General Reader Aprende ou se atualiza em tcnicas de experimentos ou em um certo
experimento.
Glossary Descreve os termos e conceitos utilizados no contexto de um
experimento especfico. Pode tambm ser utilizado para genericamente
descrever documentos, com uma pequena introduo.
Guidelines Descreve diretrizes como processos, checklists e mtodos usados em um
experimento.
Industrial Developer Descreve os profissionais da rea industrial que podem participar de um
determinado experimento.
Instruments Descreve os instrumentos usados em um experimento. Podendo ser de
dois tipos: Software Artifact ou Experiment Artifact.
Interface Descreve as interfaces utilizadas em um artefato de software para
produzir um experimento.
Librarian Coordinator Tem como funo coordenar as outras Bibliotecas.
Local Theme Librarian Descreve o bibliotecrio com responsabilidades por uma determinada
localidade.
Master Librarian Estabelece e mantm os documentos padres do pacote.
Master Librarian Secretary Tem como funo ajudar o Master Librarian em suas atividades.
Measurement Descreve as mtricas usadas para validar os dados coletados de forma
manual ou atravs de entrevistas.
Observational Note
Template
um template utilizado para descrever as observaes relativas a um
experimento.
Observational Notes Descreve observaes sobre o experimento.
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
51
Open Questions Descreve as perguntas que representam futuras perspectivas de pesquisa.
Partner Description Descreve informaes sobre os parceiros que realizam um experimento.
Practitioner Representa uma pessoa interessada em saber que tipos de tecnologias
foram validadas empiricamente. Esta pessoa no est interessada em
replicar um experimento, mas precisa ter livre acesso aos resultados de
um experimento, avaliando se estes resultados preenchem os requisitos
do seu ambiente de desenvolvimento.
Professional Descreve os profissionais da indstria que fazem parte da classe de
Engenheiros de Software.
Program Text Descreve os programas utilizados em um artefato de software para
produzir um experimento.
Questionnaire Template um template utilizado para descrever as questes de um experimento.
Questionnaires Descreve as questes aplicadas atravs do experimento.
Questions Cannot Answer Descreve as questes que no se consegue responder apenas realizando o
experimento, mas que seria bastante interessante poder respond-las,
como por exemplo: no podemos ter o caso ideal, impraticvel testar
isto, etc...
Readme Reminders Descreve as informaes freqentemente perguntadas sobre o
experimento.
Replicator Responsvel por repetir um experimento.
Report Descreve informaes sobre os resultados de um experimento atravs de
relatrios.
Requirement Documents Descreve as caractersticas que o sistema deve ter em acordo com os
requisitos do usurio. Representa as caractersticas funcionais e no-
funcionais.
Researcher Representa os Engenheiros de Software que desenvolvem pesquisa na
rea.
Result Form Descreve informaes sobre os documentos resultantes de um
experimento.
Software Artifact Descreve os artefatos de software utilizados em um experimento.
Software Engineer Representa os Engenheiros de Software participantes da comunidade.
Eles podem ser pesquisadores.
Software Engineering
Community Members
Representa toda a comunidade de Engenharia de Software participante de
um experimento.
Software Process Model Descreve como o processo de software foi modelado.
Steering Board o comit gestor dos experimentos. Supervisiona e participa dos
experimentos. Tem como funo controlar a qualidade do material
utilizado nos experimentos e nas bibliotecas. Tem ainda como funo
formular o Quality Assurance Rules e supervisionar a evoluo dos
Copyright GHT/DG/EAGA COPPE/UFRJ
RT-ES-590/02
52
documentos padres.
Student Descreve os estudantes que podem participar de um determinado
experimento.
Subject Descreve as pessoas que participam de um experimento planejado.
System Documentation Responsvel pelas informaes sobre o sistema que servem de apoio para
os pesquisadores.
Template Descreve templates usados em um experimento. Podendo ser de trs
tipos: Defect List Template, Observational Note Template ou
Questionnaire Template.
Test Data Case Descreve os casos de teste definidos para o Sistema.
Thematic Area Description Descreve informaes sobre temas gerais e sobre reas tcnicas
especficas.
User Documentation Responsvel pelas informaes sobre o sistema que servem de apoio para
os usurios.
Web Cruiser Descreve as pessoas interessadas em Engenharia de Software que possam
estar navegando pela Internet e lendo parte do contedo dos pacotes.