UNIVERSIDADE ESTADUAL DO CEARÁ

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO CEARÁ

MESTRADO INTEGRADO PROFISSIONALIZANTE EM COMPUTAÇÃO

Disciplina: Engenharia de Software
Professor Dr. Cidcley Teixeira
Métodos Empíricos na Engenharia de Software

Danniel Rocha do Nascimento Gelter Thadeu Maia Rodrigues

Graduado em Ciências da computação pela
Universidade Estadual do Piauí – UESPI
Francisco Célio da Silva Santiago
Graduado em Pedagogia pela Universidade Estadual
Vale do Acaraú – UVA
Cientista Religioso pela UVA e pelo Instituto
Diocesano de Estudos Superiores de Tianguá – IDEST
Pós Graduado em Sistemas para Internet –
Universidade Estadual do Ceará - UECE
Filosofia e Sociologia – Faculdade de Tecnologia e
Ciências – FTC - Bahia
Bacharel em Direito pela Universidade Federal do
Ceará - UFC
Pós Graduado em Direito Processual - UFC
Germano de Oliveira Ribeiro
Graduado em Geografia pela Universidade Federal do
Ceará - UFC
Pós graduado em ensino de Geografia – UFC
Zoralia Brito das Chagas Vasconcelos
Graduada em Matemática pela Universidade Federal
do Ceará – UFC
Pós graduada em Informática Educativa - UFC

Resumo: Este artigo introduz o papel do Empirismo de uma forma geral, partindo do conceito, importância e
aplicabilidade do mesmo em Engenharia de software, a fim de despertar a busca para a melhoria da situação
atual, criar melhores estudos empíricos e tirar interpretações mais sólidas para o futuro. Tem como objetivo
apresentar uma estrutura geral para aplicação dos estudos empíricos em software e os passos concretos para
aplicar melhores estudos nos projetos, a coleta de dados mais efetiva, a importância do trabalho em grupo e o
envolvimento de outros pesquisadores das mais variadas áreas. Exemplifica o tema através de três estudos de
casos. O primeiro caso é um projeto de pesquisa que avalia a efetividade da arquitetura de groupware através
de um experimento controlado, comparando o desempenho dos grupos “cara a cara” com os grupos
distribuídos, baseando-se na qualidade dos perfis de hipótese, desenvolvidos por ambos os tipos de grupo. O
segundo caso é uma avaliação da influência da aplicação de técnicas ágeis, notadamente XP e SCRUM, no
processo de desenvolvimento de software sob os aspectos do uso da comunicação. O terceiro estudo de caso
destaca o uso dos métodos empíricos de forma a permitir que as pesquisas possuam resultados válidos e críveis.
Analisa a relação entre as preferências e as percepções sobre o clima em uma equipe e a relação entre o clima
desejado-percebido e a qualidade no desenvolvimento de um software utilizando-se uma variação de XP.

Palavras-chave: Empirismo. Observação. Experiência. Método empírico. Engenharia de software.

Abstract: This article introduces the role of Empiricism in general, based on the concept, importance and
applicability of it in engineering software in order to awaken the quest to improve the current situation, create
better empirical studies and interpretations get stronger for the future. Aims at presenting a framework for
applying the empirical studies in software and concrete steps to implement best studies on the projects, the data
collection more effective, the importance of working in groups and the involvement of other researchers from
many different areas. Exemplifies the theme through three case studies. The first case is a research project that
evaluates the effectiveness of the architecture of the groupware through a controlled experiment, comparing the
performance of groups "face to face" with the groups distributed based on the quality of profiles of hypothesis,
developed by both the type of group. The second case is an evaluation of the effects of applying agile techniques,
especially XP and Scrum in the software development process under the aspects of the use of the communication.
The third case study highlights the use of empirical methods to enable the research results are valid and
credible. Examines the relationship between preferences and perceptions about the climate in a team and the
relationship between climate and the perceived quality-liked in the development of software using a variation of
XP.

Keyword: Empiricism. Observation. Experience. Empiric method. Software engineering.

 2

1. INTRODUÇÃO

O empirismo (Grego= “empeirikós” - Latim= “empiricu”) revelou-se na filosofia

grega sob a forma sensualista (sensação), citando-se como seus representantes Heráclito,
Protágoras e Epicuro. Na Idade Média seu mais significativo adepto foi Guilherme de Occam;
expressou-se então por meio do nominalismo, cuja tese central é a não-existência de conceitos
abstratos e universais, mas apenas de termos ou nomes cujo sentido seria o de designar
indivíduos revelados pela experiência.
O empirismo moderno tem como seus principais representantes John Locke, Thomas
Hobbes, George Berkeley e David Hume. Locke argumentou que a mente seria,
originalmente, um quadro em branco (tábua rasa), sobre o qual é gravado o conhecimento,
cuja base é a sensação.
O método empírico é geralmente observado como sendo o fulcro do método científico
moderno. Defende que as nossas teorias devem ser baseadas em observações do mundo, em
vez da intuição ou fé. Defende a investigação empírica e o raciocínio dedutivo. Todo o
processo do conhecer, do saber e do agir é aprendido pela experiência, pela tentativa e erro.
Para o Empirismo adquire-se a sabedoria através da percepção do mundo externo, ou
então do exame da atividade da nossa mente, que abstrai a realidade que nos é exterior e as
modifica internamente (CHAUÍ, 2003). Daí ser o Empirismo de caráter individualista, pois tal
conhecimento varia da percepção, que é diferente de um indivíduo para o outro. Na
Engenharia de software esse individualismo não pode acorrer, pois a experiência e os
resultados observados por várias pessoas em uma mesma pesquisa é o que vai dar o caráter de
significação e credibilidade ao produto final.

2. ESTUDOS EMPÍRICOS NA ENGENHARIA DE SOFTWARE

Os estudos empíricos são apenas testes que comparam o que acreditamos ao que
vemos. Porém, se tais testes, forem sabiamente construídos, executados e utilizados para
apoiar o método científico, os mesmos passam a ter um papel fundamental na ciência
moderna. Especificamente, eles nos ajudam a entender como e por que as coisas funcionam, e
nos permitem usar esta compreensão para alterar nosso mundo materialmente. Entretanto,
observa-se que nas pesquisas de Engenharia de Software, os métodos empíricos não tiveram
tanto êxito, comparado ao seu amplo uso nas outras ciências.
Possuem, de modo geral, planejamentos estatísticos pobres, não fazem a diferença dos
grandes sistemas e são administrados em um curto espaço de tempo (FENTON, PFLEEGER e
GLASS, 1994).
Segundo BASILI (1996), as muitas diferenças entre projetos de software individuais
causam uma difícil comparação. Seguramente, estes e muitos outros fatores afetam o uso de
estudos empíricos. Porém, acreditamos que, mesmo se eliminássemos as dificuldades
encontradas nos estudos empíricos, ainda não teríamos o mesmo resultado verificado em
outras áreas. Isto porque há um distanciamento entre os estudos empíricos realizados e as
metas que queremos alcançar com esses estudos.
Com isso, necessitamos refletir nas experiências e como elas podem ser usadas para
melhorar efetivamente o desenvolvimento de software. Acreditar que este problema é o maior
desafio que está à frente dos pesquisadores empíricos.

3. POR QUE OS ESTUDOS EMPÍRICOS?

Nos grandes projetos de software, há as fases de desenvolvimento, como a definição

de exigências, o projeto funcional, o mecanismo de implementação, a integração, que são
 3

administradas e usam ferramentas de apoio amplamente variadas. Alguns desenvolvedores

possuem rigorosos processos, outra parte, acatam as decisões dos próprios administradores
que se baseiam em seus experimentos individuais, outros seguem tradições institucionais por
falta de alternativas satisfatórias. Por isso, e pelo fato da pesquisa de desenvolvimento de
software não ter produzido modelos e ferramentas analíticas que são comuns em outras
ciências, os custos e benefícios dos processos são raramente compreendidos, sendo um
problema muito sério. A ponto de refletirmos se nossas ações estão partindo de suposições
coerentes, se a avaliação de novos métodos está correta.
Os estudos empíricos são percebidos como experiências formais, como estudos de
caso, pesquisas e na criação de prototipagem. Sua essência é aprender algo útil comparando
teoria à realidade e melhorar os resultados. Então, envolvem os seguintes passos: formular a
hipótese ou o problema para a experiência, observar uma situação, resumir as observações em
dados, analisar os dados e tirar conclusões. Sendo a etapa “tirar resultados”, a mais importante
e freqüentemente a menos bem feita, devido ser as conclusões um guia para o futuro da área.
Muitos documentos não conseguem aproveitar os seus resultados. Precisamos aprender
alguma coisa com cada estudo e relacionar estas coisas à teoria e a prática.

4. A PESQUISA EMPÍRICA ATUAL

O ideal do estudo empírico seria permitir-nos positivamente afetar a prática do

desenvolvimento de software, mas isto ainda é uma ilusão. Vejamos:

4.1 Atuais pontos fortes

Mais percebemos que não existe apenas os fatores negativos, podemos encontrar
alguns pontos positivos neste Apesar de todos os problemas até então já citados, poderemos
mencionar alguns pontos fortes da Engenharia empírica de software. Como o seu
amadurecido ao longo dos últimos 10-20 anos, tendo a validação empírica considerada
normal em alguns sub-domínios da engenharia.
Há um aumento crescente na média da qualidade destes estudos, e pela quantidade de
artigos e publicações sobre o tema, pelo fato dos pesquisadores estarem mais educadores na
condução dos estudos empíricos, sensibilizados pela proposta de eficácia dos estudos.
Agências financiadoras estão reconhecendo o valor dos estudos empíricos, como a
National Science Foundation (NSF-EUA), que programa suas pesquisas baseadas em
atividades experimentais. Vários são os eventos, workshop, conferências e outros sobre o
tema da estatística e engenharia de software.

4.2 Problemas sistêmicos

Antes que possamos melhorar a utilização dos estudos empíricos, temos que eliminar
algumas problemáticas práticas e crenças.
Verifica-se na Engenharia de Software, que os pesquisadores não validam suas
pesquisas e idéias, tornando seus trabalhos com pequena visibilidade.
Nos encontros do projeto de software, discute-se muito sobre o número de testes
estatísticos usados ou se não teria sido melhor se tivesse feito uma coisa ou outra. E no final,
o que é mais importante do estudo é saber se a pesquisa e suas conclusões são fundamentadas
e acreditável.
Muitos estudos empíricos estudam o óbvio, onde o ideal seria investigar e refletir
sobre as questões mais difíceis que estamos estudando empiricamente.
 4

Existem muitos documentos cujo único ponto de venda é o banco de dados. Nossos
dados devem ser utilizados para responder a perguntas, e não para encher gráficos.
Concretamente, faltam-lhes as hipóteses. Assim, no final do estudo, o pesquisador só pode
apresentar observações sobre os dados. Todo estudo, até estudo de caso, deve ser concebido
para responder perguntas, dar resultados.

5. DESAFIOS FUTUROS PARA ESTUDOS EMPÍRICOS

Para PERRY, PORTER e VOTTA (2000), se quiser que estudos empíricos melhorem
a investigação e as práticas de Engenharia de Software, tem-se que criar melhores estudos e
acreditar em suas conclusões.

5.1 Criação de estudos empíricos melhores

Será um meio de desenvolver esses estudos para que tenham mais chance de dirigir a
investigação. Para isso, os estudos empíricos têm que ter objetivos claros, projetá-los mais
eficazmente, maximizar a informação resultante, resolver questões importantes.
Nossos estudos devem esforçar-se por estabelecer princípios que sejam causal,
acionável e geral. Quando temos uma relação causal, sabemos por que algo acontece. Se o
agente for acionável, então temos um botão que pode ser girado para controlar o resultado. Se
for geral, será útil para uma vasta gama de pessoas em um amplo conjunto de contextos.
Estudos individuais não demonstram clareza, surgindo diversos estudos para resolver
grandes problemas, às vezes, até com aspectos complementares. Como são normalmente
caros e demorados, tem-se que encontrar formas de se obter a informação desejada a um
baixo custo, tomando alguns atalhos em nossos experimentos ou tentando resolver problemas
menores de maneira mais focalizada. Os estudos empíricos ganham credibilidade quando são
refeitos e reverificados. Precisamos encontrar maneiras de ajudar os outros a reproduzir os
nossos resultados.

5.2 Interpretações acreditáveis

A credibilidade de um estudo refere-se ao grau de confiança que temos nas suas

conclusões. Se os estudos não são credíveis, o tempo gasto fazendo-lhes foi desperdiçado.
Temos que projetar experimentos com alta validade, que é à base do estabelecimento de
conclusões credíveis. Existem três tipos de validade importantes: interna, externa e a de
construção.
Nossos estudos devem ter hipóteses, ou seja, definir o que comparar e o porquê.
Devemos evitar a tentação de medir tudo com a melhor precisão possível. Às vezes,
ele será o suficiente para identificar um limite inferior e superior; outras vezes, será o
suficiente para medir a uma resolução bruta. A definição de precisão adequada dependerá do
problema, mas usando grosseiras medições podem ser uma forma de limitar estudo dos
custos, e ainda obter informações importantes.
Dados e procedimentos devem ser publicados para que outros possam compreender,
analisar e eventualmente duplicar os estudos..

5.3 Projetando um estudo empírico

Com tudo isso, podemos concluir que o estudo não é perfeito e que o verdadeiro
desafio é a criação, concepção e condução de alto impacto dos estudos acreditáveis. Isto
envolve a gestão de “trade-offs” de tal maneira que maximizamos a precisão de interpretação
 5

(os resultados que vemos não sejam resultados de influência desconhecida), a relevância (tais
resultados são importantes sobre Engenharia de Software), o impacto (os resultados afetam a
prática da pesquisa em Engenharia de Software). Submetido às limitações de recursos:
estudos são caros, temos de trabalhar dentro de limitações dos recursos; e de risco (estudos,
especialmente os feitos na indústria, podem prejudicar ou pôr em risco os parceiros
industriais; temos que minimizar estes problemas).

6. A ESTRUTURA DE UM ESTUDO EMPÍRICO

Segundo os autores, PERRY, PORTER e VOTTA (2000) a estrutura e os

componentes para um bom estudo empírico, devem conter os seguintes elementos: Contexto
da investigação, Hipóteses, Projeto experimental, Ameaças à validade, Análise e apresentação
de dados e os Resultados e conclusões.

6.1 O Contexto da investigação

Todos os estudos incidem sobre um problema. Esta seção une as metas de estudo ao
que é atualmente compreendido sobre o problema. Esta seção tem duas partes: a definição do
problema e a revisão de pesquisa (descreve o contexto histórico em torno do problema, o que
sabemos, o que foi feito anteriormente, as perguntas sem respostas e questões centrais do
problema).

6.2 Hipóteses

As hipóteses são essenciais. Afirmam as questões de investigação que estamos

pedindo. O devemos fazer é pensar em um estudo como um procedimento para a realização
de uma comparação. Inicialmente, com perguntas de alto nível (hipóteses abstratas), que são
declaradas em condições cotidianas. Elas dizem coisas como: "as reuniões são uma parte
indispensável do processo de inspeção". Depois, refinamos em questões de baixo nível
(hipóteses concretas), são em termos de concepção do estudo, como por exemplo "equipes
que fazem reuniões com inspeções encontram mais defeitos do que equipes que fazem
inspeções sem elas".

6.3 Projeto do estudo

É um plano detalhado para criar os dados usados para testar as hipóteses.

Um dos seus componentes é o conjunto de variáveis dependentes e independentes,
entre as causas e efeitos. As variáveis independentes são os atributos que definem a
configuração do estudo. As variáveis dependentes são as saídas do final do processo cujos
valores previsíveis são esperados, dependem dos valores das variáveis independentes.
O projeto do estudo pode incluir um plano sistemático para manipular as variáveis
independentes, respeitando as variáveis dependentes.
Por fim, o contexto operacional do estudo, onde descreve o desenvolvimento físico,
intelectual e cultural do estudo.

6.4 Ameaças à Validade

São as influências que podem limitar a nossa capacidade de interpretar ou tirar

conclusões a partir dos dados do estudo. Há pelo menos três tipos de validade a serem
protegidas. A Validade Interna significa que mudanças nas variáveis dependentes podem ser
 6

atribuídas às mudanças na segurança das variáveis independentes. A Validade Externa

significa que os resultados do estudo generalizam as configurações fora do estudo. E
Construir Validade significa que as variáveis independentes e dependentes são modelos
precisos às hipóteses abstratas.

6.5 A análise dos dados e apresentação

As duas abordagens gerais para apresentação e análise dos dados são:

Análise Quantitativa trata principalmente da comparação com os dados numéricos. As
comparações são normalmente destinadas a rejeitar ou não rejeitar uma hipótese nula.
Análise Qualitativa tende a usar os dados que são menos facilmente quantificados:
observação, entrevistas, agendas etc. São utilizadas para entender as perspectivas das pessoas
de uma situação. Normalmente, os pesquisadores devem ser muito cuidadosos para que seus
‘preconceitos’ não afetem os dados.
Na Engenharia de software a pesquisa de análise qualitativa é menos utilizada do que a
análise quantitativa, mas nós podemos esperar para vê-la acontecer mais freqüentemente no
futuro. Como GLASSER e STRAUSS (1977) apontam “Em muitos casos, ambas as formas
de dados são necessários, ambos devem ser utilizados como suplementos, como verificação
mútua e, mais importante para nós, como diferentes tipos de dados sobre o mesmo assunto.”

6.6 Resultados e Conclusões

Depois de análise dos dados temos que dar sentido aos mesmos. Temos de tentar
compreender e explicar as limitações do estudo. Que conclusões se podem tirar? Que
influências tivemos nos resultados? O que os dados realmente dizem? Há ambigüidades na
nossa interpretação? Podemos dar outras explicações para os dados que vemos? Nossos
resultados são realmente críveis?
Qual o significado prático dos resultados? Se esses resultados se revelaram gerais e o
que os técnicos ou desenvolvedores podem fazer com eles? Certifique-se de ter dado
informações suficientes para outras pessoas para ajudá-las a repetir o estudo, se quiserem.

7. PASSOS CONCRETOS

No intuito da Engenharia de software reordenar os pensamentos de seus pesquisadores

nos objetivos dos estudos empíricos e melhorar sua administração e avaliação, PERRY,
PORTER e VOTTA (2000), citam algumas estratégias concretas de como fazer isso.

7.1 Projetando o estudo - fazer perguntas compreensíveis

Uma das coisas mais importantes que os pesquisadores podem fazer é elaborar
perguntas compreensíveis, limitadas, criteriosas, para torná-las mais precisas, e assim chegar
às respostas importantes. Como exemplo, os estudos de KNIGHT and LEVESON (1986)
sobre a programação N-Version é um bom exemplo de uma questão compreensiva. A
programação N-Version refere-se a redundância em software utilizando as esperanças de
alcançar elevada confiabilidade. Esses estudiosos notaram que esta esperança depende
fortemente do pressuposto que módulos redundantes fracassam de forma independente. Se
eles não fizessem, então a confiança do sistema global não seria tão alto quanto esperado.
Assim, eles estudaram se os módulos desenvolvidos realmente falham de forma
independentemente. A conclusão foi que, em vez disso, as falhas do módulo não eram
independentes e que, portanto, a programação N-Version não cumpriu sua promessa de alta
 7

confiabilidade. Isto provocou uma grande discussão, o que levanta dúvidas sobre a validade
do próprio estudo, o efeito exato de falhas dependentes na confiança dos cálculos, e se o
insucesso da dependência poderia ser evitado. Isto é exatamente o que um bom estudo pode
fazer.

7.2 Famílias de Estudos

Cada pergunta não se presta a um único estudo empírico. Para muitas questões temos
que fazer muitos estudos. Nestes casos, criamos e não apenas realizamos um estudo, mas uma
família de estudos. Aqui temos de pensar em toda a gama de questões, o que vamos perguntar
e projetar nos estudos individuais para apoiar os objetivos gerais. Pode ser possível levantar
mais perguntas do que possamos responder e por isso precisam atender uma família
seqüencial de estudos para resolver essas questões relacionadas à medida que forem surgindo.
A chave fundamental aqui é que a observação. Podemos projetar e administrar uma
série de estudos que, em conjunto, vão nos ajudar a responder a uma pergunta maior.

7.3 Construir parcerias

Esses tipos de experiências sugeridos serão difíceis para uma só pessoa. Logo, a
sugestão é a criação de parcerias. É colocar os estudantes em ambientes industriais, onde
poderá administrar e controlar o estudo, aprender sobre a prática da engenharia de software,
desenvolver contatos profissionais, controlar alguma documentação de um estudo.
Também criar equipes de pesquisa interdisciplinar, com pessoas de áreas diversas, é
outra grande idéia. A equipe do projeto inclui pesquisadores em Estatística, Experimentação,
teoria organizacional, linguagens de programação, Engenharia de Software e Visualização.
Outro problema importante é saber quando parar o estudo. Estudos utilizando
desenvolvedores profissionais que criam produtos profissionais têm validade muito forte, mas
pode colocar em risco o projeto participante. Uma solução é parar qualquer tratamento
problemático se há observações suficientes para se convencer que nada "de azar" tenha
acontecido. Isso irá exigir um modelo estatístico e vai, certamente, exigir acompanhamento de
perto do estudo.

7.4 Obtendo os Dados

Muitos estudos buscam os seus dados através de medição sujeitos à medida que
executam tarefas pré-determinadas. Deveríamos explorar outros métodos para adquirir dados.

- Simulação e Modelagem Matemática

Outra forma de gerar dados é usar modelos matemáticos ou simulações. Embora
possam ser muito poderosas, têm também suas próprias limitações. Gostaríamos de ver uma
maior utilização de simulação e modelagem em conjunto com estudos dirigidos.
- Outros estudos envolvendo Meta-Análise
Não existe um único estudo que apresenta resultados inequívocos. Portanto, é
imperativo que a comunidade de pesquisa integre e compare estudos que abordam hipóteses
comuns. Esta é a única maneira de ganhar confiança de que os resultados empíricos são reais
e não apenas uma variação aleatória.
- Laboratórios educacionais
Outra grande dificuldade verificada é que os pesquisadores raramente são treinados
para realizar experimentos de alta qualidade. Uma maneira fácil de corrigir isso é integrar
métodos experimentais para a graduação curricular. Criar módulos pedagógicos nos quais os
 8

alunos realizam experiências, recolhem e analisam dados e testam hipóteses, como parte da
sua graduação nos cursos de engenharia de software, pode ser uma sugestão.
Estes módulos poderão ser adaptados na forma de ensino laboratoriais de estudos
empíricos. Os exercícios em laboratórios educacionais são uma parte normal das ciências
físicas. Nestes laboratórios os alunos necessitam aprender e aplicar o método científico,
analisar os princípios físicos. Enquanto administrando um laboratório o aluno monitora o
processo físico, recolhe e analisa dados sobre o processo, e usa os dados para testar hipóteses,
o que muitas vezes desafia a sua intuição.

8- ESTUDO DE CASO 1 - Comparando reuniões distribuídas e cara-a-cara para

avaliação da arquitetura de software: uma experiência controlada

A avaliação da arquitetura de software provou ser uma técnica eficaz de garantia

assegurada que ajuda a descobrir os riscos potenciais de arquitetura antes que se tornem caros
para consertar (BASS et al. 2003; CLEMENTS et al. 2002; MARANZANO et al. 2005). A
maioria das abordagens das avaliações de arquitetura de software atuais, contam intensamente
com os esforços colaborativos de vários sócios para desempenhar variadas tarefas, tais como:
definir e refinar determinantes de negócios, criação de perfis hipotéticos, por exemplo, uma
série de hipóteses para especificar precisamente os requisitos de qualidade requeridos, como
segurança, manutenção, e desempenho, e mapeamento de hipóteses de acordo com a
arquitetura proposta para raciocinar sobre a adequabilidade das várias decisões arquitetônicas
(ALI-BABAR et al. 2004).
A maioria destas tarefas é desempenhada numa reunião “cara a cara”, colocando um
grande número de sócios de maneira ordenada, lado a lado. De fato, KAZMAN e BASS
(2002) sugerem que as reuniões de avaliação da arquitetura de software aconteçam longe dos
pontos de desenvolvimento para evitar grandes interrupções ou distrações. Reunir os sócios
para um número de sessões pode ser um exercício caro e que, também, pode causar
dificuldades de programação.
Numa tentativa de encontrar as tecnologias e técnicas apropriadas para dirigir alguns
desses problemas, a pesquisa propôs que os sistemas de software colaborativo (groupware)
pela internet podem proporcionar uma alternativa eficaz e eficiente de custo para as reuniões
“cara a cara” de avaliação da arquitetura de software.

8.1 Origem da pesquisa

O projeto de pesquisa analisou a efetividade do processo de avaliação da arquitetura

de groupware através de um experimento controlado. O experimento controlado foi
desenhado para comparar o desempenho dos grupos “cara a cara” com os grupos distribuídos,
baseando-se na qualidade dos perfis de hipótese, desenvolvidos por ambos os tipos de grupo.
Foi sugerido que se não for possível demonstrar que a qualidade dos perfis de hipótese
gerados, num arranjo distribuído, usando um sistema de groupware, não é significativamente
pior do que a qualidade dos perfis de hipótese gerados nas reuniões “cara a cara”, os gerentes
descobririam que a economia de custos inerente nas reuniões distribuídas, equilibraria
qualquer pequena perda em qualidade nos resultados das reuniões.

8.2 Avaliação empírica

Perguntas e Hipóteses da Pesquisa

1. Como o apoio do groupware afeta a qualidade dos resultados do processo de avaliação
da arquitetura de software?
 9

2. Como o apoio do groupware a satisfação dos participantes com o processo e com o

processo de avaliação da arquitetura de software?
3. Que tipos de características uma aplicação de groupware deveria proporcionar para
dar um suporte de sucesso ao processo da arquitetura de software distribuído?

Hipótese Nula: Não há diferença entre a qualidade dos perfis hipotéticos

desenvolvidos por grupos trabalhando em reuniões F2F e grupos trabalhando em reuniões
distribuídas usando um sistema de groupware.

Hipótese Alternativa 1: A qualidade dos perfis hipotéticos desenvolvidos por grupos

trabalhando em reuniões F2F é significativamente melhor do que a qualidade dos perfis
hipotéticos desenvolvidos por grupos trabalhando em reuniões distribuídas usando um sistema
de groupware.

Hipótese Alternativa 2: A qualidade dos perfis hipotéticos desenvolvidos por grupos

trabalhando em reuniões distribuídas usando um sistema de groupware é significativamente
melhor do que a qualidade dos perfis hipotéticos desenvolvidos por grupos trabalhando em
reuniões F2F.

8.3 Desenho do experimento

Foi usado o desenho de transição AB/BA. Num desenho de estudo de transição, os

participantes são designados para uma seqüência de tratamentos para estudar diferenças entre
tratamentos individuais. Esse é um desenho de equilíbrio no qual cada unidade de
experimento (ex.: grupos de três participantes para este estudo) desempenham duas tarefas de
desenvolvimento de perfil hipotético para dois sistemas diferentes.
Metade dos grupos usa uma reunião F2F na sua primeira tarefa seguida de uma
reunião distribuída para a segunda tarefa. Como os perfis hipotéticos precisam ser concretos,
decidiu-se selecionar apenas um atributo de qualidade, manutenção, para o desenvolvimento
de perfis hipotéticos. Isso significa que os participantes devem construir perfis hipotéticos de
software. Porém, o desenho do experimento permite que os resultados sejam aplicados aos
perfis hipotéticos de outros atributos de qualidade também (BENGTSSON 2002).
As vantagens do desenho de transição é que eles requerem menos participantes do que
os desenhos paralelos e quando não há interação (ou interação insignificante) entre os
tratamentos e ordem, eles são resistentes às diferenças de sujeitos e afeitos de maturação. A
desvantagem mais significante de um desenho de transição é que será inapropriado se houver
uma grande interação entre tratamento e ordem.
Os participantes eram estudantes do 3º e 4º ano dos cursos de engenharia de software e
engenharia da computação da Universidade de New South Wales, Austrália. Baseado nos
resultados de uma poderosa análise dos dados do estudo piloto, 50 unidades experimentais
(grupos de 3 sujeitos) foram consideradas um tamanho de amostra suficiente. O estudo foi
parte de um curso sobre administração da qualidade de software no qual 159 estudantes
estavam matriculados, o que deu o número requerido de unidades experimentais.
Para calcular o desempenho dos grupos trabalhando num arranjo distribuído
comparado aos grupos trabalhando num arranjo F2F para o processo de avaliação de
arquitetura de software. BENGTSSON (2002) propôs um método para avaliar a qualidade dos
perfis hipotéticos baseado num processo de classificação que compara cada perfil hipotético
com um perfil hipotético de referência. Para se usar esse método, o perfil hipotético
propriamente dito para cada indivíduo e grupo precisa ser recodificado num formato padrão
para análise. A qualidade de cada perfil hipotético recodificado é determinada pela
 10

classificação indicada para aquele perfil hipotético baseado na sua comparação com um perfil
hipotético de referência construído a partir de todas as hipóteses únicas encontradas num
perfil hipotético recodificado criado para um sistema particular.
Já que a construção do perfil hipotético de referência depende do julgamento subjetivo
e conhecimento de um indivíduo, dois pesquisadores recodificaram perfis hipotéticos e
construíram dois perfis hipotéticos de referência independentemente. A confiabilidade da
codificação foi calculada comparando os perfis hipotéticos de referência, construídos pelos
dois pesquisadores, que checaram e discutiram ajustes léxicos para ser feitos nos perfis
hipotéticos para a construção do perfil hipotético de referência e o cálculo de valores para
cada perfil hipotético.

8.4 Resultados e análise

A análise resultados da regressão indica que baseado em 32 observações, o principal

efeito do tratamento (ex.: a principais diferenças entre a qualidade de perfis hipotéticos dos
grupos distribuídos e dos grupos F2F, por exemplo, D-F2F é 209.55 com uma margem de erro
de 36.88. O valor é significativamente diferente de zero (p<0.001, 95% intervalo de confiança
134.24 para 284.87). Isso sugere que o processo de arranjo distribuído para a geração de
perfis hipotéticos é superior ao processo de arranjo F2F em termos de qualidade de perfis
hipotéticos.
Os resultados dos dados auto-reportados indicam que a maioria dos participantes
preferiu a reunião em arranjo “cara a cara” e acharam que tiveram um melhor desempenho
neste tipo de arranjo. Isto é verificado através da porcentagem dos participantes que
reportaram o efeito negativo da ferramenta colaborativa na discussão em grupo (69%); eles
acharam as reuniões em arranjo F2F mais eficientes (60%); e preferiram a reunião F2F (82%)
à reunião distribuída com ferramenta de suporte.

9- ESTUDO DE CASO 2 - O impacto de práticas ágeis em comunicação no

desenvolvimento de software

Nos últimos anos, cresceu o uso das técnicas ágeis de desenvolvimento, como forma
da empresa ajustar-se às dinâmicas do mercado, às exigências dos novos clientes e inovações
tecnológicas.
Continuando as análises práticas sobre o tema de Métodos Empíricos em Engenharia
de Software, será analisado outro caso cujo título traduzido é “O impacto de práticas ágeis na
comunicação no processo de desenvolvimento de software.”
O objetivo desse estudo é avaliar a influência da aplicação de técnicas ágeis,
notadamente XP (eXtreme Programming) e SCRUM, no processo de desenvolvimento de
software, no que tange ao uso da comunicação. A base para o estudo em tela foi um estudo de
um caso de uma empresa finlandesa (F-Secure), na qual foram aplicados e medidos o uso das
técnicas ágeis em dois processos de desenvolvimento.

9.1 A comunicação e sua importância no projeto de desenvolvimento.

Para coordenar um processo de desenvolvimento de software, é essencial ter uma

comunicação clara entre os diversos atores do processo, tanto para dar fluência ao
desenvolvimento do sistema em si, como para subsidiar o projeto na parte de documentação.
A comunicação pode ser descrita como o meio para gerenciar os relacionamentos entre
os diversos atores do processo de desenvolvimento de software (equipes desenvolvedoras,
 11

gerentes e clientes). Por isso, um bom processo de comunicação pode ser considerado como
um dos fatores de sucesso de um projeto de desenvolvimento de software.
Em desenvolvimento de software, comunicação implica em que diferentes pessoas
trabalham em um mesmo projeto, tem a mesma idéia do que eles estão construindo e
compartilham informações sobre esse projeto. Logo, a questão central dessa pesquisa foi:
como o uso de práticas ágeis afeta a comunicação nas equipes desenvolvedoras de software e
a organização em si?
Importante destacar que a metodologia de desenvolvimento de software escolhida para
o estudo, ou seja, o uso de técnicas ágeis, não tem em sua essência o objetivo de primar pelo
uso da comunicação formal durante o projeto, enfatizando muito mais a troca tácita de
conhecimento entre os membros do grupo. É claro que a comunicação formal vai existir, tal
como códigos fonte, testes de caso e um mínimo de documentação. Mas essa não é a essência
do uso de técnicas ágeis.

9.2 Os tipos de comunicação

Para uma melhor compreensão do processo de comunicação, é comum dividi-la em

dois tipos: formal e informal. Essa classificação ressalta os diferentes tipos de interação entre
os atores do processo de desenvolvimento, conforme demonstrado abaixo:

Tipos de Comunicação Formas de comunicação

Conversas diretas entre os membros
da equipe. Conversas informais por
Informal telefone, vídeo, áudio conferência,
voice mail e email.

Reuniões em grupos (semanalmente,

e.g.), reuniões de avaliação de
milestones e apresentação de
Formal andamento do projeto.

Documentação Formal, como por

exemplo, documento de requisitos

Outra classificação divide o processo de comunicação entre comunicação interna e

comunicação externa. A comunicação interna pressupõe o processo de interação entre os
membros da equipe desenvolvedora. Já a comunicação externa pressupõe a interação entre os
desenvolvedores e demais stakeholders do processo, como clientes, gerentes, grupos de
suporte e demais intervenientes no projeto.
Com base nas informações acima, o estudo definiu um framework que contemplava
tanto as relações de dependência entre os atores quanto a influência da comunicação externa
(desenvolvedores e colaboradores) e interna (desenvolvedores entre si). A partir dessa
proposta de trabalho foram traçadas as diretrizes de estudo e a análise dos resultados.

9.3 Os níveis de dependência no processo de comunicação

A interação dos diversos atores no processo de desenvolvimento de um software

produz entre eles níveis de dependência durante o projeto. Esses níveis de dependência podem
se classificados em:
 12

• Dependência entre tarefas e recursos: afeta diretamente os gerentes e os

analistas desenvolvedores, pois para cada tarefa a ser executada pelos analistas,
os gestores alocam os recursos necessários, sejam eles humanos, materiais ou
financeiros.
• Dependência entre produtor e consumidor: em outras palavras, significa a
dependência entre quem desenvolve e quem precisa do software desenvolvido,
ou seja, analista e usuário, respectivamente e visa medir a usabilidade do
sistema desenvolvido.
• Dependência entre tarefas e sub-tarefas: significa o processo de decomposição
das tarefas em sub-tarefas menores, com o objetivo de facilitar a visualização
dos objetivos desejados. Essa dependência afeta diretamente os clientes,
gerentes e analistas desenvolvedores.
• Dependência entre requisitos e características: essa dependência afeta
diretamente os requisitos de sistema e demanda uma análise continua por parte
de todos os atores no processo de desenvolvimento (clientes, analistas,
gerentes, arquitetos de software e engenheiros de qualidade.

9.4 O caso estudado

O estudo consistia em acompanhar, documentar e analisar dois projetos da empresa F-

Secure. O primeiro projeto tinha por objetivo desenvolver uma ferramenta de gerenciamento
de um sistema de segurança, era composto por 06 pessoas (04 engenheiros de software, 01
líder de projeto e 01 engenheiro de qualidade) e teve um prazo de duração de 18 meses.
Já o segundo projeto tinha por escopo desenvolver uma aplicação de segurança para
um dispositivo móvel, era composto também por 06 pessoas (04 analistas, 01 gerente de
projeto e 01 engenheiro de qualidade) e teve um prazo de duração menor: 04 meses.
A ambos os projetos foram aplicados técnicas ágeis de desenvolvimento e catalogados
os resultados. Tais resultados foram fruto de um processo de observação, entrevista com
gravação e documentação das atividades dos membros dos projetos.

9.5 Análise empírica dos resultados

Durante o processo de desenvolvimento, ambos os projetos analisados adotaram

técnicas de comunicação informal entre seus membros, o que foi considerado por todos como
sendo uma vantagem na utilização de técnicas ágeis, já que essa informalidade favorece o
contato entre os membros e a troca de informações entre eles, fazendo com que todos se
sintam parte do processo de desenvolvimento. Entretanto, os colaboradores externos do
projeto 2 fizeram uma ressalva quanto ao uso dessa modalidade de comunicação, pois ela
prescinde da fase de documentação do projeto e isso acabou sendo destacado como um ponto
negativo. Como forma de contornar essa situação, durante as reuniões do projeto os próprios
colaboradores externos tratavam de documentar o desenvolvimento.
Também foi aplicada a ambos os projetos a técnica de programação em pares, o que
favoreceu consideravelmente a continuidade do processo de desenvolvimento, já que duas
pessoas acompanhavam a confecção do código ao mesmo tempo em que faziam o processo de
crítica sobre o programa criado, mitigando a existência de erros na linha de programação.
Como forma de acompanhar o andamento dos projetos, ambos os projetos iniciaram
com o uso de uma storyboard, entretanto os desenvolvedores do projeto 1 acabaram por
substituir esse método pelo envio diário de planilhas contendo o progresso do projeto
desenvolvido. A storyboard foi utilizada pelos usuários do projeto 2 até o final, tendo obtido
entre os analistas uma boa avaliação.
 13

Outro ponto bastante interessante abordado no estudo, foi a alocação dos analistas e
programadores de cada projeto em um mesmo espaço físico (cada projeto em um mesmo
espaço físico e não os dois no mesmo ambiente). Os desenvolvedores do projeto 1 avaliaram
com muita positividade trabalhar em um mesmo espaço físico, inobstante tenha havido
aqueles que destacaram que isso também é um ponto negativo, pois dificulta a concentração
dos desenvolvedores, conforme exemplificado por um analista do projeto 1, o qual relatou ter
dificuldades de concentração no ambiente, pois enquanto uns programavam, os outros
estavam em reuniões naquele mesmo ambiente.
Os analistas do projeto 2 foram mais alem. Durante o curso do projeto, decidiram
realocar todos em salas separadas (maneira tradicional), em virtude do grande número de
reclamações de dificuldade de concentração por parte dos desenvolvedores. Entretanto, ao
final do projeto, os mesmos analistas ressaltaram que trabalhar em salas separadas prejudica a
colaboração e a sensação de conjunto da equipe.

9.6 Conclusões

Foi observado na prática que o emprego de técnicas ágeis de programação favorece

consideravelmente o aumento da comunicação interna informal entre os membros de uma
equipe. Das técnicas estudadas, a alocação de todos os programadores no mesmo espaço
físico, foi aquela destacada como sendo a que mais contribuiu e que mais obstáculos criou
para o Projeto.
O uso de reuniões, relatórios de status do projeto e divisão das tarefas em sub-tarefas
menores, também contribuiu para o incremento do processo comunicativo.
Já com relação à comunicação externa (desenvolvedores e stakeholders), pode-se notar
muitas vezes uma dicotomia de interesses, onde os analistas estão focados em desenvolver o
projeto, enquanto os colaboradores buscam informações sobre o andamento do projeto,
notadamente através de documentação das etapas de desenvolvimento.

10 ESTUDO DE CASO 3 - Para entender a relação entre o clima da equipe e a

qualidade de software - um estudo quase-experimental

Por fim, veremos um último caso de trabalho exemplificando o uso de Métodos

Empíricos em Engenharia de Software. Trata-se do artigo “Toward understanding the
relationship between team climate and software quality: a quasi-experimental study”
(ACUÑA, GÓMEZ & JURISTO, 2008) (Entendendo as relações entre o clima da equipe e a
qualidade do software: um estudo quase-experimental, em uma tradução livre).
Pela extensão e complexidade do citado artigo, assim como pelo fato do foco deste
trabalho não residir nas demonstrações de como utilizar estatística, mas no uso de métodos
empíricos de forma a permitir que as pesquisas possuam resultados válidos e críveis, não
veremos muito profundamente como cada método estatístico foi utilizado, mas uma maior
atenção será dada aos passos necessários para se atingir tais resultados. Começaremos, assim,
por mostrar alguns conceitos necessários ao entendimento da pesquisa, seguiremos com uma
visão sobre o projeto experimental desenvolvido para esse estudo, apresentaremos os
resultados e, ao fim, serão apresentadas as conclusões as quais as pesquisadoras chegaram
pela avaliação feita sobre os dados.

10.1 Conceitos

- Pesquisa quase-experimental (quasi-experimental): Uma das primeiras dúvidas

que pode surgir quando da leitura do referido texto é sobre o significado da expressão “quase”
 14

quando tratamos ainda do título do mesmo. Pesquisas quase-experimentais são aquelas

utilizadas quando não é possível atribuir aleatoriamente um tratamento ou condição
experimental aos sujeitos. São caracterizadas por serem não muito intrusivas e não muito
dispendiosas, além de permitir que testes estatísticos (correlações, regressões, diferença entre
médias, análise de variância, etc.) possam ser utilizados nos dados delas obtidos.

- Clima da equipe (Team climate): É a percepção compartilhada sobre as práticas de

trabalho. Segundo as autoras, o clima parece ser um catalisador de outros fatores (como
interação, coesão, cooperação, comunicação, etc) que influenciam positivamente nos
resultados da equipe.
Este clima de equipe, para que pudesse ser mais corretamente avaliado, foi dividido
em alguns fatores (Team Climate Factors) com base em trabalhos anteriores sobre o assunto
(WEST, 1990 apud ACUÑA, GÓMEZ & JURISTO, 2008 e WEST & ANDERSON, 1996
apud ACUÑA, GÓMEZ & JURISTO, 2008). Assim, os quatro fatores identificados como
aqueles que propiciam um melhor clima de equipe são:
Participação assegurada (participative safety): seria a medida de quanta confiança os
membros da equipe tem para expor suas idéias;
Suporte à inovação (support for innovation): ou qual o suporte provido às idéias
inovadoras em uma equipe;
Visão de equipe (team vision): que vem a ser uma medida de quão claramente o time
define metas e objetivos; e
Orientação à tarefa (task orientation): medida de quanto esforço o time impõe para
alcançar a excelência nos objetivos.

- Qualidade de Software: Por qualidade de software as autoras trataram a obediência

parcial às regras estabelecidas no padrão SWEBOK 2004 (Software Engeneering Body of
Knowledge) – IEEE Computer Society Professional Pratices Committee. Assim como no caso
do clima da equipe, quando do tratamento da qualidade de software as autoras a dividiram em
determinados critérios. Os seis critérios utilizados no trabalho foram:
1. Decomposição e modularização: Nº de módulos utilizados;
2. Testabilidade: Nº de erros encontrados no conjunto de casos de teste de
execução automática;
3. Funcionalidade: Nº de requisitos satisfeitos;
4. Reusabilidade: Nº de módulos reutilizados;
5. Estilo de programação: Diretrizes definidas no website disponibilizado aos
participantes (www.iiuam.es/~sacuna/eda/practica.html#6); e
6. Participação: checklist of laboratory session observations.

- Projeto Experimental
Aqui serão mostrados os aspectos mais importantes sobre o projeto exerimental, i.e.,
aquilo que é relevante no planejamento de forma geral em pesquisas que utilizam métodos
empíricos. Ressalta-se que alguns itens serão suprimidos em troca de, principalmente, clareza
na explicação. Dessa maneira, é recomendável, para um total entendimento sobre o processo
utilizado pelas autoras, a leitura do próprio texto que aqui é exposto de forma mais sintética.
Tipo de pesquisa: Como o próprio título já expõe, fora escolhida a pesquisa quase-
experimental;
Objetivos: Analisar a relação entre as preferências e as percepções sobre o clima em
uma equipe; Analisar a relação entre o clima desejado-percebido e a qualidade no
desenvolvimento de um software utilizando-se uma variação de XP.
 15

Hipóteses nulas1: H01: O clima da equipe não tem relação com a qualidade do
software produzido.
H02: A diferença entre clima desejado-percebido não tem relação com a qualidade do
software produzido.
Obs.: Não serão mostradas aqui as hipóteses alternativas pelo motivo exposto logo no
início desta parte do trabalho.
Variáveis:
Independentes:
Clima de equipe;
Diferença entre clima desejado e percebido;
Dependente:
Qualidade de software;
Sujeitos: 105 estudantes do segundo ano do curso de Computação da Higher
Techinical School da Universidad Autónoma de Madrid;
Instrumentos:
TSI – Team Selection Inventory: para medir as preferências sobre o clima da equipe;
TCI – Team Climate Inventory: para medir as percepções sobre o clima da equipe;
Obs.: Como os instrumentos foram aplicados individualmente foi preciso utilizar a
média aritmética para agrupá-los num time. Isso ocorreu após a verificação de possibilidade
feita por análise de variância.
Algumas variáveis poderiam causar influência no quase-experimento (ameaças) e
foram devidamente tratadas pelas autoras de forma a, na medida do possível, terem seu efeito
anulado atribuindo-se a máxima constância às mesmas. As variáveis em questão, assim como
os tratamentos a elas dispensados são os seguintes:
A experiência dos participantes: esta é uma variável que poderia influenciar na
qualidade do software produzido. Este aspecto possui dois lados. O primeiro é a experiência
no projeto de softwares e o segundo a experiência no tipo de programação utilizado. Para este
possível problema, a seleção aleatória dos componentes foi entendida como suficiente para
dissolvê-la entre as diversas equipes.
O projeto a ser desenvolvidos (funcionalidades que os sujeitos devem implementar
durante o experimento): o sistema a ser desenvolvido poderia, por sua variação, impossibilitar
a comparação entre as diversas equipes, além de influenciar na qualidade do software
produzido. O efeito desta variável fora cancelado pelo fato de todos os times terem produzido
exatamente o mesmo projeto de software.
Conhecimento sobre o método para construção de software a ser utilizado: a
produtividade poderia ser influenciada pelo conhecimento prévio do método utilizado para a
construção do software, assim, para anular este possível efeito, as autoras buscaram equilibrar
o conhecimento sobre o método ao desenvolver um método (baseado no XP, mas não o
próprio) e também fazendo um curso de nivelamento sobre o assunto.

10.2 Métodos estatísticos utilizados

Correlações para checar se os questionários (TSI e TCI) eram inter-relacionados;

Análise Descritiva dos quatro fatores do clima de equipe;
Análise de variância para checar diferenças significantes entre cada uma das medidas
feitas;
Regressão entre as preferências, medidas na fase de pré-projeto, e as percepções sobre
o clima da equipe, medidas na fase de pós-projeto;
1
No trabalho as hipóteses nulas foram ainda divididas para cada um dos fatores que formam o clima da equipe,
conforme foram mostrados anteriormente. Por conseguinte, o mesmo ocorreu para as hipóteses alternativas.
 16

Análise da diferença entre médias entre as preferências e as percepções sobre o clima

da equipe

10. 3 Resultados e conclusões

Após os dados serem organizados, observados, avaliados e comparados, as autoras

chegaram ao seguinte resultado: participação assegurada e Visão de equipe possuem relação
com a qualidade do software produzido, principalmente para aqueles cujas expectativas com
relação a estas variáveis foram superadas pelo que encontraram na equipe e aqueles cuja
expectativa correspondeu aproximadamente ao encontrado.
É importante ressaltar que isso não significa que, caso sejam promovidos esses fatores,
se conseguirá softwares com maior qualidade, contudo, deve-se agir sobre estes fatores para
que a qualidade do software não seja diminuída pela diminuição dos mesmos.
É também relevante dizer que esse trabalho não se faz como definitivo, mas como um
trabalho que conduz as pesquisas na mesma área para um passo a mais na direção de algum
resultado mais preciso e isto também fica claro ao final do mesmo quando as autoras citam
inúmeros trabalhos que ficam assim como sugestão de trabalhos futuros que ainda devem ser
feitos. O que fica claro, apesar de tudo, é que sim, é possível medir variáveis que algumas
vezes parecem imensuráveis como poderia ser o caso do “clima em uma equipe” e, além
disso, tirar conclusões ou perceber relações que possam dar direção a trabalhos futuros onde,
somados a seus antecessores, tendem sempre melhorar o entendimento sobre os processos de
Engenharia de Software.

11. SÍNTESE

Com tudo isto aqui mencionado, pudemos verificar uma visão geral do estado atual
dos estudos empíricos e pontuamos os seus pontos fortes e fracos. E como sugestão, se faz
necessário o cuidado para se melhorar a pesquisa empírica, através de melhores projetos
empíricos, rigorosos e acreditáveis, para engenharia de software.
É preciso buscar modelar, no futuro, uma estrutura geral para softwares através dos
estudos empíricos. Como sugestões concretas, percebemos a necessidade de se: criar
melhores estudos, tendo cuidado na aquisição dos dados e envolvendo os outros nesses
estudos e práticas empíricas.
A formação dos nossos alunos também é fato imprescindível para a busca dessa
melhoria para um futuro não tão distante, onde a prática laboratorial se faz real.
Enquanto estamos ainda relativamente imaturos como uma disciplina empírica
comparada com outras ciências e disciplinas de engenharia, têm sido feitos progressos e
estamos otimistas de que podemos e alcançaremos o rigor necessário para o desenvolvimento
dos entendimentos profundos de engenharia de software.
 17

12. REFERÊNCIAS

ACUÑA, ST; GOMEZ, M; JURISTO, N. (2008). Towards understanding the relationship between team climate
and software quality - a quasi-experimental study. Empirical Software Engineering 13 (4): 401-434.
ALI-BABAR. M., ZHU, L., JEFFERY, R. (2004) A Framework for Classifying and Comparing Software Archi-
tecture Evaluation Methods. In: Proceedings of the 15th Australian Software Engineering Conference,
Melbourne, 13–16 April 2004
ALI BABAR, M., KITCHENHAM, B. A., JEFFERY, D. J. (2008). Comparing distributed and face-to-face
meetings for software architecture evaluation: A controlled experiment. Empirical Software Engineering 13(1):
39-62.
BASILI, V., Editorial. Empirical Software Engineering Journal, 1996. 1(2).
BASS, L., CLEMENTS, P., KAZMAN, R. (2003) Software architecture in practice. Addison-Wesley, Reading
BENGTSSON, P. (2002) Architecture-level modifiability analysis. Ph.D. Thesis, Blekinge Institute of Techno-
logy
CHAUÍ, M. Convite a Filosofia. São Paulo: Ática, 2003.
CLEMENTS, P., KAZMAN, R., KLEIN, M. (2002) Evaluating software architectures: methods and case studi-
es. Addison-Wesley, Reading
FENTON, N., S.L. PFLEEGER, and R. GLASS, Science and Substance: A Challenge to Software Engineers.
IEEE Software, 1994. 11(4): p. 86-95.
GLASSER, B. and STRAUSS, A. The discovery of grounded theory: Strategies for qualitative research. 1977,
Chicago: Aldine Publishing.
KAZMAN R, BASS L (2002) Making architecture reviews work in the real world. IEEE Softw 19(1):67–73
KNIGHT, J. and LEVESON, N. An Experimental Evaluation of the Assumption of Independence in Multi-
Version Programming. IEEE Transactions on Software Engineering, 1986. SE-12(1): p. 96-109.
MARANZANO, J. F., ROZSYPAL, S.A., ZIMMERMAN, G.H., WARNKEN, G.W., WIRTH, P.E., WEISS,
D.M. (2005) Architecture reviews: practice and experience. IEEE Softw 22(2):34–43
PERRY, Dewayne E., PORTER, Adam A., VOTTA, Lawrence G., Empirical Studies of Software Engineering:
A Roadmap. ICSE 2000
PIKKARAINEN, M. HAIKARA, J. SALO, O., ABRAHAMSSON, P. And STILL, J. (2008). The Impact of
Agile Practices on Communication in Software Development. Empirical Software Engineering. 13, 3, 303-337.