Pular para conteúdo

Bem-vindo ao Curso de Engenharia de Software para Iniciantes

Aprenda os fundamentos da Engenharia de Software, do zero ao profissional, com uma abordagem prática e estruturada!

🎯 Sobre o Curso

Este curso foi desenvolvido para te introduzir ao mundo da Engenharia de Software. Você aprenderá conceitos essenciais, metodologias ágeis, modelagem, arquitetura e muito mais.

O que você vai aprender: - Ciclo de Vida de Desenvolvimento de Software (SDLC) - Metodologias Ágeis (Scrum, Kanban) - Requisitos e User Stories - Modelagem UML e Arquitetura - Versionamento com Git e GitHub - Testes, DevOps e Qualidade de Software

🚀 Comece Agora

  • Aulas

    16 aulas completas organizadas em 6 módulos, do básico ao avançado.

    Ver todas as aulas

  • Slides

    Slides interativos com RevealJS para todas as aulas do curso.

    Acessar slides

  • Exercícios

    Pratique com exercícios para cada aula e fixe o conteúdo.

    Ver exercícios

  • Quizzes

    Teste seus conhecimentos com quizzes interativos.

    Fazer quizzes

  • Projetos

    Desenvolva projetos práticos para aplicar o que aprendeu.

    Ver projetos

  • Configuração

    Guias de instalação e configuração do ambiente de desenvolvimento.

    Configurar ambiente

📚 Estrutura do Curso

  1. Fundamentos e Processos (Aulas 01-03)
  2. Requisitos e Modelagem (Aulas 04-05)
  3. Arquitetura e Design (Aulas 06-08)
  4. Qualidade e Testes (Aulas 09-10)
  5. DevOps e Segurança (Aulas 11-12)
  6. Gestão e Evolução (Aulas 13-16)

🎓 Como Usar Este Curso

  1. Configure seu ambiente - Siga os guias de configuração
  2. Comece pela Aula 01 - Vá para Aulas e comece do início
  3. Pratique regularmente - Faça os exercícios e projetos de cada aula
  4. Teste seus conhecimentos - Complete os quizzes para validar seu aprendizado
  5. Revise com os slides - Use os slides para revisão rápida

Pronto para começar? Ir para Aula 01

Sobre o Curso

🎓 Engenharia de Software para Iniciantes

Este curso foi desenhado para estudantes de Análise e Desenvolvimento de Sistemas (ADS), Ciência da Computação e iniciantes na área de tecnologia que desejam entender além do código.

🚀 Objetivo

Transformar programadores em Engenheiros de Software. Enquanto cursos de programação ensinam como escrever código, este curso ensina como construir sistemas robustos, escaláveis e de qualidade.

📚 Metodologia

O curso segue uma abordagem Hands-on (Mão na Massa), mas aplicada a conceitos teóricos. Em vez de apenas ler sobre Scrum ou Requisitos, você simulará um projeto real (um To-Do App) e aplicará cada conceito aula a aula.

🛠 Ferramentas Utilizadas

  • Git & GitHub: Para versionamento e colaboração.
  • UML: Para modelagem visual.
  • Kanban/Trello: Para gestão de tarefas.
  • VS Code: Como ambiente de desenvolvimento.
  • MkDocs: Plataforma onde este curso está hospedado.

👤 Público Alvo

  • Estudantes de graduação em TI.
  • Desenvolvedores Júnior que querem evoluir na carreira.
  • Curiosos que querem entender como grandes softwares são construídos.

Pronto para começar sua jornada na Engenharia de Software?

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado por módulos.

📚 Módulos do Curso

Módulo 1 – Fundamentos e Processos

Aula 01 – Fundamentos da Engenharia de Software

🎯 Objetivos de Aprendizagem

  • Compreender o que é Engenharia de Software e sua importância.
  • Diferenciar "programação" (coding) de "engenharia de software".
  • Conhecer o Ciclo de Vida de Desenvolvimento de Software (SDLC).
  • Entender as fases fundamentais da construção de um software.

📚 Conteúdo

1. O que é Engenharia de Software?

Conceito Chave

Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software.

Diferente de apenas escrever código (programação), a engenharia se preocupa com o ciclo completo e o impacto a longo prazo:

  • Qualidade: O software funciona como esperado? É seguro?
  • Prazo e Custo: O projeto será entregue no tempo e orçamento previstos?
  • Manutenibilidade: O código pode ser entendido e alterado por outras pessoas no futuro?

[!TIP] Engenharia de Software é como a aviação: existem protocolos para garantir que nada caia por uma falha boba.

📊 Métrica de Exemplo (Estimativa de Esforço):

No modelo COCOMO básico, o esforço \(E\) em pessoas-mês é calculado como: $$ E = a \cdot (KLOC)^b $$ Onde \(KLOC\) é a quantidade de linhas de código em milhares.

2. A Crise do Software

Historicamente, muitos projetos de software falhavam (estouravam prazos, orçamentos ou não funcionavam). Isso levou à Crise do Software, que impulsionou a criação de métodos para organizar o trabalho.

Atenção

Não subestime a complexidade. Software é invisível, o que torna erros difíceis de detectar sem um processo sólido.

3. O Ciclo de Vida de Desenvolvimento de Software (SDLC)

O SDLC (Software Development Life Cycle) é a estrutura que define as etapas envolvidas na criação de um software.

graph TD
    A["Levantamento de Requisitos"] --> B["Análise e Design"]
    B --> C["Implementação"]
    C --> D["Testes"]
    D --> E["Implantação"]
    E --> F["Manutenção"]
    F --> A

Dica Didática

Pense no SDLC como uma receita de bolo: você não começa a assar sem antes comprar os ingredientes (requisitos) e pré-aquecer o forno (preparação).

4. Exemplos Práticos (TermynalJS)

$ git init projeto-software
$ echo "planejamento" > requisitos.txt
$ # Simulação de ciclo de vida
$ ls -R

📝 Exercícios Progressivos

  1. [Básico] Defina com suas palavras a diferença entre um programador e um engenheiro de software.
  2. [Básico] Cite as 6 fases principais do SDLC.
  3. [Intermediário] Por que a fase de manutenção é frequentemente a mais cara de todo o ciclo?
  4. [Intermediário] Explique o que foi a "Crise do Software".
  5. [Desafio] Pesquise sobre o modelo COCOMO e explique por que estimar o tamanho do software em linhas de código (KLOC) pode ser problemático.

🚀 Mini-Projeto 01: O Primeiro Roadmap

Crie um documento simples listando os Requisitos para um sistema de "Gestão de Biblioteca". O que um usuário (estudante) e um administrador (bibliotecário) precisariam fazer no sistema?

📅 Atividades

Aula 02 – Processos de Software: Cascata e Ágil

🎯 Objetivos de Aprendizagem

  • Entender a evolução dos modelos de processo de software.
  • Conhecer o modelo Cascata (Waterfall) e suas limitações.
  • Introduzir o conceito de Desenvolvimento Ágil.
  • Comparar abordagens tradicionais vs. ágeis.

📚 Conteúdo

1. O Modelo Cascata (Waterfall)

O modelo tradicional e sequencial. Nele, cada fase do ciclo de vida deve ser finalizada antes da próxima começar.

Definição

O Cascata é um modelo linear onde as etapas fluem para baixo, como uma queda d'água.

  • Fluxo: Requisitos Design Código Testes Deploy.
  • Vantagem: Fácil de gerenciar e entender o progresso.
  • Problema: Rígido. Mudar requisitos no meio do projeto é extremamente caro.

2. O Modelo V (V-Model)

Uma evolução do Cascata que coloca o foco na Verificação e Validação.

graph TD
    A["Requisitos"] --- B["Testes de Aceitação"]
    C["Arquitetura"] --- D["Testes de Sistema"]
    E["Design Detalhado"] --- F["Testes de Integração"]
    G["Codificação"] --- H["Testes Unitários"]

    A --> C --> E --> G --> H --> F --> D --> B

Atenção

No Modelo V, para cada fase de construção, existe um plano de teste correspondente desde o início.

3. O Manifesto Ágil

Devido à frustração com projetos lentos e burocráticos, surgiu o movimento Ágil.

Os 4 Pilares

  1. Pessoas e Interações > Processos e Ferramentas.
  2. Software Funcional > Documentação Extensa.
  3. Colaboração com o Cliente > Negociação de Contratos.
  4. Responder a mudanças > Seguir um plano fixo.

4. Demonstração de Agilidade (TermynalJS)

$ # Ciclo Ágil: Feedback Rápido
$ npm start --dev
$ # Alteração detectada... Reloading!
$ # Teste automatizado concluído: 100% OK
$ git commit -m "feat: entrega incremental da sprint 1"

📝 Exercícios Progressivos

  1. [Básico] Por que o modelo Cascata é chamado de "sequencial"?
  2. [Básico] Liste os 4 valores principais do Manifesto Ágil.
  3. [Intermediário] Qual a principal diferença entre o Modelo Cascata e o Modelo V?
  4. [Intermediário] Em qual cenário o Modelo Cascata ainda pode ser útil hoje em dia?
  5. [Desafio] Como a "Lei de Murphy" se aplica a projetos que utilizam apenas o modelo Cascata?

🚀 Mini-Projeto 02: O Comparativo

Crie uma tabela comparando "Construir uma Ponte" com "Construir um Aplicativo de Entregas". Qual desses projetos combina melhor com Cascata e qual combina melhor com Agile? Justifique.

📅 Atividades

Aula 03 – Metodologias Ágeis: Scrum e Kanban

🎯 Objetivos de Aprendizagem

  • Aprofundar o conhecimento em metodologias Ágeis.
  • Entender o framework Scrum (Papéis, Artefatos, Eventos).
  • Entender o método Kanban (Visualização e fluxo).
  • Diferenciar Scrum de Kanban.

📚 Conteúdo

1. Scrum: O Time em Campo

Scrum é o framework ágil mais utilizado no mundo. Ele transforma o trabalho em ciclos iterativos.

O que é uma Sprint?

A Sprint é o coração do Scrum. É um período de tempo fixo (geralmente de 1 a 4 semanas) onde um incremento de software "Pronto" é criado.

📊 Papéis e Fluxo

graph LR
    PO["Product Owner"] --> B[Backlog]
    B --> S[Sprint Planning]
    S --> T[Time de Dev]
    T --> D(Daily Scrum)
    D --> T
    T --> R[Review/Retro]
    R --> I["Incremento (Software Pronto)"]

Artefatos

  1. Product Backlog: Lista de desejos do cliente.
  2. Sprint Backlog: O que faremos agora.
  3. Incremento: O resultado final da Sprint.

2. Kanban: Visualizando o Fluxo

Diferente do Scrum, o Kanban não tem ciclos fixos; ele foca no fluxo contínuo.

O Quadro Kanban

A regra de ouro do Kanban é Limitar o Trabalho em Progresso (WIP). Não comece novas tarefas antes de terminar as atuais!

  • To-Do: Pendente.
  • Doing: Em desenvolvimento.
  • Done: Entregue.

3. Simulação de Trabalho Ágil (TermynalJS)

$ # Status da Sprint
$ scrum status
$ # Tarefas no Scrum Backlog: 12
$ # Tarefas Concluídas: 5
$ # Movendo tarefa de 'Doing' para 'Done'
$ kanban move task-102 --to done

Importante

Scrum é focado em tempo (concluir a Sprint), enquanto Kanban é focado em fluxo (entregar tarefas continuamente).

📝 Exercícios Progressivos

  1. [Básico] O que é uma "Sprint" no Scrum?
  2. [Básico] No Kanban, o que significa a sigla WIP (Work In Progress)?
  3. [Intermediário] Qual o papel do Scrum Master e em que ele difere de um "Chefe"?
  4. [Intermediário] Explique a diferença entre a Sprint Review e a Sprint Retrospective.
  5. [Desafio] Um time está sofrendo com muitas interrupções externas durante a Sprint. Qual metodologia você recomendaria para ajudar a visualizar esse problema e por quê?

🚀 Mini-Projeto 03: O Quadro Kanban

Utilize uma ferramenta (ou papel) para montar um Quadro Kanban para a organização dos seus estudos. Crie pelo menos 5 tarefas e defina um limite de WIP para a coluna "Fazendo".

📅 Atividades

Módulo 2 – Requisitos e Modelagem

Aula 04 – Requisitos de Software

🎯 Objetivos de Aprendizagem

  • Entender o que são Requisitos de Software.
  • Diferenciar Requisitos Funcionais de Não-Funcionais.
  • Aprender a escrever Histórias de Usuário (User Stories).
  • Compreender a importância do documento de requisitos.

📚 Conteúdo

1. O que são Requisitos?

Requisitos são as necessidades e condições que o software deve atender. É a tradução do que o cliente "quer" para o que o time "vai construir".

Fator de Sucesso

Ter requisitos claros e validados é o passo mais importante para evitar o desperdício de tempo e dinheiro no desenvolvimento.

2. Tipos de Requisitos

A) Requisitos Funcionais (RF)

Descrevem o que o sistema FAZ. São as funcionalidades que o usuário vê e usa.

Exemplos de RF

  • "O sistema deve enviar um e-mail de confirmação após o cadastro."
  • "O sistema deve permitir a exclusão de itens do carrinho."

B) Requisitos Não-Funcionais (RNF)

Descrevem COMO o sistema deve se comportar. São restrições técnicas e de qualidade.

Exemplos de RNF

  • Performance: "O login deve ser processado em menos de 1 segundo."
  • Segurança: "Todas as senhas devem ser salvas com hash SHA-256."
  • Disponibilidade: "O sistema deve estar online 99.9% do tempo."

3. User Stories (Histórias de Usuário)

No desenvolvimento ágil, simplificamos os requisitos usando o formato:

Como um <tipo de usuário>, eu quero <ação>, para que <benefício>.

$ # Exemplo de User Story
$ # Como um: Estudante
$ # Eu quero: Marcar aulas como concluídas
$ # Para que: Eu possa acompanhar meu progresso no curso

📝 Exercícios Progressivos

  1. [Básico] Qual a principal diferença entre um RF e um RNF?
  2. [Básico] Escreva uma User Story para a funcionalidade de "Resetar Senha" de um app.
  3. [Intermediário] Classifique os itens abaixo como RF ou RNF:
    • ( ) "O app deve abrir em menos de 3 segundos."
    • ( ) "O usuário deve poder filtrar produtos por preço."
  4. [Intermediário] O que são "Critérios de Aceite" em uma User Story?
  5. [Desafio] Imagine um sistema de votação online. Liste 2 Requisitos Não-Funcionais CRÍTICOS para esse sistema e justifique sua escolha.

🚀 Mini-Projeto 04: Levantamento Inicial

Escolha um aplicativo que você usa muito (ex: Instagram, WhatsApp). Liste 3 Requisitos Funcionais e 2 Não-Funcionais que você percebe nele. Tente escrever um desses RFs no formato de User Story.

📅 Atividades

Aula 05 – Modelagem de Sistemas e UML

🎯 Objetivos de Aprendizagem

  • Entender o que é Modelagem de Software.
  • Conhecer a UML (Unified Modeling Language).
  • Aprender a ler Diagramas de Caso de Uso e de Classes.

📚 Conteúdo

1. Por que modelar?

Assim como arquitetos desenham plantas antes de construir, engenheiros de software criam modelos para visualizar a solução antes da codificação.

Comunicação Visual

Diagramas ajudam a alinhar o entendimento entre o cliente (entidade de negócios) e o desenvolvedor (entidade técnica).

2. O que é UML?

A UML (Linguagem de Modelagem Unificada) é o padrão visual para documentar a arquitetura e o comportamento de sistemas orientados a objetos.

3. Diagrama de Caso de Uso

Foca no "O que" o sistema faz e "Quem" interage com ele.

Elementos Básicos

  • Atores: Bonecos palito representam usuários ou sistemas externos.
  • Casos de Uso: Elipses representam as funcionalidades.
$ # Fluxo de Caso de Uso: Comprar Produto
$ # 1. Ator seleciona item
$ # 2. Sistema valida estoque
$ # 3. Sistema processa pagamento

4. Diagrama de Classes

Mostra a estrutura estática do sistema (os dados e comportamentos).

classDiagram
    class Pessoa {
        +String nome
        +int idade
        +andar()
    }
    class Aluno {
        +int matricula
        +estudar()
    }
    Pessoa <|-- Aluno

Sintaxe Mermaid

Note que usamos +String nome em vez de +nome: String para garantir compatibilidade máxima com diferentes renderizadores.

📝 Exercícios Progressivos

  1. [Básico] O que significa a sigla UML?
  2. [Básico] Qual a diferença entre um "Ator" e um "Usuário" em UML?
  3. [Intermediário] No diagrama de classes, o que representa o símbolo + antes de um atributo?
  4. [Intermediário] Desenhe (em papel) um pequeno Diagrama de Caso de Uso para um "Sistema de Caixa Eletrônico" (Saque, Consulta de Saldo).
  5. [Desafio] No exemplo de Mermaid acima, o que significa a seta <|--? (Pesquise sobre Herança se necessário).

🚀 Mini-Projeto 05: Modelando o Mundo Real

Crie um Diagrama de Classes simples para um "Sistema de E-commerce". Defina as classes Produto, Cliente e Pedido. Liste pelo menos 2 atributos e 1 método para cada uma.

📅 Atividades

Módulo 3 – Arquitetura e Design

Aula 06 – Arquitetura de Software

🎯 Objetivos de Aprendizagem

  • Entender o conceito de Arquitetura de Software.
  • Conhecer padrões arquiteturais comuns (Monólito, Microserviços).
  • Entender a separação Frontend vs. Backend.

📚 Conteúdo

1. O que é Arquitetura?

Se a modelagem (Aula 05) é a planta baixa da casa, a Arquitetura é a estrutura e engenharia por trás. Define a organização fundamental do sistema e as decisões difíceis de mudar.

Decisão Estratégica

Arquitetura de software é o conjunto de decisões técnicas significativas sobre a estrutura de um sistema e seus componentes.

2. Monólito vs. Microserviços

A) Monólito (Tudo em um só lugar)

O sistema inteiro é construído como uma única unidade.

Vantagens

  • Mais simples de desenvolver inicialmente.
  • Testes e deploys mais diretos.
  • Ideal para times pequenos.

B) Microserviços (Dividir para conquistar)

O sistema é composto por pequenos serviços independentes que se comunicam via rede (APIs).

Atenção

Embora escalável, microserviços introduzem uma complexidade enorme de rede e gerenciamento (ex: Docker, Kubernetes).

3. Padrão Multicamadas (Layered)

A forma mais clássica de organizar o código internamente:

  1. Apresentação (UI): Interface com o usuário.
  2. Negócio (BLL): Onde as regras "mandam".
  3. Dados (DAL): Acesso ao banco de dados.
graph TD
    A["Frontend (UI)"] -- "API Call" --> B["Backend (Lógica)"]
    B -- "Query" --> C["Banco de Dados"]

4. Simulação de Arquitetura (TermynalJS)

$ # Verificando serviços ativos (Microserviços)
$ docker ps
$ # Service-Catalog: UP (Port 8081)
$ # Service-Checkout: UP (Port 8082)
$ # Service-Payment:  DOWN (Port 8083)
$ # Alerta: Checkout não funcionará sem o Payment!

📝 Exercícios Progressivos

  1. [Básico] O que é Arquitetura de Software?
  2. [Básico] Diferencie Frontend de Backend.
  3. [Intermediário] Cite uma vantagem e uma desvantagem de usar Microserviços.
  4. [Intermediário] Por que dizemos que decisões arquiteturais são "caras"?
  5. [Desafio] Uma startup quer lançar um MVP (Produto Mínimo Viável) em 2 meses com um time de 3 pessoas. Você recomendaria Monólito ou Microserviços? Justifique.

🚀 Mini-Projeto 06: Planejando a Estrutura

Desenhe (ou descreva) quais seriam as "camadas" de um sistema de Login. O que aconteceria na camada de Interface, na camada de Lógica e na camada de Banco de Dados?

📅 Atividades

Aula 07 – Versionamento de Código (Git & GitHub)

🎯 Objetivos de Aprendizagem

  • Entender para que serve o Versionamento de Código.
  • Conhecer o Git (ferramenta) e o GitHub (plataforma).
  • Aprender os comandos básicos: init, add, commit, push.
  • Entender o conceito de Branches (Ramos).

📚 Conteúdo

1. O Problema das Versões

Sem versionamento, os arquivos ficam desorganizados e é impossível saber quem mudou o quê. No desenvolvimento de software, precisamos de uma Máquina do Tempo.

Por que usar Git?

O Git resolve o problema do "final_final_v2.zip". Ele permite salvar estados do código e alternar entre eles com segurança.

2. Git vs. GitHub

Não confunda a ferramenta com o serviço!

  • Git: O motor. É um software que você instala no seu computador para controlar as versões localmente.
  • GitHub: O estacionamento. É uma plataforma na nuvem onde você guarda seus projetos e colabora com outros desenvolvedores.

3. O Fluxo de Trabalho (Ciclo de Vida)

graph LR
    A["Workspace (Edição)"] -- "git add" --> B["Staging (Seleção)"]
    B -- "git commit" --> C["Local Repo (Foto)"]
    C -- "git push" --> D["GitHub (Nuvem)"]

Dica de Ouro

Pense no git add como colocar as compras no carrinho e no git commit como passar no caixa e finalizar a compra.

4. Praticando no Terminal (TermynalJS)

$ # Iniciando um novo projeto
$ git init
$ git add .
$ git commit -m "feat: estrutura inicial do curso"
$ # Conectando ao GitHub e enviando
$ git remote add origin https://github.com/usuario/projeto.git
$ git push origin main

Atenção

Sempre escreva mensagens de commit claras (ex: "fix: corrige erro no login") para que seus colegas entendam o que você fez.

📝 Exercícios Progressivos

  1. [Básico] Qual a diferença entre Git e GitHub?
  2. [Básico] Para que serve o comando git add?
  3. [Intermediário] O que acontece quando executamos um git commit?
  4. [Intermediário] Explique o conceito de "Branch" (Ramo) e por que ele é importante para trabalhar em equipe.
  5. [Desafio] Você descobriu um erro grave no código que foi enviado ontem. Como o Git pode te ajudar a voltar para a versão de anteontem? (Pesquise sobre git checkout ou git revert).

🚀 Mini-Projeto 07: Meu Primeiro Repo

Crie um repositório no seu GitHub chamado estudos-eng-software. Faça o commit de um arquivo README.md explicando o que você está aprendendo nesta aula e envie-o para a nuvem.

📅 Atividades

Aula 08 – Design de Software e SOLID

🎯 Objetivos de Aprendizagem

  • Entender os princípios de um bom design de software.
  • Compreender os conceitos de Acoplamento e Coesão.
  • Introduzir o princípio KISS e DRY.
  • Conhecer os Princípios SOLID (visão geral).

📚 Conteúdo

1. Design de Software

Design não é apenas sobre cores e botões; em engenharia, é sobre a organização interna do código. Um bom design torna o software fácil de mudar e difícil de quebrar.

O Código Espaguete

Sem design, o código se torna um amontoado confuso de funções dependentes. O objetivo do design é manter a ordem.

2. Conceitos Fundamentais

A) Coesão (O foco)

Cada parte do sistema deve fazer apenas uma coisa e fazê-la muito bem.

Alta Coesão

Imagine uma caixa de ferramentas. Cada ferramenta tem uma função única. Você não usa um martelo para parafusar.

B) Acoplamento (A dependência)

O quanto uma parte do sistema depende de outra. Queremos que as partes sejam independentes.

Baixo Acoplamento

Se você mudar o formato do banco de dados e precisar mexer em 50 arquivos diferentes, seu acoplamento está alto.

3. Princípios Práticos

  • KISS (Keep It Simple, Stupid): Mantenha as coisas simples. Se há duas formas de resolver, escolha a mais óbvia.
  • DRY (Don't Repeat Yourself): Não se repita. Se você copiou e colou código, você falhou no design.

4. SOLID (Os 5 Pilares)

graph TD
    S["Single Responsibility"]
    O["Open/Closed"]
    L["Liskov Substitution"]
    I["Interface Segregation"]
    D["Dependency Inversion"]
$ # Analisando qualidade do design (Simulação)
$ analyze-design --file Pedido.js
$ # Alerta: Classe 'Pedido' faz muitas coisas! (Baixa Coesão)
$ # Sugestão: Separe a lógica de 'Cálculo de Desconto' em outra classe.

📝 Exercícios Progressivos

  1. [Básico] O que é "Coesão" em design de software?
  2. [Básico] O que significa a sigla DRY?
  3. [Intermediário] Por que um alto acoplamento é prejudicial para a manutenção?
  4. [Intermediário] Explique o princípio KISS com um exemplo do mundo real.
  5. [Desafio] Escolha DOIS princípios do SOLID e tente explicar a importância deles para um sistema que precisa crescer muito.

🚀 Mini-Projeto 08: Refatorando o Caos

Abaixo está um pseudo-código: função ProcessarPedido(id) { ValidarEstoque(); CobrarCartao(); EnviarEmailConfirmacao(); GerarNotaFiscal(); } Como você separaria essa função seguindo o princípio de Responsabilidade Única (SRP)?

📅 Atividades

Módulo 4 – Qualidade e Testes

Aula 09 – Qualidade de Software e QA

🎯 Objetivos de Aprendizagem

  • Entender o conceito de Qualidade de Software.
  • Diferenciar Error, Fault (Defeito) e Failure (Falha).
  • Conhecer o papel de QA (Quality Assurance).
  • Entender o custo de corrigir bugs tardiamente.

📚 Conteúdo

1. O que é Qualidade?

Um software tem qualidade quando ele atende aos requisitos (faz o que deve fazer) e atende às expectativas do usuário (é rápido, seguro e intuitivo).

Foco no Valor

Não adianta ter um código tecnicamente perfeito se ele não resolve o problema do usuário ou se é impossível de usar.

2. A anatomia de um problema

Na engenharia, somos precisos com os termos para identificar a origem dos problemas:

  1. Erro (Mistake): É o equívoco humano (ex: o dev esqueceu de validar um campo).
  2. Defeito (Fault/Bug): É a "marquinha" deixada no código pelo erro.
  3. Falha (Failure): É o comportamento visível (ex: o app fechou sozinho).

Causa e Efeito

Humano erra Código ganha um Defeito Usuário percebe a Falha.

3. A Regra 1-10-100

Quanto mais tarde você descobre um problema, mais caro ele custa.

  • $1 na fase de Requisitos: Basta apagar uma linha de texto.
  • $10 na fase de Desenvolvimento: Precisa reescrever código.
  • $100 em Produção: Custa reputação, suporte técnico e correções de emergência.

4. Simulação de Qualidade (TermynalJS)

$ # Rodando análise de bugs (Linting)
$ npm run lint
$ # Erro encontrado: Variável 'total' não definida. (Aula 09)
$ # Defeito corrigido. Qualidade aumentada em 5%!
$ # Rodando testes de regressão... Passou!

📝 Exercícios Progressivos

  1. [Básico] O que é Qualidade de Software para você?
  2. [Básico] Diferencie Erro de Falha.
  3. [Intermediário] Por que a fase de manutenção costuma ser a mais cara se não houver qualidade inicial?
  4. [Intermediário] Explique a regra 1-10-100 com suas próprias palavras.
  5. [Desafio] Você é o QA de um novo app de banco. Onde você focaria seus esforços para economizar mais dinheiro para a empresa? (Pense na regra 1-10-100).

🚀 Mini-Projeto 09: Plano de Prevenção

Imagine que você está criando um app de delivery. Liste 3 possíveis falhas que os usuários poderiam encontrar e sugira como evitá-las ainda na fase de design.

📅 Atividades

Aula 10 – Testes de Software

🎯 Objetivos de Aprendizagem

  • Entender a importância dos testes automatizados.
  • Conhecer a Pirâmide de Testes.
  • Diferenciar Testes Unitários de Integração e E2E.
  • Introduzir o conceito de TDD (Test Driven Development).

📚 Conteúdo

1. Por que testar automaticamente?

Testar manualmente (clicar no botão todas as vezes que muda o código) é lento e propenso a erros. Testes automatizados são robôs que verificam seu código em milissegundos.

Confiança para Mudar

Ter uma boa base de testes permite que você altere o código sem medo de quebrar algo que já funcionava (regressão).

2. A Pirâmide de Testes

Sugere o equilíbrio ideal entre velocidade e cobertura dos testes:

graph TD
    A["E2E (Interface) - Poucos"] --> B["Integração - Alguns"]
    B --> C["Unitários - Muitos"]

    style C fill:#f9f,stroke:#333,stroke-width:4px

O Segredo da Pirâmide

A base (Unitários) deve ser grande porque são testes rápidos e baratos. O topo (E2E) deve ser pequeno porque são testes lentos e difíceis de manter.

3. Tipos de Teste

A) Teste Unitário

Testa a menor parte do código isoladamente (uma função). - Ex: "A função calcularTotal(10, 5) retorna 15?"

B) Teste de Integração

Testa se duas ou mais peças funcionam bem juntas. - Ex: "A lógica do app consegue ler os dados do Banco de Dados?"

C) Teste End-to-End (E2E)

Testa o fluxo completo do usuário no navegador ou app.

4. TDD: Teste Primeiro, Código Depois

O TDD (Desenvolvimento Orientado a Testes) segue um ciclo repetitivo:

  1. RED: Escreva um teste que falha (o código ainda não existe).
  2. GREEN: Escreva o código mínimo para o teste passar.
  3. REFACTOR: Melhore o código garantindo que o teste continue passando.
$ # Executando testes unitários
$ npm test
$ # PASS  tests/math.test.js
$ # PASS  tests/auth.test.js
$ # Testes: 12 passed, 12 total
$ # Tempo: 0.5s

📝 Exercícios Progressivos

  1. [Básico] O que são testes automatizados?
  2. [Básico] Desenhe a Pirâmide de Testes e nomeie suas faces.
  3. [Intermediário] Qual a principal diferença entre um teste Unitário e um de Integração?
  4. [Intermediário] Explique as três fases do ciclo TDD (Red, Green, Refactor).
  5. [Desafio] Por que não devemos ter apenas testes de Interface (E2E) em um projeto grande?

🚀 Mini-Projeto 10: O Roteiro de Teste

Para uma funcionalidade de "Saque no Caixa Eletrônico", liste 3 testes unitários que você criaria (pense em valores válidos, valores negativos e saldo insuficiente).

📅 Atividades

Módulo 5 – DevOps e Segurança

Aula 11 – DevOps e CI/CD

🎯 Objetivos de Aprendizagem

  • Entender o que é DevOps (Cultura).
  • Compreender Integração Contínua (CI).
  • Compreender Entrega Contínua (CD).
  • Conhecer o conceito de Pipeline de Automação.

📚 Conteúdo

1. O fim do "No meu PC funciona"

Antigamente, desenvolvedores criavam o software e o "jogavam por cima do muro" para o time de Operações (infraestrutura) instalar. Isso gerava muitos conflitos.

Cultura DevOps

DevOps não é uma ferramenta ou um cargo, é a união de Development (Desenvolvimento) e Operations (Operações). O objetivo é colaborar para entregar software rápido e com segurança.

2. CI/CD: A Esteira de Automação

Imagine uma fábrica de carros automatizada. Isso é o que chamamos de CI/CD em software.

CI (Continuous Integration)

Toda mudança é enviada para um repositório central e testada automaticamente.

Vantagem da CI

Descobrimos erros minutos após eles serem escritos, e não meses depois.

CD (Continuous Delivery / Deployment)

O código aprovado nos testes é preparado automaticamente para ir ao ar.

  • Delivery: O deploy é um passo manual (clicar em um botão).
  • Deployment: O deploy é 100% automático para os usuários.

3. O Pipeline (A jornada do código)

graph LR
    A["Push (Git)"] --> B["Build"]
    B --> C["Test (Check)"]
    C --> D["Deploy (Nuvem)"]

    style C fill:#ccffcc,stroke:#333

Stop the Line

Se o passo de Test falhar, o Pipeline para imediatamente e o código não vai para o ar. Qualidade em primeiro lugar!

4. Simulação de Pipeline (TermynalJS)

$ git push origin main
$ # Iniciando Workflow CI...
$ # [STEP 1] Build: SUCCESS
$ # [STEP 2] Unit Tests: SUCCESS
$ # [STEP 3] Security Scan: SUCCESS
$ # [STEP 4] Deploying to Production...
$ # Done! Versão 1.2.0 está no ar. 🚀

📝 Exercícios Progressivos

  1. [Básico] O que significa a sigla DevOps?
  2. [Básico] Qual a diferença entre Integração Contínua (CI) e Entrega Contínua (CD)?
  3. [Intermediário] Por que dizemos que DevOps é uma "cultura" e não apenas um software?
  4. [Intermediário] Descreva os passos comuns de um Pipeline de automação.
  5. [Desafio] Como a automação de testes (Aula 10) ajuda na implementação de uma cultura DevOps?

🚀 Mini-Projeto 11: Desenhando a Esteira

Imagine que você é o líder técnico de um novo banco digital. Desenhe ou descreva quais seriam os passos obrigatórios do seu Pipeline de Deploy para garantir que nenhum bug de segurança chegue aos clientes.

📅 Atividades

Aula 12 – Segurança de Software

🎯 Objetivos de Aprendizagem

  • Entender o conceito de Security by Design.
  • Conhecer a Tríade CIA (Confidencialidade, Integridade e Disponibilidade).
  • Diferenciar Autenticação de Autorização.
  • Conhecer os principais riscos da OWASP (Injeção).

📚 Conteúdo

1. Security by Design

Muitos sistemas falham porque a segurança é pensada apenas no final. A engenharia moderna exige que a segurança faça parte do design inicial.

Mentalidade de Segurança

Segurança não é um produto que você compra, é um processo que você constrói desde a primeira linha de código.

2. A Tríade CIA (Confidencialidade, Integridade e Disponibilidade)

Os 3 pilares fundamentais da segurança da informação:

  1. Confidencialidade: Garante que o dado só seja visto por quem tem permissão.
  2. Integridade: Garante que a informação não seja alterada indevidamente.
  3. Disponibilidade: Garante que o sistema esteja acessível quando o usuário precisar.

Dica Didática

C (Segredo) I (Verdade) A (Acesso).

3. Autenticação vs. Autorização

Termos que parecem iguais, mas têm papéis diferentes:

  • Autenticação: "Quem é você?" (Login, Senha, Biometria).
  • Autorização: "O que você pode fazer?" (O usuário pode ler, mas só o admin pode apagar).

4. Simulação de Segurança (TermynalJS)

$ # Rodando Scanner de Vulnerabilidades
$ security-audit ./projeto
$ # [ALERT] Vulnerabilidade encontrada no campo de Busca!
$ # Risco: SQL Injection (Injeção de Código)
$ # Sugestão: Use consultas parametrizadas.

📝 Exercícios Progressivos

  1. [Básico] O que significa a sigla CIA em segurança?
  2. [Básico] Qual a diferença entre Autenticação e Autorização?
  3. [Intermediário] Explique o conceito de "Security by Design".
  4. [Intermediário] O que é um ataque de Injeção (SQL Injection)?
  5. [Desafio] Imagine que um site de notícias sofreu um ataque e todas as notícias foram apagadas. Qual pilar da tríade CIA foi mais afetado? Justifique.

🚀 Mini-Projeto 12: O Checkup de Segurança

Escolha um aplicativo bancário ou de e-commerce que você usa. Liste quais métodos de Autenticação (ex: senha, biometria, Token) ele utiliza para garantir a Confidencialidade dos seus dados.

📅 Atividades

Módulo 6 – Gestão e Evolução

Aula 13 – Gerenciamento de Projetos e Estimativas

🎯 Objetivos de Aprendizagem

  • Entender o Triângulo de Ferro (Escopo, Tempo, Custo).
  • Aprender o conceito de MVP (Minimum Viable Product).
  • Conhecer técnicas de estimativa Ágil.
  • Saber priorizar tarefas usando o método MoSCoW.

📚 Conteúdo

1. O Triângulo de Ferro

Em qualquer projeto de engenharia, você lida com três restrições interligadas. Se você mexer em uma, as outras serão afetadas.

  1. Escopo: O que será feito.
  2. Tempo: Qual o prazo.
  3. Custo: Quanto dinheiro e recursos temos.

Equilíbrio Delicado

Se você quer aumentar o Escopo (fazer mais coisas) sem aumentar o Tempo (prazo), o Custo (esforço/equipe) obrigatoriamente terá que subir.

2. MVP (Mínimo Produto Viável)

O MVP não é um produto mal acabado, mas sim a versão mais simples que resolve o problema central do usuário.

Ideia Chave

Se você quer construir um carro, não comece fabricando uma roda. Comece com um skate (MVP), depois um patinete, até chegar ao carro. Assim você entrega valor desde o dia 1.

3. Priorização com MoSCoW

Como decidir o que entra no MVP?

  • Must Have: Obrigatório (O sistema não funciona sem isso).
  • Should Have: Importante (Mas o sistema sobrevive sem).
  • Could Have: Desejável (Um "luxo" se sobrar tempo).
  • Won't Have: Não terá agora (Fica para a versão 2.0).

4. Estimativas no Terminal (TermynalJS)

$ # Rodando sessão de Planning Poker
$ planning-poker start --task "Criar Login"
$ # Dev 1: 3 pontos
$ # Dev 2: 5 pontos
$ # Dev 3: 13 pontos (Divergel!)
$ # Alinhamento: "Ah, esqueci da validação de 2 etapas!" -> Média: 8 pontos.

📝 Exercícios Progressivos

  1. [Básico] Quais são as 3 pontas do Triângulo de Ferro?
  2. [Básico] O que significa a sigla MVP?
  3. [Intermediário] Explique a diferença entre uma tarefa "Must Have" e uma "Should Have".
  4. [Intermediário] Por que usamos pontos (Story Points) em vez de horas para estimar tarefas no Ágil?
  5. [Desafio] Um cliente pede para adicionar uma funcionalidade complexa (Escopo) sem mudar a data de entrega (Tempo). Usando o Triângulo de Ferro, quais são suas opções como engenheiro?

🚀 Mini-Projeto 13: Meu Planejamento MoSCoW

Imagine que você vai criar um app de "Lista de Compras". Liste 2 itens para cada categoria do MoSCoW. O que é "Must Have" para o app ser útil?

📅 Atividades

Aula 14 – Documentação Técnica

🎯 Objetivos de Aprendizagem

  • Entender por que documentar é essencial (e não perda de tempo).
  • Conhecer os tipos de documentação (Técnica vs. Usuário).
  • Aprender a escrever um bom README.
  • Conhecer o poder do Markdown.

📚 Conteúdo

1. "O código se documenta sozinho"? (Spoiler: Não!)

Um código limpo ajuda muito, mas ele não explica o PORQUÊ das decisões, nem como instalar e rodar o projeto.

Amor ao Próximo

Documentação é um ato de respeito com os outros desenvolvedores (e com o seu "eu" do futuro). Ninguém gosta de herdar um projeto sem manual.

2. Tipos de Documentação

A) Documentação de Usuário

Focada em quem vai usar o software. - Guia de Início Rápido: Como começar? - FAQ: Dúvidas comuns.

B) Documentação Técnica

Focada em quem vai manter o software. - README: O cartão de visitas do projeto. - Documentação de API: Como outros sistemas se conectam ao seu (ex: Swagger). - Diagramas: Arquitetura visual (Aula 05 e 06).

3. O Poder do Markdown

Markdown é uma linguagem simples de marcação que se tornou o padrão para documentar software.

Dica de Escrita

Use # para títulos, **negrito** para destaque e `código` para comandos. É leve e renderiza em qualquer lugar (GitHub, MkDocs, etc.).

4. Criando um README no Terminal (TermynalJS)

$ touch README.md
$ echo "# Nome do Meu Projeto" >> README.md
$ echo "## Como instalar" >> README.md
$ echo "npm install" >> README.md
$ cat README.md
$ # Resultado: Arquivo README criado com sucesso!

📝 Exercícios Progressivos

  1. [Básico] Qual a principal função de um arquivo README?
  2. [Básico] Cite um exemplo de documentação para usuário.
  3. [Intermediário] Por que comentar o código deve ser feito "com moderação"? (O que devemos comentar de verdade?).
  4. [Intermediário] O que significa "Autodocumentação" em código limpo?
  5. [Desafio] Você entrou em um projeto legado sem nenhuma documentação. Quais seriam os 3 primeiros passos que você daria para tentar entender o sistema?

🚀 Mini-Projeto 14: Documentando meu Trabalho

Crie um arquivo chamado ABOUT_ME.md usando sintaxe Markdown. Escreva uma breve biografia, liste 3 habilidades técnicas suas em uma lista e adicione uma frase em negrito sobre seu objetivo no curso.

📅 Atividades

Aula 15 – Manutenção e Evolução

🎯 Objetivos de Aprendizagem

  • Entender que o software nunca está "pronto".
  • Conhecer a diferença entre Manutenção Corretiva, Preventiva e Evolutiva.
  • Entender o conceito de Refatoração.
  • Analisar o conceito de Dívida Técnica (Technical Debt).

📚 Conteúdo

1. O Software não é uma estátua

Diferente de um monumento de pedra, o software é vivo. Se o mundo ao redor muda (novos celulares, novas leis, novos navegadores), o software precisa mudar junto.

Lei da Evolução (Lehman)

Um software que é usado em um ambiente real deve sofrer mudanças contínuas ou tornar-se progressivamente menos útil.

2. Tipos de Manutenção

  • Corretiva: Consertar erros/bugs (o famoso "apagar incêndio").
  • Adaptativa: Mudar o sistema para funcionar em um novo ambiente (ex: migrar para a nuvem).
  • Evolutiva (Perfeccionista): Adicionar novas funcionalidades desejadas pelos usuários.
  • Preventiva: Melhorar o código para evitar que ele quebre no futuro.

3. Refatoração e Dívida Técnica

Refatorar é como limpar a cozinha enquanto você cozinha. Você não muda o sabor da comida (o comportamento), mas deixa o ambiente organizado (a estrutura).

Cuidado com a Dívida

Dívida Técnica ocorre quando escolhemos uma solução rápida em vez de uma solução correta. "Pagamos juros" cada vez que mexer nesse código fica mais difícil e lento.

4. Simulação de Refatoração (TermynalJS)

$ # Analisando complexidade do código
$ code-metrics ./src
$ # Resultado: Alerta de Complexidade Ciclomática Alta!
$ # Aplicando Refatoração: Extrair Método...
$ # Novo resultado: Código 40% mais legível. Dívida reduzida!

📝 Exercícios Progressivos

  1. [Básico] O que é manutenção Corretiva?
  2. [Básico] O que significa "Refatorar" um código?
  3. [Intermediário] Explique com uma metáfora o que é Dívida Técnica.
  4. [Intermediário] Qual a diferença entre manutenção Evolutiva e Preventiva?
  5. [Desafio] Qual o perigo de nunca refatorar um sistema que cresce constantemente?

🚀 Mini-Projeto 15: O Plano de Evolução

Escolha um aplicativo que você usa e que mudou recentemente (ex: Instagram, WhatsApp). Identifique uma mudança que foi Corretiva (bug que sumiu) e uma que foi Evolutiva (nova função).

📅 Atividades

Aula 16 – Carreira e Ética na Engenharia de Software

🎯 Objetivos de Aprendizagem

  • Refletir sobre a responsabilidade ética do Engenheiro de Software.
  • Conhecer as Soft Skills essenciais para o mercado atual.
  • Discutir o futuro da área e o impacto da Inteligência Artificial.

📚 Conteúdo

1. Ética: O Código de Conduta

O software hoje decide desde quem recebe um empréstimo até o trajeto de um carro autônomo. Pequenas falhas ou preconceitos no código podem ter impactos gigantescos na vida das pessoas.

Responsabilidade Profissional

A ética na engenharia de software envolve privacidade (LGPD), acessibilidade e a garantia de que o seu trabalho não será usado para prejudicar ou discriminar ninguém.

2. O Profissional "T-Shaped"

No mercado moderno, não basta saber apenas uma tecnologia. Buscamos o equilíbrio entre profundidade e amplitude.

  • Barra Vertical: Especialização (ex: ser um mestre em React ou Java).
  • Barra Horizontal: Conhecimentos gerais (entender de UX, DevOps, Negócios e Testes).

Dica de Carreira

Seja profundo o suficiente para resolver problemas difíceis, mas amplo o suficiente para colaborar com qualquer time.

3. Soft Skills (Habilidades Comportamentais)

Programar é a parte fácil; lidar com pessoas é o desafio. Senioridade se mede por: 1. Comunicação: Traduzir o "tecniquês" para o cliente. 2. Empatia: Se colocar no lugar do usuário final. 3. Resiliência: Lidar com prazos e bugs inesperados sem desespero.

4. O Futuro com IA (TermynalJS)

$ # Simulando o amanhã
$ ai-assistant suggest-architecture --project "Smart-City"
$ # Sugestão: Use Microserviços baseados em Green-Energy.
$ # Reflexão: A IA é o seu copiloto, mas você ainda é o piloto!
$ echo "Engenharia de Software é sobre resolver problemas, não só digitar código."

📝 Exercícios Progressivos

  1. [Básico] O que é ética na engenharia de software?
  2. [Básico] O que define um profissional "T-Shaped"?
  3. [Intermediário] Liste 3 Soft Skills importantes e justifique por que um desenvolvedor precisa delas.
  4. [Intermediário] Como a LGPD (Lei Geral de Proteção de Dados) afeta o trabalho do engenheiro?
  5. [Desafio] Qual o papel do engenheiro de software em um mundo onde a IA pode escrever código básico sozinha?

🚀 Mini-Projeto 16: Meu Roadmap Profissional

Desenhe seu próprio "T". Na barra vertical, coloque a tecnologia que você mais gosta. Na barra horizontal, coloque 3 áreas que você quer aprender mais (ex: Segurança, Design, Nuvem).

📅 Atividades

Materiais

Materiais

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos.

  • Slides

    • Acesse os slides de todas as aulas para revisão.

  • Exercícios

    • Pratique com listas de exercícios para cada módulo.

  • Quizzes

    • Teste seus conhecimentos com quizzes interativos.

  • Projetos

    • Desenvolva projetos práticos para aplicar o que aprendeu.

  • Setup

    • Guias de instalação e configuração do ambiente.

Slides

Slides das Aulas

Aqui você encontra os slides de apresentação de cada aula.

Como Usar

  • Os slides usam RevealJS para apresentação interativa
  • Clique nos links acima para visualizar em tela cheia
  • Use as setas do teclado para navegar entre os slides
  • Pressione F para tela cheia e S para modo apresentador

Exercícios

Exercícios

Bem-vindo à seção de exercícios! Aqui você encontra atividades práticas para fixar os conceitos vistos em aula.

Dicas

  • Tente resolver os exercícios consultando o material da aula.
  • Discuta suas respostas com colegas ou mentores.
  • Foque na aplicação prática dos conceitos.

Exercício 01

  1. Identificação de Fases: Pense em um aplicativo que você usa (ex: Instagram). Liste uma atividade que provavelmente ocorreu na fase de Design e uma na fase de Testes desse app.
  2. Cenário de Erro: Se um erro grave é descoberto apenas na fase de Implantação, qual fase anterior provavelmente falhou em detectá-lo? Por que corrigir agora é mais caro?
  3. Debate: Por que não devemos pular direto para a fase de Codificação sem fazer Requisitos ou Design?

Exercício 02

  1. Estudo de Caso: Imagine que você está construindo um software para controlar o lançamento de um foguete espacial. Qual modelo seria mais seguro: Cascata (com requisitos fixos e rigorosos) ou Ágil (onde "bugs" podem ser corrigidos depois)? Justifique.
  2. Comparação: Faça uma tabela simples comparando "Frequência de Entrega" no Cascata vs. Ágil.
  3. Reflexão: Por que o modelo Ágil se tornou tão popular em startups, onde o modelo de negócio muda o tempo todo?

Exercício 03

  1. Simulação de Daily: Reúna 3 amigos (ou imagine). Cada um deve responder: 1) O que fiz ontem? 2) O que farei hoje? 3) Tenho algum impedimento?
  2. Quadro Kanban: Pegue post-its (ou papel picado) e monte um quadro "To Do", "Doing", "Done" na sua parede para suas tarefas pessoais da semana.
  3. Papéis: Se você fosse criar o "To-Do App" com amigos, quem seria o PO? Quem seria o Scrum Master? Por que?

Exercício 04

  1. Classificação: Classifique os itens abaixo em RF (Funcional) ou RNF (Não-Funcional):

    • "O site deve ter fundo azul."
    • "O usuário pode recuperar sua senha via e-mail."
    • "O sistema deve rodar 24/7 sem cair."
    • "O sistema deve calcular juros compostos."

  2. Escrita de User Story: O To-Do App precisa de um "Modo Noturno". Escreva isso como uma User Story seguindo o modelo.

  3. Critérios de Aceite: Defina 3 critérios para a funcionalidade "Excluir Tarefa". (Ex: O sistema deve pedir confirmação? O que acontece com a tarefa depois de excluída?)

Exercício 05

  1. Observação: Olhe para o seu celular. Se o "Celular" fosse uma Classe, cite 3 atributos (o que ele tem) e 3 métodos (o que ele faz).
  2. Caso de Uso: Desenhe (no papel) um diagrama de Caso de Uso simples para um "Caixa Eletrônico". Atores: Cliente e Técnico. Casos de uso: Sacar Dinheiro, Depositar, Repor Dinheiro.
  3. Leitura: Se você ver uma seta conectando a classe Cachorro à classe Animal, o que isso provavelmente significa? (Dica: Herança).

Exercício 06

  1. Análise de App: Pense no Uber. O App no seu celular é o Cliente ou o Servidor? Onde ficam guardados os dados dos motoristas?
  2. Desenho: Desenhe três caixas empilhadas representando as camadas: Apresentação (Topo), Lógica (Meio) e Dados (Base). Onde você colocaria o código que verifica se a senha do usuário tem 8 dígitos?
  3. Reflexão: Por que a Netflix usa Microserviços? (Dica: Imagine milhões de pessoas assistindo coisas diferentes ao mesmo tempo. Se o módulo de "Legendas" falhar, o filme deve parar?).

Exercício 07

  1. Analogia: Explique para uma criança o que é git commit usando a metáfora de um videogame (Save Point).
  2. Cenário: Você apagou sem querer uma parte importante do código hoje de manhã. Se você estiver usando Git, como ele pode te salvar?
  3. Fluxo: Desenhe setas conectando:
    • Meu PC -> Área de Preparação -> Histórico Local -> GitHub
    • (Associe aos comandos: add, commit, push).

Exercício 08

  1. Refatoração (Teórica): Você encontrou uma função de 500 linhas chamada GerenciarUsuario que cadastra, envia e-mail de boas-vindas, valida CPF e gera relatório. Usando o princípio da Coesão, como você dividiria essa função?
  2. Identificando DRY: Se você escreveu a lógica de calcular desconto de 10% em 5 lugares diferentes do código, o que acontece se o desconto mudar para 15%? Como o princípio DRY resolveria isso?
  3. Monstro de Espaguete: Pesquise o termo "Spaghetti Code" e escreva uma frase sobre como evitá-lo.

Exercício 09

  1. Classificação: O programador esqueceu de converter uma data (Erro). O código ficou salvando o ano como 1900 (Defeito). O cliente viu sua idade como 123 anos (Falha). Identifique cada um no seu próprio exemplo.
  2. Debate: Por que corrigir um bug em produção custa 100x mais? (Pense em: parar o time, fazer patch, reputação da marca, dados corrompidos).
  3. QA vs Teste: Se você revisa o documento de requisitos para ver se falta algo, você está fazendo QA ou Teste de Código?

Exercício 10

  1. Escrevendo Testes (Papel): Imagine uma função ehMaiorDeIdade(idade). Escreva 3 casos de teste para ela.
    • Ex: Entrada 10 -> Esperado: Falso.
    • Ex: Entrada 18 -> Esperado: ???
    • Ex: Entrada 25 -> Esperado: ???
  2. Classificação: Um teste que verifica se, ao clicar no botão "Login", o usuário é redirecionado para a "Home", é Unitário ou E2E?
  3. Reflexão TDD: Por que escrever o teste antes ajuda a desenhar melhor o código? (Pense em como você é "obrigado" a pensar na entrada e saída da função).

Exercício 11

  1. Desenho: Desenhe uma esteira de fábrica. Em vez de montar carros, coloque as etapas de software: Checkout (Baixar código) -> Testar -> Construir -> Publicar.
  2. Cenário: Sem CI, João subiu um código que quebrou o sistema na sexta-feira e foi embora. Com CI, o que teria acontecido assim que ele desse git push?
  3. Pesquisa: O que são "GitHub Actions"? (Dica: É uma ferramenta de CI/CD gratuita).

Exercício 12

  1. Cenário de Ataque: Você criou um site onde o usuário digita o ID do pedido na URL (site.com/pedido?id=10) para ver os detalhes. O que acontece se o usuário mudar o 10 para 11? Se ele ver o pedido de outra pessoa, qual pilar da segurança foi quebrado? (Confidencialidade).
  2. Engenharia Social: Por que o "fator humano" é frequentemente o elo mais fraco da segurança? (Pesquise sobre Phishing).
  3. Senha Fraca: Por que sites obrigam você a usar letras maiúsculas, números e símbolos na senha? Isso ajuda contra qual tipo de ataque? (Força Bruta).

Exercício 13

  1. MoSCoW na Prática: Você está organizando uma festa de aniversário. Classifique os itens: Bolo, Palhaço, Convidados, Bexigas, DJ Famoso.
  2. MVP: Você quer criar um concorrente para o Uber. Qual seria o MVP? (Dica: Precisa de um App para passageiro e outro para Motorista? Ou dá para começar com um grupo de WhatsApp e uma planilha?).
  3. Triângulo: Seu chefe pede "Quero o dobro de funcionalidades para semana que vem, sem contratar ninguém". Qual lado do triângulo você deve mexer para explicar que isso é impossível?

Exercício 14

  1. Refatorando README: Você encontrou um projeto no GitHub que tem um README escrito apenas: "Projeto TCC Final". Como você melhoraria isso? Escreva 3 tópicos que faltam.
  2. Markdown na Veia: Escreva seu nome em Negrito, Itálico e como Código usando a sintaxe Markdown.
  3. Comentários: O comentário abaixo é bom ou ruim? Por que? 
    // Incrementa i em 1
i = i + 1;

Exercício 15

  1. Metáfora: Explique Dívida Técnica comparando com não lavar a louça do jantar por uma semana. O que acontece quando você precisa cozinhar de novo?
  2. Identificando Oportunidade: Você abre um código e vê a mesma função de 20 linhas copiada em 3 arquivos diferentes. Que tipo de manutenção você deve fazer? (Preventiva/Refatoração).
  3. Decisão: Seu chefe quer lançar o produto AMANHÃ, mas o código está feio. Você assume a dívida técnica? Se sim, o que você deve negociar para depois do lançamento?

Exercício 16

  1. Dilema Ético: Seu chefe pede para você criar um algoritmo que mostre vagas de emprego de alto salário apenas para homens. O que você faz? (Isso viola princípios éticos e legais).
  2. Autoavaliação: Desenhe um "T". Na barra vertical, coloque o que você mais gostou/quer aprofundar (ex: Backend, Frontend, Testes). Na horizontal, o que você precisa conhecer o básico.
  3. Portfólio: Reúna todos os documentos do "Projeto To-Do App" que fizemos. Isso já é um início de portfólio mostrando que você sabe documentar e pensar o software.

Quizzes

Quizzes Interativos

Teste seus conhecimentos com quizzes rápidos ao final de cada tópico!

🎯 Como Usar

  • Responda as perguntas para validar seu entendimento.
  • Verifique o Gabarito ao final para explicações detalhadas.
  • Use como revisão antes de avançar para o próximo módulo.

Quiz 01 - Introdução

1. Qual é o principal objetivo da Engenharia de Software?
Escrever código o mais rápido possível, sem se preocupar com erros.
Aplicar uma abordagem sistemática e disciplinada para o desenvolvimento de software.
Criar apenas jogos de computador.
Consertar computadores quebrados (hardware).
2. O que significa a sigla SDLC?
Software Design Leveled Code
System Development Linear Code
Software Development Life Cycle (Ciclo de Vida de Desenvolvimento de Software)
Super Dynamic Life Cycle
3. Em qual fase do SDLC definimos "O QUE" será construído?
Testes
Implementação
Levantamento de Requisitos
Manutenção
4. O que ocorre na fase de "Manutenção"?
O software é deletado.
O software é planejado do zero.
Correções e melhorias são feitas após o software estar em uso.
Os desenvolvedores tiram férias.
5. Qual a diferença principal entre Programação e Engenharia de Software?
Programação é apenas escrever código; Engenharia envolve todo o ciclo de vida e gestão.
Não há diferença, são sinônimos.
Engenharia de Software é apenas para hardware.
Programação é mais difícil que Engenharia.
Gabarito:
  • 1- Aplicar uma abordagem sistemática e disciplinada para o desenvolvimento de software.
  • 2- Software Development Life Cycle (Ciclo de Vida de Desenvolvimento de Software)
  • 3- Levantamento de Requisitos
  • 4- Correções e melhorias são feitas após o software estar em uso.
  • 5- Programação é apenas escrever código; Engenharia envolve todo o ciclo de vida e gestão.

Quiz 02 - Introdução

1. Qual a principal característica do Modelo Cascata?
Permite mudanças a qualquer momento sem custo.
As fases são sequenciais; uma termina para a outra começar.
Não existe planejamento.
O cliente vê o software todo dia.
2. O que o Manifesto Ágil valoriza MAIS?
Processos e Ferramentas.
Documentação Abrangente.
Software em Funcionamento.
Negociação de Contratos.
3. No modelo Ágil, como é a entrega do software?
Única, apenas no final do projeto.
Incremental e frequente (em partes).
Apenas quando o cliente paga tudo.
Aleatória.
4. Por que o Cascata é comparado à construção civil?
Porque engenheiros de software usam capacetes.
Porque é difícil mudar a estrutura depois de pronta (rigidez).
Porque usa cimento.
Porque é barato.
5. Qual destes NÃO é um valor do Manifesto Ágil?
Responder a mudanças.
Colaboração com o cliente.
Seguir um plano rigorosamente acima de tudo.
Indivíduos e interações.
Gabarito:
  • 1- As fases são sequenciais; uma termina para a outra começar.
  • 2- Software em Funcionamento.
  • 3- Incremental e frequente (em partes).
  • 4- Porque é difícil mudar a estrutura depois de pronta (rigidez).
  • 5- Seguir um plano rigorosamente acima de tudo.

Quiz 03 - Introdução

1. Quem é o responsável por decidir O QUE será feito no produto (Product Backlog)?
Scrum Master
Time de Desenvolvimento
Product Owner (PO)
Gerente de RH
2. O que é uma Sprint?
Uma corrida de 100 metros.
Um ciclo de tempo fixo (ex: 2 semanas) onde o trabalho é executado.
Uma reunião diária.
Um tipo de documento.
3. Qual o objetivo da reunião Daily Scrum?
Alinhar o time sobre o progresso e impedimentos (15 min).
Reclamar do chefe.
Fazer o planejamento do ano todo.
Apresentar o software para o cliente.
4. O que significa "Kanban"?
Código rápido.
Placa visual ou cartão.
Reunião longa.
Gerente bravo.
5. Qual a diferença principal entre Scrum e Kanban?
Scrum usa quadros e Kanban não.
Kanban tem Sprints fixas e Scrum é contínuo.
Scrum tem papéis e ciclos fixos; Kanban foca em fluxo contínuo.
Não há diferença.
Gabarito:
  • 1- Product Owner (PO)
  • 2- Um ciclo de tempo fixo (ex: 2 semanas) onde o trabalho é executado.
  • 3- Alinhar o time sobre o progresso e impedimentos (15 min).
  • 4- Placa visual ou cartão.
  • 5- Scrum tem papéis e ciclos fixos; Kanban foca em fluxo contínuo.

Quiz 04 - Introdução

1. "O sistema deve enviar um e-mail de confirmação de cadastro". Isso é um:
Requisito Não-Funcional.
Requisito Funcional.
Bug.
User Story.
2. "O sistema deve suportar 1 milhão de usuários simultâneos". Isso é um:
Requisito Não-Funcional (Performance).
Requisito Funcional.
Requisito de Design.
Exagero.
3. Qual a estrutura correta de uma User Story?
Quero , Como , Para .
Como , Eu quero , Para que .
O sistema deve .
O usuário precisa de .
4. Para que servem os Critérios de Aceite?
Para o cliente aceitar pagar mais.
Para definir as regras técnicas do banco de dados.
Para definir claramente quando uma história está concluída e correta.
Para nada.
5. Qual o maior risco de requisitos mal definidos?
O programador ficar entediado.
Construir o software errado, desperdiçando tempo e dinheiro.
O computador travar.
A Internet cair.
Gabarito:
  • 1- Requisito Funcional.
  • 2- Requisito Não-Funcional (Performance).
  • 3- Como , Eu quero , Para que .
  • 4- Para definir claramente quando uma história está concluída e correta.
  • 5- Construir o software errado, desperdiçando tempo e dinheiro.

Quiz 05 - Introdução

1. O que significa UML?
Ultramodern Modeling Language
Unified Modeling Language (Linguagem de Modelagem Unificada)
Universal Machine Language
User Management Logistic
2. No Diagrama de Caso de Uso, o que o "boneco palito" representa?
Um erro no sistema.
O banco de dados.
Um Ator (quem interage com o sistema).
O gerente do projeto.
3. Qual diagrama mostra a estrutura estática (classes e atributos) do sistema?
Diagrama de Caso de Uso.
Diagrama de Classes.
Diagrama de Sequência.
Fluxograma.
4. Para que serve a modelagem de software?
Para deixar o escritório mais bonito com desenhos.
Para visualizar, comunicar e documentar o sistema antes de programar.
Para substituir o código final.
Para tornar o software mais lento.
5. Em um diagrama de classes, o que são os "Métodos"?
As características da classe (ex: cor).
As ações ou comportamentos da classe (ex: andar).
O nome da classe.
As conexões.
Gabarito:
  • 1- Unified Modeling Language (Linguagem de Modelagem Unificada)
  • 2- Um Ator (quem interage com o sistema).
  • 3- Diagrama de Classes.
  • 4- Para visualizar, comunicar e documentar o sistema antes de programar.
  • 5- As ações ou comportamentos da classe (ex: andar).

Quiz 06 - Introdução

1. Qual a principal característica de uma arquitetura Monolítica?
O sistema é composto por milhares de pequenos serviços.
O sistema é um único bloco de código onde tudo está junto.
O sistema não usa banco de dados.
O sistema só roda em celulares.
2. Na arquitetura Cliente-Servidor, o que o "Cliente" geralmente faz?
Armazena todos os dados do mundo.
Processa pagamentos bancários sozinho.
Envia requisições e exibe a interface para o usuário.
Gera energia para o servidor.
3. Qual a vantagem dos Microserviços?
São extremamente simples de configurar.
Se um serviço falhar, o resto do sistema pode continuar funcionando.
Não precisam de internet.
Usam menos memória sempre.
4. O que é a camada de "Lógica de Negócio"?
A parte visual (cores e botões).
Onde ficam as regras do sistema (ex: cálculos, validações).
O cabo de rede.
A marca do computador.
5. Arquitetura de Software é fácil de mudar depois que o projeto está pronto?
Sim, muda-se em 5 minutos.
Não, geralmente é caro e difícil (como mudar a fundação de um prédio).
Depende da cor do software.
Arquitetura não existe.
Gabarito:
  • 1- O sistema é um único bloco de código onde tudo está junto.
  • 2- Envia requisições e exibe a interface para o usuário.
  • 3- Se um serviço falhar, o resto do sistema pode continuar funcionando.
  • 4- Onde ficam as regras do sistema (ex: cálculos, validações).
  • 5- Não, geralmente é caro e difícil (como mudar a fundação de um prédio).

Quiz 07 - Introdução

1. Qual a diferença entre Git e GitHub?
Git é pago, GitHub é grátis.
Git é a ferramenta de versionamento; GitHub é a plataforma de hospedagem.
São a mesma coisa.
GitHub é para jogos.
2. Qual comando "tira a foto" (salva a versão) no histórico local?
`git add`
`git upload`
`git commit`
`git save`
3. O que é um "Branch"?
Um erro no código.
Uma ramificação paralela para desenvolver sem afetar o código principal.
A marca do computador.
Um tipo de vírus.
4. Para que serve o `git push`?
Para empurrar o computador.
Para enviar as alterações locais para o repositório remoto (GitHub).
Para baixar atualizações.
Para apagar tudo.
5. Por que usamos controle de versão?
Para gastar mais espaço em disco.
Para ter histórico, backup e facilitar o trabalho em equipe.
Porque é difícil.
Para nada.
Gabarito:
  • 1- Git é a ferramenta de versionamento; GitHub é a plataforma de hospedagem.
  • 2- `git commit`
  • 3- Uma ramificação paralela para desenvolver sem afetar o código principal.
  • 4- Para enviar as alterações locais para o repositório remoto (GitHub).
  • 5- Para ter histórico, backup e facilitar o trabalho em equipe.

Quiz 08 - Introdução

1. O que é "Coesão" no design de software?
Quando o código está todo junto num arquivo só.
Quando um módulo/classe foca em uma única responsabilidade bem definida.
Quando usamos cola para unir as páginas.
Quando o software não funciona.
2. O que queremos em um bom sistema?
Baixo Acoplamento e Alta Coesão.
Alto Acoplamento e Baixa Coesão.
Código Espaguete.
Bugs complexos.
3. O que significa a sigla DRY?
Do Repeat Yourself (Repita-se).
Don't Repeat Yourself (Não se repita - Evite duplicação).
Data Run Yard.
Dry Code (Código Seco).
4. O princípio KISS sugere que:
Devemos beijar o computador.
Devemos criar as soluções mais complexas possíveis.
Devemos manter as coisas simples (Keep It Simple).
Code is Stupid Simple.
5. Qual a letra "S" do SOLID?
Simple Code Principle.
Single Responsibility Principle (Princípio da Responsabilidade Única).
Super Class Principle.
Silicon Valley.
Gabarito:
  • 1- Quando um módulo/classe foca em uma única responsabilidade bem definida.
  • 2- Baixo Acoplamento e Alta Coesão.
  • 3- Don't Repeat Yourself (Não se repita - Evite duplicação).
  • 4- Devemos manter as coisas simples (Keep It Simple).
  • 5- Single Responsibility Principle (Princípio da Responsabilidade Única).

Quiz 09 - Introdução

1. Um desenvolvedor estava cansado e digitou a fórmula de juros errada. Isso é um:
Defeito.
Erro (Ação Humana).
Falha.
Acerto.
2. O sistema calculou o valor errado para o cliente na tela. Isso é uma:
Erro.
Defeito.
Falha (Comportamento observável).
Feature.
3. Qual a diferença entre QA e Teste?
QA foca em prevenir defeitos (processo); Teste foca em achar defeitos (produto).
QA é para hardware.
Teste é feito pelo cliente.
São sinônimos.
4. Segundo a regra 1-10-100, quando é mais barato corrigir um problema?
Na produção (quando o cliente usa).
Nos testes.
No início (Requisitos/Design).
Nunca.
5. Um software perfeito é:
Aquele sem nenhum bug (impossível na prática, mas almejado).
Aquele que atende aos requisitos e satisfaz o usuário.
Aquele feito em Python.
Aquele que nunca foi lançado.
Gabarito:
  • 1- Erro (Ação Humana).
  • 2- Falha (Comportamento observável).
  • 3- QA foca em prevenir defeitos (processo); Teste foca em achar defeitos (produto).
  • 4- No início (Requisitos/Design).
  • 5- Aquele que atende aos requisitos e satisfaz o usuário.

Quiz 10 - Introdução

1. Qual teste fica na base da Pirâmide de Testes (devemos ter em maior quantidade)?
Teste Manual.
Teste End-to-End (E2E).
Teste Unitário.
Teste de Usabilidade.
2. O que valida um Teste Unitário?
O sistema inteiro.
A menor parte testável do código (ex: uma função).
A integração com o banco de dados.
A cor do botão.
3. No TDD (Test Driven Development), qual a ordem correta?
Código -> Teste -> Refatoração.
Teste -> Código -> Refatoração.
Refatoração -> Teste -> Código.
Teste -> Refatoração -> Código.
4. Por que não devemos ter APENAS testes manuais?
Porque são lentos, caros e propensos a falhas humanas.
Porque testadores manuais não existem.
Porque computadores não gostam de mãos.
Porque é muito rápido.
5. O que significa o estado "Red" no TDD?
O teste falhou (porque a funcionalidade ainda não existe).
O computador está superaquecendo.
O código está pronto e funcionando.
O teste deve ser apagado.
Gabarito:
  • 1- Teste Unitário.
  • 2- A menor parte testável do código (ex: uma função).
  • 3- Teste -> Código -> Refatoração.
  • 4- Porque são lentos, caros e propensos a falhas humanas.
  • 5- O teste falhou (porque a funcionalidade ainda não existe).

Quiz 11 - Introdução

1. O que significa DevOps?
Desenvolvimento de Operações Secretas.
Development + Operations (União de Desenvolvimento e Operações).
Um novo sistema operacional.
Departamento de Vendas.
2. Qual o principal objetivo do DevOps?
Criar barreiras entre os times.
Entregar software com mais velocidade e qualidade através da colaboração e automação.
Eliminar todos os gerentes.
Usar computadores mais rápidos.
3. O que acontece na etapa de "CI" (Integração Contínua)?
O código é misturado e testado automaticamente com frequência.
O cliente testa o software.
O computador é reiniciado.
Nada.
4. A frase "Funciona na minha máquina" é um sintoma de:
Falta de um ambiente padronizado e automatizado (Problema que DevOps resolve).
Um computador muito bom.
Um programador excelente.
Sorte.
5. O que é um Pipeline de CI/CD?
Um cano de água.
Uma sequência de passos automatizados que o código percorre (Build, Test, Deploy).
Um jogo de encanador.
Uma ferramenta de chat.
Gabarito:
  • 1- Development + Operations (União de Desenvolvimento e Operações).
  • 2- Entregar software com mais velocidade e qualidade através da colaboração e automação.
  • 3- O código é misturado e testado automaticamente com frequência.
  • 4- Falta de um ambiente padronizado e automatizado (Problema que DevOps resolve).
  • 5- Uma sequência de passos automatizados que o código percorre (Build, Test, Deploy).

Quiz 12 - Introdução

1. Qual e a diferença entre Autenticação e Autorização?
Autenticação confirma quem você é; Autorização define o que você pode fazer.
São a mesma coisa.
Autenticação é para sair do sistema.
Autorização é para entrar no sistema.
2. O que significa a sigla CIA em segurança?
Central Intelligence Agency.
Confidentiality, Integrity, Availability.
Code Is Awesome.
Computer Internet Access.
3. O que é SQL Injection?
Uma técnica para deixar o banco de dados mais rápido.
Um ataque onde código malicioso é inserido em campos de entrada para manipular o banco de dados.
Uma vacina para computadores.
Um tipo de monitor.
4. Quando devemos começar a pensar na segurança do software?
Depois que o software for hackeado.
Apenas na fase de testes.
Desde o início do projeto (Security by Design).
Nunca, segurança é problema do usuário.
5. O que é a OWASP?
Uma marca de antivírus.
Uma organização que documenta e compartilha conhecimentos sobre segurança de software.
Um governo.
Um tipo de senha.
Gabarito:
  • 1- Autenticação confirma quem você é; Autorização define o que você pode fazer.
  • 2- Confidentiality, Integrity, Availability.
  • 3- Um ataque onde código malicioso é inserido em campos de entrada para manipular o banco de dados.
  • 4- Desde o início do projeto (Security by Design).
  • 5- Uma organização que documenta e compartilha conhecimentos sobre segurança de software.

Quiz 13 - Introdução

1. O que acontece se tentarmos aumentar o escopo de um projeto mantendo o mesmo prazo e custo?
A qualidade provavelmente cairá.
O projeto ficará pronto mais cedo.
Os desenvolvedores ficarão felizes.
Nada.
2. O que significa MVP?
Most Valuable Player.
Minimum Viable Product (Mínimo Produto Viável).
Maximum Virtual Process.
Mini Video Player.
3. Qual o objetivo do "Planning Poker"?
Jogar cartas e apostar dinheiro.
Estimar a complexidade das tarefas em equipe de forma colaborativa.
Decidir quem vai pagar o almoço.
Escolher o nome do produto.
4. Na técnica MoSCoW, o que significa o "M" (Must Have)?
Funcionalidades que TALVEZ o sistema tenha.
Funcionalidades OBRIGATÓRIAS para o sistema funcionar.
Funcionalidades que NÃO teremos.
Funcionalidades de Marketing.
5. Por que usamos pontos (Fibonacci) em vez de horas para estimar?
Porque horas são muito precisas.
Porque a complexidade relativa é mais fácil de acertar do que o tempo exato.
Porque Fibonacci era um programador famoso.
Porque horas custam dinheiro.
Gabarito:
  • 1- A qualidade provavelmente cairá.
  • 2- Minimum Viable Product (Mínimo Produto Viável).
  • 3- Estimar a complexidade das tarefas em equipe de forma colaborativa.
  • 4- Funcionalidades OBRIGATÓRIAS para o sistema funcionar.
  • 5- Porque a complexidade relativa é mais fácil de acertar do que o tempo exato.

Quiz 14 - Introdução

1. Qual a melhor definição para a frase "O código se documenta sozinho"?
Uma verdade absoluta, nunca precisamos escrever documentos.
Um mito perigoso. Código limpo ajuda, mas documentação de contexto é essencial.
O código fala com a gente usando IA.
Documentação é proibida no Ágil.
2. O que deve conter um arquivo README.md?
A história da vida do programador.
Receitas de bolo.
Resumo do projeto, como instalar e usar.
Versículos bíblicos.
3. Para quem é voltada a Documentação de API?
Para o cliente final (dona de casa).
Para outros desenvolvedores que vão integrar com seu sistema.
Para o gerente de vendas.
Para ninguém.
4. O que é Markdown?
Uma marca de roupa.
Uma linguagem de marcação leve usada para formatar textos (como este aqui).
Um código difícil de ler.
Um banco de dados.
5. Qual a diferença entre documentação de Usuário e Técnica?
De usuário é para quem usa o software; Técnica é para quem constrói/mantém.
Não há diferença.
Técnica deve ser escrita em latim.
De usuário deve ser escrita em código.
Gabarito:
  • 1- Um mito perigoso. Código limpo ajuda, mas documentação de contexto é essencial.
  • 2- Resumo do projeto, como instalar e usar.
  • 3- Para outros desenvolvedores que vão integrar com seu sistema.
  • 4- Uma linguagem de marcação leve usada para formatar textos (como este aqui).
  • 5- De usuário é para quem usa o software; Técnica é para quem constrói/mantém.

Quiz 15 - Introdução

1. O que é Refatoração?
Mudar o software para ele fazer coisas novas.
Apagar todo o código e começar do zero.
Alterar a estrutura interna do código para melhorá-lo, sem mudar o comportamento externo.
Adicionar bugs.
2. O que significa "Dívida Técnica"?
Quanto dinheiro o projeto deve ao banco.
O custo futuro gerado por escolher uma solução rápida e fácil agora em vez de uma abordagem melhor.
O salário do programador.
O preço da licença do software.
3. Manutenção Corretiva serve para:
Adicionar novas telas.
Corrigir defeitos (bugs).
Melhorar a performance.
Adaptar ao novo Windows.
4. Segundo a Regra do Escoteiro no código:
Devemos acampar no escritório.
Devemos sempre deixar o código um pouco mais limpo do que encontramos.
Só devemos mexer no que está quebrado.
Devemos apagar comentários.
5. Por que o software precisa evoluir?
Porque o mundo, os negócios e as tecnologias mudam.
Porque programadores ficam entediados.
Para gastar dinheiro.
Não precisa, software dura para sempre igual.
Gabarito:
  • 1- Alterar a estrutura interna do código para melhorá-lo, sem mudar o comportamento externo.
  • 2- O custo futuro gerado por escolher uma solução rápida e fácil agora em vez de uma abordagem melhor.
  • 3- Corrigir defeitos (bugs).
  • 4- Devemos sempre deixar o código um pouco mais limpo do que encontramos.
  • 5- Porque o mundo, os negócios e as tecnologias mudam.

Quiz 16 - Introdução

1. O que é um profissional "T-Shaped"?
Alguém que só usa camisetas com gola T.
Alguém que tem conhecimento profundo em uma área e conhecimentos gerais em outras.
Alguém que só sabe uma coisa e ignora o resto.
Alguém que sabe tudo sobre tudo.
2. Por que a ética é fundamental na Engenharia de Software?
Porque softwares impactam vidas, privacidade e a sociedade.
Porque é bonito no currículo.
Para passar na faculdade.
Não é importante.
3. Qual destas é uma Soft Skill essencial?
Saber programar em Assembly.
Comunicação clara e empática.
Digitar muito rápido.
Instalar o Windows.
4. Sobre o futuro com IA na programação:
A IA vai programar tudo sozinha amanhã e ninguém mais terá emprego.
A IA servirá como ferramenta de apoio, aumentando a produtividade dos engenheiros.
A IA é proibida.
Devemos voltar a usar papel e caneta.
5. Qual o próximo passo após terminar este curso?
Parar de estudar para sempre.
Continuar praticando, construir portfólio e aprender novas tecnologias (Lifelong Learning).
Esquecer tudo.
Mudar de área.
Gabarito:
  • 1- Alguém que tem conhecimento profundo em uma área e conhecimentos gerais em outras.
  • 2- Porque softwares impactam vidas, privacidade e a sociedade.
  • 3- Comunicação clara e empática.
  • 4- A IA servirá como ferramenta de apoio, aumentando a produtividade dos engenheiros.
  • 5- Continuar praticando, construir portfólio e aprender novas tecnologias (Lifelong Learning).

Projetos

Projetos Práticos

Ao longo deste curso, desenvolveremos um projeto contínuo: Sistema de Gestão de Tarefas (To-Do App). Focaremos na engenharia por trás do software, desde a concepção até a manutenção.

🚀 Dicas para o Projeto

  1. Foco no Processo: O objetivo é praticar as etapas da Engenharia de Software, não apenas "fazer funcionar".
  2. Documente Tudo: Suas decisões devem estar registradas.
  3. Evolução Contínua: O projeto cresce a cada aula. Mantenha seus arquivos organizados.

Projeto 01

Neste curso, vamos simular o desenvolvimento de um Sistema de Gerenciamento de Tarefas (To-Do App) completo.

Atividade da Aula: - Papel: Você é o Engenheiro de Software responsável. - Tarefa: Definir o escopo inicial (Requisitos de Alto Nível). - Ação: Crie um documento de texto simples listando 3 funcionalidades essenciais que um App de Tarefas DEVE ter para ser útil (ex: "Adicionar tarefa"). Isso será a base para as próximas aulas.

Projeto 02

Continuando com nosso To-Do App:

Atividade da Aula: - Decisão: Vamos adotar uma abordagem Ágil simplificada para este projeto. - Ação: 1. Divida as funcionalidades que você listou na Aula 01 em 3 "Entregas" (ou Sprints). 2. Entrega 1: O básico do básico (MVP). 3. Entrega 2: Melhorias importantes. 4. Entrega 3: Extras ("firulas"). 5. Escreva isso no seu documento de projeto.

Projeto 03

Atividade da Aula: Vamos organizar as tarefas que definimos na Aula 02 usando conceitos do Scrum.

  1. Product Backlog: Pegue todas as tarefas listadas (Fase 1, 2 e 3) e coloque em uma lista única, ordenada por prioridade (o mais importante no topo).
  2. Sprint 1: Selecione os itens do topo da lista que cabem na primeira "Sprint" (nosso MVP).
  3. Ferramenta: Crie um quadro no Trello, Notion ou apenas desenhe em papel com colunas: Backlog, Sprint 1, Fazendo, Feito.
  4. Mova os itens da Sprint 1 para a coluna A Fazer.

Projeto 04

Atividade da Aula: Vamos detalhar a Sprint 1 (MVP) usando User Stories.

  1. Pegue os itens que você colocou na coluna "To Do" do seu quadro (Aula 03).
  2. Reescreva cada um deles no formato de User Story.
    • Ex: De "Login" para "Como um usuário cadastrado, quero fazer login, para acessar minhas tarefas privadas."
  3. Adicione pelo menos 2 Critérios de Aceite para cada história.
    • Ex: "Login com senha errada deve mostrar mensagem de erro."
  4. Identifique 1 Requisito Não-Funcional para seu app (ex: ele deve funcionar offline?).

Projeto 05

Atividade da Aula: Vamos criar modelos simples para o To-Do App.

  1. Diagrama de Caso de Uso:
    • Identifique os Atores (ex: Usuário Comum, talvez? Admin?).
    • Desenhe (ou liste) os Casos de Uso ligados a eles (ex: Criar Tarefa, Completar Tarefa).
  2. Diagrama de Classes (Conceitual):
    • Pense na principal "coisa" do seu app: a Tarefa.
    • Quais atributos ela tem? (Título, Descrição, Data, EstáConcluída?).
    • Quais métodos ela poderia ter? (Concluir(), Editar(), Adiar()?).
  3. Ferramenta: Use papel e caneta, ou ferramentas online como Draw.io ou Mermaid.live.

Projeto 06

Atividade da Aula: Vamos definir a arquitetura do To-Do App.

  1. Tipo: Vamos usar uma arquitetura Web Simples (SPA - Single Page Application).
    • Frontend: HTML/JS (simulado no navegador).
    • Backend: Simulado (Local Storage do navegador).
  2. Desenho da Arquitetura:
    • Desenhe um quadrado "Navegador" contendo "HTML" e "JavaScript".
    • Desenhe um "Banco de Dados Local" dentro do navegador.
    • Isso mostra que, no nosso MVP, não teremos servidor externo (Serverless/Local).
  3. Decisão: Escreva no seu documento de projeto: "Arquitetura escolhida: Local/Client-side apenas". Justificativa: "Simplicidade para aprender e custo zero".

Projeto 07

Atividade da Aula: Vamos simular o versionamento do nosso To-Do App.

  1. Inicializar: Imagine que você rodou git init na pasta do projeto.
  2. Primeiro Commit:
    • Você criou os arquivos iniciais (index.html, style.css).
    • Rodou git add .
    • Rodou git commit -m "Estrutura inicial do projeto".
  3. Simulação de Branch:
    • Você quer tentar mudar a cor de fundo para rosa, mas não tem certeza se vai gostar.
    • O que você faz? Tenta direto na main ou cria uma branch experimentacao-cor?
  4. No Documento: Escreva o nome de 3 commits que você faria ao longo do projeto (ex: "Adicionar funcionalidade de login").

Projeto 08

Atividade da Aula: Vamos aplicar o DRY no nosso projeto teórico.

  1. Cenário: No nosso To-Do App, toda vez que uma tarefa é concluída, precisamos atualizar o contador de "Tarefas Pendentes" na tela. Isso acontece quando criamos, excluímos ou completamos uma tarefa.
  2. Problema: Se escrevermos o código de contar e atualizar a tela em todos esses lugares, ferimos o DRY.
  3. Solução: Crie uma função chamada atualizarContador().
  4. No Documento: Escreva em pseudocódigo: 
    função atualizarContador() {
   pendentes = contarTarefasNaoFeitas()
   tela.exibir(pendentes)
}

// Agora só chamamos a função:
aoCriarTarefa -> atualizarContador()
aoExcluirTarefa -> atualizarContador()

Projeto 09

Atividade da Aula: Como vamos garantir a qualidade do To-Do App?

  1. Critérios de Aceite: Revise os critérios que você criou na Aula 04. Eles são a base do teste.
  2. Checklist de QA Manual: Crie uma lista de checagem para ser feita ANTES de dizer que uma tarefa está pronta.
    • Ex:
      • [ ] Funciona no Chrome?
      • [ ] Funciona no Celular?
      • [ ] O que acontece se eu tentar criar uma tarefa sem título? (Teste Negativo)
  3. Ação: Adicione esse "Checklist de Qualidade" ao seu documento de projeto.

Projeto 10

Atividade da Aula: Vamos planejar os testes para o nosso To-Do App.

  1. Escolha uma funcionalidade: Vamos usar "Adicionar Tarefa".
  2. Crie Casos de Teste (Cenários):
    • CT01: Adicionar tarefa com título válido. (Resultado Esperado: Tarefa aparece na lista).
    • CT02: Tentar adicionar tarefa sem título. (Resultado Esperado: Erro/Alerta, tarefa NÃO aparece).
    • CT03: Adicionar tarefa com título muito longo (ex: 500 caracteres). (Resultado Esperado: Truncar ou erro?).
  3. Ação: Adicione uma tabela "Plano de Testes" ao seu documento de projeto com esses casos.

Projeto 11

Atividade da Aula: Não vamos configurar um servidor Jenkins/GitHub Actions real, mas vamos simular o processo.

  1. Regra do Projeto: A partir de agora, ninguém (você) pode considerar uma tarefa "Pronta" sem rodar os testes da Aula 10.
  2. O Pipeline Manual:
    • Toda vez que você terminar uma tarefa:
      1. Salve o arquivo.
      2. Abra o navegador.
      3. Teste se funciona (Executar Testes Manuais).
      4. Se passar -> Faça o Commit.
      5. Se falhar -> Corrija e volte ao passo 1.
  3. Documentação: Escreva no seu projeto: "Política de CI: Commits apenas após testes passarem com sucesso".

Projeto 12

Atividade da Aula: Vamos pensar como um hacker para proteger nosso To-Do App.

  1. Identifique Riscos:
    • Risco 1: Alguém pode ver as tarefas de outra pessoa? (No nosso caso localstorage, só quem usa o PC vê. Mas e se fosse na web?).
    • Risco 2: Injeção de Script (XSS). Se eu criar uma tarefa com o título <script>alert('oi')</script>, o navegador vai executar esse código?
  2. Mitigação (Proteção):
    • Para o Risco 2: Devemos "higienizar" (sanitize) tudo que o usuário digita antes de mostrar na tela. O texto deve ser tratado como texto, nunca como código executável.
  3. Documentação: Adicione uma seção "Segurança" no seu projeto listando: "Risco de XSS nos títulos das tarefas" e a solução "Sanitize inputs".

Projeto 13

Atividade da Aula: Volte ao Backlog do seu To-Do App (Aula 03).

  1. Aplique MoSCoW: Marque cada item com M, S, C ou W.
    • Criar Tarefa: Must?
    • Editar Tarefa: Should?
    • Modo Escuro: Could?
    • Integração com Google Agenda: Won't?
  2. Defina os Pontos (Estimativa):
    • Atribua pontos (1, 2, 3, 5, 8) para o esforço de cada tarefa.
    • Ex: Criar Tarefa (5 pontos), Excluir Tarefa (2 pontos).
  3. Corte: Se sua Sprint só "aguenta" 10 pontos, quais tarefas entram?

Projeto 14

Atividade da Aula: Chegou a hora de criar a "capa" do nosso To-Do App.

  1. Crie um arquivo README.md (simulado no seu documento de projeto).
  2. Escreva:
    • Título: To-Do App Super.
    • Descrição: Um gerenciador de tarefas simples e ágil.
    • Tecnologias: HTML, CSS, JS, LocalStorage.
    • Como rodar: "Abra o arquivo index.html no navegador".
    • Autor: Seu Nome.
  3. Entrega: Cole o conteúdo Markdown no seu documento oficial.

Projeto 15

Atividade da Aula: Vamos "pagar" uma dívida técnica do nosso To-Do App.

  1. Analise seu CSS/Design: Você escreveu estilos direto no HTML (style="...") ou criou classes confusas?
  2. Ação: Simplifique. Se tiver cores repetidas, crie variáveis CSS (:root { --cor-principal: blue; }).
  3. Documente: No seu projeto, crie uma seção "Histórico de Mudanças" e adicione: "Refatoração do CSS para usar variáveis. Motivo: Facilitar mudança de tema futuro."

Projeto 16 - A Entrega Final

🎯 Objetivo

Compilar todo o aprendizado em um "Book" do Projeto.

📝 Descrição

O software é importante, mas a documentação do processo prova que você é um Engenheiro, não apenas um digitador de código.

🚀 Estrutura do Seu Portfólio

Organize seus arquivos (simbolicamente) nesta ordem:

  1. Capa (README): O que é o projeto.
  2. Planejamento:
    • Backlog e Priorização (MoSCoW).
    • Estimativas.
  3. Design:
    • Diagramas de Caso de Uso e Classes.
    • Arquitetura Escolhida.
  4. Qualidade:
    • Plano de Testes.
    • Casos de Teste.
  5. Segurança:
    • Modelagem de Ameaças.
  6. Evolução:
    • Changelog (Histórico de Mudanças).

📤 Parabéns!

Você completou o curso "Engenharia de Software para Iniciantes". Agora você tem uma visão holística de como softwares nascem, vivem e evoluem.

Configuração

Configuração do Ambiente

Bem-vindo à seção de configuração! Aqui você encontra o guia para preparar seu computador para o curso.

  • Ambiente de Desenvolvimento

    Instalação do VS Code, Git e configuração básica.

    Ver Guia

Configuração do Ambiente de Desenvolvimento

Para este curso de Engenharia de Software, precisaremos de algumas ferramentas essenciais. Não se preocupe, todas são gratuitas e amplamente usadas no mercado de trabalho.

1. Visual Studio Code (VS Code)

O VS Code é o editor de código mais popular do mundo. Usaremos ele para escrever nossos projetos, visualizar arquivos Markdown e gerenciar nosso código.

  • Baixar: code.visualstudio.com
  • Instalar: Siga o padrão (Next, Next, Install).
  • Extensões Recomendadas:
    • Markdown All in One (para visualizar este curso)
    • Draw.io Integration (para criar diagramas UML)

2. Git

O Git é o sistema de controle de versão que todo Engenheiro de Software deve conhecer.

  • Baixar: git-scm.com/downloads
  • Instalar: Pode manter as opções padrão.
  • Verificar: Abra o terminal (cmd ou PowerShell) e digite: 
    git --version

3. GitHub

Não precisamos instalar nada, mas você precisa de uma conta. - Criar Conta: github.com

Próximos Passos

Com o VS Code e o Git instalados, você está pronto para começar! As aulas guiarão você no uso dessas ferramentas conforme necessário.

Versão para Impressão

Esta página foi gerada automaticamente para impressão.