1. 2. Por que a evidência é importante no Engenharia de Software
1.1. Sistemas se tornaram parte do cotidiano
1.2. Benefícios sociais: Aplicação drive-by-wire para carros e dispositivos médicos vestíveis.
1.3. Prejuízos sociais: Desperdiço de dinheiro público e dados aos cidadãos(Comanda automatizada e sistema de controle para serviço de Ambulância de Londres).
1.4. Prática e processos para adoção de melhores soluções de software
1.5. EBSE ajudar na adoção tecnologias apropriadas e evitar tecnologias inapropriadas.
2. 3. O objetivo da EBSE
2.1. Um meio pelo qual os profissionais da indústria podem fazer decisões racionais sobre adoção de tecnologia.
2.2. Um meio para aumentar a aceitabilidade de software-sistemas intensivos que fazem interface com cidadãos
2.3. Um meio para melhorar a confiabilidade do sistemas intensivos de software, como resultado de uma melhor escolha de tecnologias de desenvolvimento.
3. 6. Discussão e conclusões
3.1. Engenharia de software baseado em evidências engenharia pode fornecer uma variedade de benefícios para o software praticantes e seus clientes e usuário
3.2. Existem também problemas científicos que podem ser mais difícil de abordar.
3.2.1. Avaliar tecnologias que dependem de habilidade humana
3.2.2. Experimentos sempre serão vulneráveis
3.2.3. Usar abordagem baseada em evidências para:
3.2.3.1. Visar a revisão sistemática
3.2.3.2. Avaliar melhor a viabilidade da abordagem baseada em evidência
4. 1.Introdução
4.1. Possibilidade de engenharia de software baseada em evidências usando uma analogia com a prática médica.
5. 4. Praticando o EBSE
5.1. Identificar medidas de resultados que sejam significativas para praticantes
5.2. Executar e reportar estudos de replicação.
5.3. 4.1 Definindo uma pergunta respondível
5.3.1. A tecnologia não deve ser especificada também alto nível de abstração.
5.3.2. É importante que a pergunta seja ampla o suficiente para permitir variação no fator do estudo e entre as populações.
5.3.3. Geral suficiente para identificar a maioria dos dados empíricos relevantes
5.3.4. Preciso para algumas perguntas, exemplo,especificações, programação em pares ou modelos de estimativa.
5.3.5. A população de interesse pode ser categorizado em muitas dimensões.
5.4. 4.2 Encontrando a melhor evidência
5.4.1. Dois estágios
5.4.1.1. Revisões sistemáticas já publicada
5.4.1.2. Estudos individuais relevantes.
5.4.2. Organizações que fornecem artigos: IEEEXplore e o ACM.
5.4.3. MBE apoia a melhoria tanto para revisões sistemáticas e estudos individuais. O que pode ser um contraste para Engenharia de Software onde as evidencias estão fragmentadas e limitadas, além de não está corretamente integrado.
5.5. 4.3 Avaliando criticamente as evidências
5.5.1. Sem padrões acordados
5.5.1.1. Na condução de um experimento em métodos formais a engenharia de software está muito carente de diretrizes e protocolos.
5.5.1.2. Vários tipos diferentes de estudo empírico, as orientações não são tão específicas,nem tão detalhada quanto a declaração CONSORT.
5.6. 4.4 Integrando a avaliação crítica comperícia em engenharia de software
5.6.1. Decisão de adotar uma tecnologia
5.6.1.1. Fatores como a cultura organizacional
5.6.1.2. Experiência e habilidade do software individual desenvolvedores
5.6.1.3. Requisitos dos clientes
5.6.1.4. Restrições do projeto
5.6.1.5. Extensão do treinamento necessário
5.6.2. EBSE funciona com o forte comprometimento na melhoria do processo, mas não é isso que está acontecendo.
5.6.2.1. Não em uso difundido na indústria
5.6.2.2. Não é de valor percebido para as partes interessadas
5.7. 4.5 Avaliação do processo
5.7.1. É difícil ter avaliação do processo
5.7.2. Setor competitivo, há pouco incentivo para as empresas individuais ajudar concorrentes relatando boas e más experiências com novas tecnologias
5.8. 4.6 Implicações para EBSE
5.8.1. Extensa colaboração e compromisso a longo prazo
6. 5. Fundações Científicas
6.1. 5.1 O fator de habilidade
6.1.1. 5.1.1 Protocolos experimentais
6.1.1.1. Alocação cega para grupos de tratamento
6.1.1.2. Distribuição cega de material
6.1.1.3. Marcação cega ou automatizada
6.1.1.4. Análise cega
6.1.1.5. Coleta de dados cegos
6.1.2. 5.1.2 Avaliando a qualidade do experimento.
6.1.2.1. A força da evidência
6.1.2.2. Tamanho do efeito
6.1.2.3. Relevância de evidência
6.2. 5.2 O problema do ciclo de vida
6.2.1. 5.2.1 Experimentando com técnicas individuais
6.2.1.1. Não resolve o problema que os resultados podem ser pobres substitutos para os profissionais de resultados do projeto são interessado
6.2.2. 5.2.2 Estudos empíricos de grande escala
6.2.2.1. Conjuntos de dados de projeto informações
6.2.2.1.1. Estabelecer benchmarks para qualidade ou produtividade
6.2.2.2. Definição da população é problemático para projetos de software
6.2.2.3. Obter uma amostra aleatória é problemático para projetos de software