Antes do conteúdo propriamente dito, é importante que fique claro o que será estudado, como o semestre está organizado e de que forma a aprendizagem será avaliada. Essa transparência não é burocracia: saber para onde se está indo é parte do processo de aprender — e, curiosamente, é também uma das primeiras lições da própria disciplina.

Ementa

Análise orientada a objetos. Introdução aos métodos ágeis. Principais práticas dos métodos ágeis: desenvolvimento dirigido por testes, programação pareada, refatoração e integração contínua. Exemplos de métodos ágeis: Programação Extrema (XP), Scrum e RUP. Prática em desenvolvimento de um sistema utilizando métodos e práticas ágeis.

Avaliação

A avaliação combina duas provas teóricas e um conjunto de trabalhos distribuídos ao longo de cada bimestre. As médias são calculadas assim:

Datas que importam

Comece por uma pergunta honesta: você já participou de algum trabalho de programação que atrasou, precisou ser refeito ou terminou diferente do que havia sido combinado? Se a resposta for sim, você já viveu o problema central desta disciplina — e ele quase nunca é um problema de linguagem de programação.

Um estudante que aprende a programar consegue, em pouco tempo, escrever um programa que funciona. O que não é evidente é o que acontece quando esse programa cresce, quando outras pessoas precisam mexer nele, quando o cliente muda de ideia no meio do caminho e quando existe um prazo real. Nessas condições, a habilidade individual de codificar deixa de ser suficiente. O que passa a determinar o resultado é a forma como o trabalho está organizado.

É por isso que a ementa desta disciplina não fala de sintaxe nem de framework. Ela fala de processo, de modelagem, de práticas de equipe. São esses os elementos que separam um programa que funciona na máquina de quem escreveu de um produto de software que funciona para outras pessoas, ao longo do tempo, e que pode ser mantido por quem não o escreveu.

Existe uma confusão comum entre programar e fazer engenharia de software. Programar é escrever instruções que o computador executa. Engenharia de software é a disciplina que trata de todo o ciclo de vida do produto: entender o problema, especificar o que deve ser construído, projetar uma solução, implementá-la, verificar se está correta e mantê-la em funcionamento enquanto ela for útil.

Repare no que as duas definições têm em comum: nenhuma delas menciona linguagem de programação. Ambas falam de abrangência (do início da especificação até depois da entrega) e de método (sistemático, disciplinado). A codificação está lá dentro, mas é uma parte entre várias.

O que a engenharia de software abrange

Vale separar os três termos, porque eles aparecem o semestre inteiro. Uma atividade é um objetivo amplo, aplicável a qualquer projeto (por exemplo, “comunicação”). Uma ação é um conjunto de trabalho que produz um artefato importante (por exemplo, “projeto de arquitetura”). Uma tarefa é uma unidade pequena e bem definida, com resultado concreto (por exemplo, “realizar teste de unidade do módulo de login”).

O que o processo produz são artefatos, também chamados de produtos de trabalho: programas, documentos, modelos e dados. Note que o código é apenas um dos artefatos — e frequentemente nem é o mais difícil de produzir.

Cinco perguntas para entender qualquer processo

Existem muitos processos de software diferentes, mas todos compartilham um núcleo comum. Dois autores de referência descrevem esse núcleo de formas ligeiramente distintas — e comparar as duas descrições é mais instrutivo do que decorar qualquer uma delas.

Sommerville: quatro atividades

Pressman: cinco atividades genéricas

Comparando os dois autores

Se as atividades são praticamente as mesmas em todos os processos, o que muda de uma metodologia para outra? Muda a ordem e a frequência com que essas atividades acontecem. A isso damos o nome de fluxo de processo.

Uma forma simples de explicar é comparar com cozinhar uma refeição. Os ingredientes podem ser os mesmos, mas o resultado muda se tudo for feito em sequência, se algumas etapas forem repetidas até acertar o ponto ou se duas pessoas trabalharem em paralelo. Em software acontece o mesmo: o conteúdo do trabalho não basta; a organização do trabalho muda o resultado.

Nenhum desses fluxos é intrinsecamente melhor. A escolha depende do quanto se conhece do problema, do quanto os requisitos tendem a mudar e do custo de errar. Essa é a discussão que ocupará as próximas quatro aulas.

As citações desta página foram mantidas em paráfrase, sem indicação de página. Ao estudar para a prova, use a edição indicada na bibliografia da disciplina — a numeração de páginas varia entre edições e entre a versão impressa e a da Minha Biblioteca.