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 Python.

    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?

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, ela se preocupa com: - 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?

"Software Engineering is programming integrated over time." — Titus Winters (Google)

2. A Crise do Software e a Necessidade de Processos

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.

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. As fases clássicas são:

  1. Levantamento de Requisitos: Entender O QUE deve ser construído (ex: "O usuário precisa fazer login").
  2. Análise e Design: Planejar COMO será construído (ex: "Usaremos um banco de dados SQL e uma interface web").
  3. Implementação (Codificação): Escrever o código de fato.
  4. Testes (Verificação): Garantir que não há erros (bugs).
  5. Implantação (Deploy): Colocar o software no ar para o usuário.
  6. Manutenção: Corrigir problemas e adicionar novas funcionalidades após o lançamento.

4. Analogia: Construindo uma Casa

  • Requisitos: Conversar com o arquiteto sobre quantos quartos a casa terá.
  • Design: Desenhar a planta baixa e escolher os materiais.
  • Implementação: Pedreiros levantando paredes e instalando encanamento.
  • Testes: Verificar se as luzes acendem e se não há vazamentos.
  • Implantação: Entregar as chaves ao dono.
  • Manutenção: Pintar paredes descascadas ou consertar uma telha quebrada anos depois.

📅 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 mais antigo e tradicional. Nele, cada fase do SDLC deve ser completada antes da próxima começar.

  • Fluxo: Requisitos -> Design -> Código -> Testes -> Deploy.
  • Características: Rígido, documentação extensa.
  • Problema: Se o cliente mudar de ideia na fase de testes, voltar para mudar os requisitos é muito caro e difícil. É como construir um prédio: difícil mudar a fundação depois que o teto está pronto.

2. O Modelo V (V-Model)

Uma evolução do Cascata que enfatiza os testes. Para cada fase de desenvolvimento (verifique o lado esquerdo do V), existe uma fase de teste correspondente (lado direito do V).

3. O Manifesto Ágil (2001)

Devido à rigidez do Cascata, um grupo de desenvolvedores propôs uma nova forma de trabalhar, valorizando: - Indivíduos e interações mais que processos e ferramentas. - Software em funcionamento mais que documentação abrangente. - Colaboração com o cliente mais que negociação de contratos. - Responder a mudanças mais que seguir um plano.

4. Abordagem Ágil vs. Tradicional

  • Tradicional (Cascata): Planeja tudo no início (Big Design Up Front). Entrega o software só no final.
  • Ágil: Planeja em ciclos curtos (Sprints). Entrega partes do software funcionando frequentemente (Incremental e Iterativo).

📅 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

O Scrum é uma estrutura para gerenciar trabalhos complexos. Ele divide o tempo em ciclos chamados Sprints (geralmente 2 semanas).

Os Papéis (Quem faz o quê?)

  • Product Owner (PO): Representa o cliente. Decide O QUE será feito (o "Dono do Produto").
  • Scrum Master: Garante que o time siga as regras do Scrum e remove impedimentos.
  • Time de Desenvolvimento: Quem constrói o software (Designers, Devs, Testers).

Os Artefatos (Documentos)

  • Product Backlog: Lista de tudo que o produto precisa ter.
  • Sprint Backlog: Lista do que será feito nesta Sprint.
  • Incremento: O pedaço do software pronto ao final da Sprint.

Os Eventos (Reuniões)

  • Sprint Planning: Planejar o que fazer.
  • Daily Scrum: Reunião diária de 15 min para alinhar o time.
  • Sprint Review: Mostrar o trabalho pronto ao cliente.
  • Sprint Retrospective: Discutir como melhorar o processo.

2. Kanban: Fluxo Contínuo

O Kanban (placa visual) foca em visualizar o trabalho e limitar a quantidade de coisas sendo feitas ao mesmo tempo.

  • Quadro Kanban: Colunas como "A Fazer" (To Do), "Fazendo" (In Progress), "Feito" (Done).
  • Sem Sprints fixas: O trabalho flui continuamente. Terminou uma tarefa? Puxa a próxima.

3. Scrum vs. Kanban

  • Scrum: Mais estruturado, ciclos fixos, papéis definidos. Bom para projetos onde mudanças são esperadas mas precisam de ordem.
  • Kanban: Mais flúido, fluxo contínuo. Bom para manutenção ou quando as prioridades mudam diariamente.

📅 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". - Sem requisitos claros = Projeto fracassado (O famoso balanço na árvore).

2. Tipos de Requisitos

A) Requisitos Funcionais (RF)

Descrevem o que o sistema FAZ. São as funcionalidades perceptíveis pelo usuário. - Exemplo: "O sistema deve permitir cadastrar um novo cliente." - Exemplo: "O sistema deve calcular o total da compra."

B) Requisitos Não-Funcionais (RNF)

Descrevem COMO o sistema deve ser. São restrições e qualidades (performance, segurança, usabilidade). - Exemplo: "O sistema deve carregar qualquer página em menos de 2 segundos." (Performance) - Exemplo: "O sistema deve funcionar em celulares Android e iOS." (Portabilidade) - Exemplo: "A senha deve ser criptografada." (Segurança)

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

No modelo Ágil, usamos User Stories para descrever requisitos de forma simples, focada no valor para o usuário. Modelo: Como um <tipo de usuário>, eu quero <ação>, para que <benefício>.

Exemplo: "Como um usuário do To-Do App, eu quero criar uma nova tarefa, para que eu não esqueça meus compromissos."

4. Critérios de Aceite

Complementam a User Story definindo quando ela está "pronta". Ex para "Criar Tarefa": - O campo de título é obrigatório. - A data de vencimento é opcional. - Ao salvar, deve aparecer na lista principal.

📅 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.
  • Aprender a ler Diagramas de Classes básicos.

📚 Conteúdo

1. Por que modelar?

Assim como arquitetos desenham plantas antes de construir, engenheiros de software criam modelos para: - Visualizar o sistema antes de codificar. - Comunicar ideias com o time. - Encontrar erros de lógica cedo.

2. O que é UML?

UML (Linguagem de Modelagem Unificada) é o padrão mundial para desenhar diagramas de software. Não é uma linguagem de programação, é uma linguagem visual.

3. Diagrama de Caso de Uso (O "O Quê" e "Quem")

Mostra as interações entre usuários (Atores) e o sistema (Casos de Uso).

  • Ator (Boneco palito): Quem usa o sistema (ex: Cliente, Admin).
  • Caso de Uso (Elipse): Uma funcionalidade (ex: "Fazer Login", "Comprar Produto").
  • Linha: Conecta quem faz o quê.

Exemplo: Um boneco "Cliente" ligado a uma elipse "Realizar Pedido".

4. Diagrama de Classes (A Estrutura)

Mostra a estrutura estática do sistema: as "coisas" que existem nele e seus relacionamentos.

  • Classe (Retângulo): Representa um conceito (ex: Carro).
  • Atributos: O que a classe tem (ex: cor, modelo).
  • Métodos: O que a classe faz (ex: acelerar(), frear()).

Exemplo: 

classDiagram
    Pessoa <|-- Aluno
    class Pessoa {
        +nome: string
        +idade: int
        +andar()
    }
    class Aluno {
        +matricula: int
        +estudar()
    }
(Nota: O diagrama acima mostra que Aluno é um tipo de Pessoa - Herança).

📅 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.
  • Compreender MVC e Padrões de Camadas.

📚 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 se será um prédio de aço, uma casa de madeira ou uma cabana. - Define a organização fundamental do sistema. - Difícil de mudar depois de pronto.

2. Monólito vs. Microserviços

Monólito (Tudo junto)

O sistema inteiro é um único bloco de código. - Vantagens: Simples de desenvolver e implantar no início. - Desvantagens: Se uma parte cai, tudo cai. Difícil de escalar.

Microserviços (Peças separadas)

O sistema é dividido em pequenos serviços independentes que conversam entre si (via API). - Vantagens: Se o serviço de "Pagamento" cair, o "Catálogo" continua funcionando. Cada time cuida de um pedaço. - Desvantagens: Muito mais complexo de gerenciar.

3. Client-Server (Cliente-Servidor)

A arquitetura mais comum na Web. - Client (Frontend): O que o usuário vê (Navegador, App Mobile). - Server (Backend): Onde os dados e a lógica vivem. - Eles conversam via HTTP (Internet).

4. Padrões de Camadas (Layered)

Organizar o código em "fatias" para não virar uma bagunça. - Apresentação (UI): Botões, telas. - Lógica de Negócio: Regras (ex: "Não pode sacar mais que o saldo"). - Dados (Persistência): Salvar no 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 assim: - trabalho_final.doc - trabalho_final_agora_vai.doc - trabalho_final_V2_corrigido.doc

No desenvolvimento de software, isso é o caos. Precisamos de uma máquina do tempo.

2. O que é Git?

O Git é um sistema de controle de versão distribuído. Ele registra quem mudou o que e quando. - Máquina do Tempo: Você pode voltar o código para como ele estava ontem. - Trabalho em Equipe: Permite que várias pessoas mexam no mesmo projeto sem apagar o trabalho uma da outra.

3. O que é GitHub?

O GitHub é uma rede social para códigos. É um servidor na nuvem onde você guarda seus repositórios Git. - Git = Ferramenta instalada no seu PC. - GitHub = Site onde o código fica hospedado.

4. Ciclo Básico

  1. Working Directory: Onde você edita os arquivos.
  2. Staging Area (git add): Escolhe os arquivos que vão ser salvos.
  3. Repository (git commit): Tira uma "foto" definitiva (Save Point).
  4. Remote (git push): Envia para o GitHub.

Exemplo de fluxo no terminal: 

$ git init
$ git add .
$ git commit -m "Meu primeiro commit"
$ git push origin main

5. Branches (Ramos)

Imagine uma linha do tempo principal (main). Para criar uma nova funcionalidade sem quebrar o que já funciona, criamos uma linha paralela (feature). Se der certo, juntamos tudo (merge).

📅 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 (Keep It Simple, Stupid) e DRY (Don't Repeat Yourself).
  • Conhecer os Princípios SOLID (visão geral).

📚 Conteúdo

1. Design de Software

Design não é (só) sobre cores. É sobre como organizar o código para que ele não se torne um "Monstro de Espaguete" impossível de dar manutenção.

2. Conceitos Chave

Coesão (Bom)

Uma peça de software (função, classe) deve fazer uma única coisa e fazê-la bem. - Exemplo Ruim: Uma função processarTudo() que calcula imposto, salva no banco e envia e-mail. - Exemplo Bom: 3 funções separadas: calcularImposto(), salvarPedido(), enviarEmail().

Acoplamento (Ruim quando alto)

O quanto uma peça depende da outra. Se você muda A e precisa mudar B, C e D, o acoplamento está alto. - Queremos Baixo Acoplamento e Alta Coesão.

3. Princípios Básicos

  • KISS (Keep It Simple, Stupid): A solução mais simples quase sempre é a melhor. Não complique.
  • DRY (Don't Repeat Yourself): Nunca copie e cole código. Se a lógica se repete, crie uma função.

4. SOLID (Visão Geral)

São 5 mandamentos da Orientação a Objetos: - SRP (Single Responsibility): Uma classe deve ter um único motivo para mudar. - OCP (Open/Closed): Aberto para extensão, fechado para modificação. - LSP (Liskov): Filhos devem substituir pais sem quebrar nada. - ISP (Interface Segregation): Interfaces específicas são melhores que uma geral. - DIP (Dependency Inversion): Dependa de abstrações, não de implementações.

📅 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 (não trava, é rápido, é seguro). - Não adianta ter código lindo se o botão de comprar não funciona.

2. Conceitos de "Erro"

Na engenharia, somos precisos com os termos: 1. Erro (Mistake): Ação humana errada. - Ex: O programador esqueceu um ponto-e-vírgula. 2. Defeito (Fault/Bug): O resultado do erro no código. - Ex: O código tem um loop infinito. 3. Falha (Failure): O comportamento errado percebido pelo usuário. - Ex: O site travou quando cliquei em "Salvar".

Pessoa erra -> Cria Defeito -> Causa Falha.

3. Quality Assurance (QA)

Garantia de Qualidade não é só testar no final. É um conjunto de atividades para garantir que o processo de desenvolvimento gere produtos bons. - QA (Processo): Foco em prevenir defeitos. - Teste (Produto): Foco em encontrar defeitos.

4. A Regra 1-10-100

Quanto mais tarde você descobre um bug, mais caro ele é para corrigir. - Descobrir na fase de Requisitos: Custa $1. - Descobrir na fase de Testes: Custa $10. - Descobrir na Produção (Cliente achou): Custa $100 (ou o fim da reputação da empresa).

📅 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.
  • Introduzir o conceito de TDD (Test Driven Development).

📚 Conteúdo

1. Por que testar automaticamente?

Testar manualmente (clicar no botão toda vez que muda o código) é: - Lento. - Chato. - Propenso a erro humano.

Testes automatizados são robôs que verificam seu código em milissegundos.

2. A Pirâmide de Testes

Idealizada por Mike Cohn, sugere a quantidade de testes que devemos ter: 1. Base (Muitos): Testes Unitários. Rápidos e baratos. 2. Meio (Alguns): Testes de Integração. 3. Topo (Poucos): Testes de Interface (E2E). Lentos e caros.

3. Tipos de Teste

Teste Unitário

Testa a menor parte do código isoladamente (uma função, uma classe). - Ex: A função somar(2, 2) retorna 4?

Teste de Integração

Testa se duas ou mais partes funcionam juntas. - Ex: A função SalvarPedido consegue gravar no BancoDeDados?

Teste End-to-End (E2E)

Testa o fluxo completo do usuário. - Ex: Um robô abre o navegador, clica em comprar e verifica se apareceu "Sucesso".

4. TDD (Test Driven Development)

Uma técnica onde você escreve o teste ANTES do código. - Red: Escreve o teste (ele falha, pois o código não existe). - Green: Escreve o código mínimo para o teste passar. - Refactor: Melhora o código garantindo que o teste continua passando.

📅 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 Problema "Funciona na minha máquina"

Antigamente, Desenvolvedores (Dev) criavam o software e jogavam por cima do muro para Operações (Ops) instalar. - Resultado: Conflitos, demoras e culpa ("Foi culpa do servidor!", "Não, foi culpa do código!").

2. DevOps (Dev + Ops)

DevOps não é uma cargo, é uma cultura. É a união de pessoas, processos e ferramentas para entregar software com velocidade e qualidade. - Objetivo: Diminuir o tempo entre "Tive uma ideia" e "O cliente está usando".

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

Imagine uma fábrica de carros robotizada. Isso é CI/CD.

CI (Continuous Integration)

  • Todo código novo é integrado ao projeto principal frequentemente.
  • Robôs rodam os testes automaticamente.
  • Se quebrar algo, o time para e conserta na hora.

CD (Continuous Delivery/Deployment)

  • Após passar no CI, o código é preparado automaticamente para ir para produção.
  • Delivery: Botão "Deploy" manual mas automatizado por trás.
  • Deployment: Vai direto para o ar sem intervenção humana.

4. O Pipeline

O caminho que o código percorre: 1. Dev faz git push. 2. Build: O robô compila o código. 3. Test: O robô roda os testes unitários. 4. Deploy: O robô atualiza o site.

Se qualquer passo falhar, o processo para (Stop the Line).

📅 Atividades

Aula 12 – Segurança de Software

🎯 Objetivos de Aprendizagem

  • Entender que segurança deve ser pensada desde o início (Security by Design).
  • Conhecer a OWASP e os principais riscos.
  • Entender conceitos básicos: Autenticação vs. Autorização.
  • Aprender sobre injeção de código (SQL Injection).

📚 Conteúdo

1. Inseguro por padrão?

Muitos softwares nascem inseguros porque os devs pensam apenas na funcionalidade ("Tem que funcionar") e esquecem da segurança ("Tem que proteger"). - Security by Design: Pensar em segurança na fase de Design, não só no final.

2. A Tríade CIA

Os 3 pilares da segurança da informação: - Confidencialidade: Só quem deve ver, vê. (Senha, criptografia). - Integridade: O dado não foi alterado indevidamente. (Ninguém mudou o saldo do banco). - Disponibilidade (Availability): O sistema está no ar quando preciso.

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

  • Autenticação: Quem é você? (Login/Senha, Biometria).
  • Autorização: O que você pode fazer? (Admin pode apagar tudo, Usuário só vê seus dados).

4. OWASP Top 10

A OWASP (Open Web Application Security Project) lista as falhas mais comuns. A nº 1 clássica é a Injection (Injeção). - Exemplo: Um hacker escreve um comando de banco de dados no campo de login e o sistema executa, revelando senhas.

📅 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 (Planning Poker).
  • Saber priorizar tarefas (MoSCoW).

📚 Conteúdo

1. O Triângulo de Ferro

Em qualquer projeto, você tem três restrições conectadas: - Escopo (O que fazer). - Tempo (Prazo). - Custo (Dinheiro/Recursos).

Se você quiser mais escopo em menos tempo, o custo aumenta. Se reduzir o custo e o tempo, o escopo diminui. (E a Qualidade está no meio afetando tudo).

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

É a versão mais simples do produto que resolve o problema do usuário. - Não é: Um produto mal feito. - É: Uma bicicleta (funcional) em vez de uma roda de carro (inútil sozinha). - Construa o MVP -> Receba Feedback -> Melhore.

3. Estimativas Ágeis

Humanos são péssimos em estimar horas ("Levo 2 horas" -> Leva 2 dias). No Ágil, usamos Story Points (Pontos de História) baseados em complexidade relativa. - Planning Poker: O time usa cartas com a sequência de Fibonacci (1, 2, 3, 5, 8, 13) para votar na complexidade da tarefa.

4. Priorização (MoSCoW)

Como decidir o que fazer primeiro? - Must have: Tem que ter (Senão não funciona). - Should have: Deveria ter (Importante, mas pode esperar). - Could have: Poderia ter (Seria legal, se sobrar tempo). - Won't have: Não terá agora (Fica para o futuro).

📅 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 ferramentas como Markdown e Wikis.

📚 Conteúdo

1. "O código se documenta sozinho"? (Mentira!)

Um código limpo ajuda, mas ele não explica o PORQUÊ das decisões, nem como instalar o projeto. - Documentação é amor ao seu "eu" do futuro e aos colegas.

2. Tipos de Documentação

Para Usuário Final

  • Manuais, Tutoriais, FAQ.
  • Linguagem simples, sem jargão técnico.

Para Desenvolvedores (Técnica)

  • README: A capa do projeto. O que é? Como instala?
  • Wiki/Docs Internos: Arquitetura, padrões, decisões.
  • API Docs: Swagger/OpenAPI (como integrar).
  • Comentários no Código: Usar com moderação (explicar o porquê, não o o quê).

3. O Poder do Markdown

Markdown (o formato .md que estamos usando agora) é o padrão da indústria. Simples, legível e converte para HTML. - Títulos com # - Listas com - - Código com crases `

4. Como escrever um bom README

Um README deve responder em 5 segundos: 1. O que esse projeto faz? 2. Como eu rodo ele na minha máquina? 3. Quais tecnologias usa?

📅 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 Morre?

Diferente de uma ponte (que degrada sozinha com a chuva), o software só "estragar" se o ambiente mudar ou se tentarmos mudá-lo. - Lei de Lehman: Um software que é usado precisa evoluir, senão torna-se obsoleto.

2. Tipos de Manutenção

  • Corretiva: Consertar bugs (o "band-aid").
  • Adaptativa: Mudar para usar novo SO ou Banco de Dados (ex: migrar para Windows 11).
  • Perfeccionista (Evolutiva): Adicionar novas funcionalidades ou melhorar performance.
  • Preventiva (Refatoração): Melhorar a estrutura do código antes que quebre.

3. Refatoração (Refactoring)

É limpar a cozinha depois de cozinhar. Alterar a estrutura interna do código sem mudar seu comportamento externo. - Objetivo: Tornar o código mais fácil de entender e modificar. - Quando fazer? O tempo todo (regra do escoteiro: deixe o código mais limpo do que encontrou).

4. Dívida Técnica (Technical Debt)

Às vezes, fazemos o código "rápido e sujo" para entregar logo. Isso é um empréstimo. - O "juro" é a dificuldade extra de trabalhar nesse código depois. - Se não pagarmos a dívida (refatorando), o projeto pode falir (ficar impossível de manter).

📅 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 necessárias para o mercado.
  • Discutir o futuro da área (IA, Low-code).
  • Concluir o curso com o projeto final.

📚 Conteúdo

1. Grandes Poderes, Grandes Responsabilidades

Software controla aviões, bancos, hospitais e redes sociais. Um erro seu pode causar prejuízo financeiro ou até vidas. - Ética: Não criar software para prejudicar, espionar ou discriminar. Respeitar a privacidade dos dados (LGPD).

2. O Profissional "T-Shaped"

O mercado busca profissionais em forma de T: - Barra vertical: Profundidade em uma área (ex: Backend Python). - Barra horizontal: Conhecimento generalista em outras (Frontend, DevOps, Design). - Você não precisa saber tudo, mas precisa saber conversar com todos.

3. Soft Skills (Habilidades Comportamentais)

Saber programar é o básico. O que diferencia o Senior do Junior é: - Comunicação: Explicar problemas técnicos para não-técnicos. - Empatia: Entender a dor do usuário. - Resiliência: Aprender com o erro.

4. O Futuro: A IA vai roubar meu emprego?

Ferramentas de IA (como Copilot, ChatGPT) são copilotos. Elas aumentam a produtividade. - O engenheiro que usa IA substituirá o engenheiro que não usa. - O foco muda de "escrever sintaxe" para "resolver problemas complexos".

📅 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.