# Engenharia de Software/Introdução

Engenharia de software não é programação. Ou, pelo menos, não é simplesmente programação.
À medida em que este livro se desenvolver, é provável que ele se desmembre em vários livros, como um livro para Engenharia de Requisitos, um para testes de software, um para UML, e etc. Mas por enquanto todo este conteúdo está centralizado aqui.
No caso de linguagens de programação, já existem livros maduros sobre determinadas linguagens. Linguagens de programação não devem ser ensinadas neste livro.

## Processos de desenvolvimento de software

Um processo de software é o conjunto de atividades que levam ao desenvolvimento de um produto de software.

## Engenharia de requisitos

A Engenharia de Requisitos tem como função descobrir o que o cliente realmente quer do software.

## Testes de software

O objetivo dos testes de software não é provar que o sistema está errado. O objetivo dos testes é achar erros no sistema. Um bom teste é aquele que em algum momento, presente ou futuro, vai expor um erro do software.
Outro objetivo dos testes de software é a validação de requisitos.

### Testes unitários

Testes Unitários são realizados nas menores unidades de código testáveis. Em geral são considerados uma tarefa do programador.

### Testes de regressão

Seres humanos se cansam rapidamente de tarefas repetitivas. Então testes de regressão devem preferencialmente ser feitos com scripts automatizados

### Desenvolvimento guiado a testes

É uma técnica conhecida do XP (Extremme programming), na qual, antes de fazer o código, você faz o teste que vai testar o código. Depois, com o teste pronto, se desenvolve o código que vai simplesmente passar no teste.
Essa técnica é útil pois o fato de criar o teste antes de iniciar a codificação ajuda a entender melhor o problema. Com um caso de teste definido a programação fica mais objetiva e diminui-se o retrabalho.

## Gerência de configuração e mudanças

Gerência de Configuração e Gerência de Mudanças são duas disciplinas muito interligadas, por isto vamos estudá-las juntas.
A Gerência de Configuração pode ter significados diferentes dependendo da área. Por exemplo, no ITIL, a gerência de configuração cuida não só do código fonte, mas também de hardware, softwares de prateleira e etc. No contexto de Engenharia de Software, A gerência de configuração cuida basicamente dos arquivos do projeto. Normalmente tais arquivos são chamados de itens de configuração.
É normal fazer a gerência de configuração com o apoio de uma ferramenta. A ferramenta tem como funcionalidades básicas:
* Armazenar todas as versões pelas quais cada item de configuração passou ao longo da vida
* Registrar e exibir mensagens de commit referentes a cada versão de cada Item de configuração
* Auxiliar no processo de ramificação e posterior mesclagem
A gerência de mudanças cria um processo para acompanhar o ciclo de vida de uma mudança, desde o nascimento, quando a mudança é proposta, até a morte, que pode ocorrer de várias formas.
Uma utilidade da gerência de mudanças é guardar de forma centralizada, tanto propostas de mudanças em aberto, quanto propostas de mudanças postergadas (para que não caiam no esquecimento) quanto mudanças já realizadas, guardando inclusive, neste último caso, o registro de como a mudança foi realizada, que dificuldades foram encontradas, etc.
Depois de alguns meses alimentando um banco de dados de gerência de mudanças, começa a ser interessante extrair relatórios do banco de dados com métricas sobre o processo de atendimento a solicitações de mudanças. Exemplos de dados que podem ser extraídos:
* Ranking dos sistemas por número de erros
* Número de solicitações não atendidas por sistema
* Tempo médio para fechamento de bugs críticos