Bloco 1 · O que é um projeto de software

Programar ≠ desenvolver software

Escrever código é uma das fases. Desenvolver um projeto de software é um processo com método:

• Perceber o problema e os requisitos.
• Desenhar a solução (algoritmos, dados, ecrãs) antes de codificar.
• Construir, testar e corrigir.
• Documentar e entregar.

Quem salta o desenho e vai logo ao código constrói o programa errado, mais depressa.

Contexto profissional

Onde se aplica esta competência (referencial):

• Empresas de informática e consultoria de TI.
• Lojas de informática e serviços de apoio técnico.
• Organismos da administração pública.

Ferramentas: IDE (ambiente de desenvolvimento), editor de texto, e apps de algoritmos/fluxogramas e prototipagem.

Bloco 2 · Pensamento computacional

Os 4 pilares

O pensamento computacional é a forma de resolver problemas que um programador usa — antes de qualquer linguagem:

1. Decomposição — partir um problema grande em partes pequenas.
2. Reconhecimento de padrões — ver o que se repete.
3. Abstração — ignorar o irrelevante, focar no essencial.
4. Algoritmo — a sequência de passos para resolver.

Estes princípios aplicam-se a qualquer linguagem e a qualquer problema.

Exemplo · calcular a média de uma turma

• Decomposição: ler notas → somar → dividir pelo número → mostrar.
• Padrão: "para cada nota, somar" repete-se.
• Abstração: não interessa o nome do aluno, só a nota.
• Algoritmo:
  1. soma = 0, contador = 0
  2. para cada nota: soma += nota; contador += 1
  3. média = soma / contador
  4. mostrar média

Bloco 3 · Ciclo de vida

Ciclo de vida do software (SDLC)

As fases por que passa qualquer projeto de software:

O erro custa mais quanto mais tarde se descobre — por isso analisa-se e desenha-se antes de codificar.

Fases de desenvolvimento de um programa

Dentro da construção, a sequência prática (referencial):

1. Identificação do problema.
2. Elaboração do algoritmo.
3. Codificação.
4. Debug (corrigir erros).
5. Testes de funcionamento.
6. Otimização algorítmica.

Vamos percorrer cada uma nos blocos seguintes.

Bloco 4 · Metodologias

Cascata vs Ágil

Hoje domina o ágil: entregar cedo, receber feedback, melhorar.

Scrum em 30 segundos

• Product backlog — lista priorizada do que fazer.
• Sprint — ciclo de 1–2 semanas com um objetivo.
• Daily — reunião curta diária (o que fiz / vou fazer / bloqueios).
• Review + Retrospetiva — mostrar o incremento e melhorar o processo.

Papéis: Product Owner (o quê), Scrum Master (facilita), Equipa (constrói).

Bloco 5 · Requisitos

Identificar o problema e os requisitos

Antes de tudo: o que tem o software de fazer?

• Requisitos funcionais — o que o sistema faz ("registar um cliente").
• Requisitos não-funcionais — como se comporta (rápido, seguro, acessível).
• Regras de negócio — restrições ("um NIF não se repete").

Técnicas: entrevistar o cliente, user stories ("Como gestor, quero listar as vendas do mês, para decidir").

Boas user stories

Formato: Como [perfil], quero [ação], para [valor].

• Como cliente, quero adicionar produtos ao carrinho, para os comprar.
• Como admin, quero exportar as vendas em CSV, para analisar no Excel.

Cada story deve ser pequena, clara e testável (critérios de aceitação).

Bloco 6 · Algoritmia

Algoritmo e pseudocódigo

Um algoritmo é uma sequência finita e ordenada de passos que resolve um problema. Escreve-se primeiro em pseudocódigo (português estruturado), independente da linguagem:

INÍCIO
  ler nota
  SE nota >= 10 ENTÃO
    escrever "Aprovado"
  SENÃO
    escrever "Reprovado"
  FIM SE
FIM

As 3 estruturas de controlo: sequência, decisão (SE), repetição (ENQUANTO/PARA).

Estruturas de controlo

# Decisão
SE saldo >= preco ENTÃO comprar SENÃO recusar

# Repetição (contada)
PARA i DE 1 ATÉ 10 FAZER escrever i

# Repetição (condicional)
ENQUANTO houver_stock FAZER vender

Dominar estas três estruturas é 90% da lógica de qualquer programa.

Bloco 7 · Fluxogramas

Fluxograma — a lógica em desenho

O fluxograma representa o algoritmo com símbolos:

Ferramentas: diagrams.net, Lucidchart, papel.

Exemplo de fluxograma

 (Início)
    │
 [ler idade]
    │
  < idade >= 18 ? > ──não──► [escrever "Menor"] ─┐
    │ sim                                        │
 [escrever "Maior"]                              │
    │                                            │
    └───────────────► (Fim) ◄────────────────────┘

Desenhar antes de codificar evita erros de lógica.

Bloco 8 · Dados e ecrãs

Modelação de dados

Definir que dados o programa guarda e como se organizam:

• Entidades (Cliente, Produto, Venda) e atributos (nome, preço).
• Relações (uma venda tem um cliente).
• Estruturas em código: variáveis, listas, dicionários, objetos.

produto = {"nome": "Café", "preco": 3.5, "stock": 20}
carrinho = [produto, ...]

Modelar os dados cedo torna o código simples e coerente.

Wireframing e protótipo

Antes de programar o interface, desenha-se:

• Wireframe — esboço de cada ecrã (screen): onde ficam menus, botões, listas — sem cores.
• Protótipo — wireframes ligados, para simular a navegação e o tipo de conteúdos e ligações.

Ferramentas: Figma, diagrams.net, papel. Valida-se a ideia antes de escrever código.

Bloco 9 · Codificação

Ambiente de desenvolvimento

• IDE (Ambiente Integrado de Desenvolvimento) — ex.: VS Code, PyCharm. Editor + execução + debug num só sítio.
• Instalar a linguagem (ex.: Python) e configurar o interpretador.
• Controlo de versões com Git: guardar histórico, voltar atrás, trabalhar em equipa.

git init
git add .
git commit -m "primeira versão"

Sintaxe e semântica

• Sintaxe — as regras de escrita da linguagem (dois pontos, indentação). Erro de sintaxe → não corre.
• Semântica — o significado: o código corre, mas faz o que querias?

def media(notas):
    return sum(notas) / len(notas)   # sintaxe ok e semântica ok

print(media([12, 15, 9]))   # 12.0

Código legível: nomes claros, funções curtas, comentários onde ajudam.

Bloco 10 · Testes

Debug — caçar erros

Debug = encontrar e corrigir defeitos. Tipos de erro:

• Sintaxe — o programa nem arranca.
• Execução (runtime) — rebenta a meio (ex.: dividir por zero).
• Lógica — corre, mas dá o resultado errado (o pior).

Técnicas: ler a mensagem de erro, print() para inspecionar, breakpoints no debugger do IDE, isolar o problema.

Testes de funcionamento

Verificar que o programa faz o esperado, com casos:

• Caso normal — dados típicos (média de [10, 14, 16]).
• Casos-limite — vazio, zero, máximo, negativos.
• Casos inválidos — texto onde se espera número.

assert media([10, 20]) == 15
assert media([5]) == 5

Corrigir os erros encontrados e voltar a testar (regressão).

Otimização e documentação

• Otimização algorítmica — depois de funcionar, torná-lo mais rápido/simples (evitar repetições, escolher a estrutura certa). Primeiro correto, depois rápido.
• Documentação técnica — README (o que é, como instalar, como usar), comentários no código, manual do utilizador. Software sem documentação não se mantém.