Método empírico em Engenharia de software

Método empírico em Engenharia de software

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

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

Gelter Thadeu Maia Rodrigues

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.

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 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.

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 (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 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 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 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?

  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 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, 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

Informal

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

Formal

Reuniões em grupos (semanalmente, e.g.), reuniões de avaliação de milestones e apresentação de 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:

  • 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.

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” 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.

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 Descritivados 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;

Análise da diferençaentre 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.

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 Architecture 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 Technology

CHAUÍ, M. Convite a Filosofia. São Paulo: Ática, 2003.

CLEMENTS, P., KAZMAN, R., KLEIN, M. (2002) Evaluating software architectures: methods and case studies. 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.

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.

Comentários