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

Plano de Ensino 🧭

Curso: Engenharia de Software para Iniciantes
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Engenharia de Software para Iniciantes.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Fundamentos da Engenharia de Software Teoria, Prática Guiada, Quiz e Exercícios
02 Processos de Software: Cascata e Ágil Teoria, Prática Guiada, Quiz e Exercícios
03 Metodologias Ágeis: Scrum e Kanban Teoria, Prática Guiada, Quiz e Exercícios
04 Requisitos de Software Teoria, Prática Guiada, Quiz e Exercícios
05 Modelagem de Sistemas e UML Teoria, Prática Guiada, Quiz e Exercícios
06 Arquitetura de Software Teoria, Prática Guiada, Quiz e Exercícios
07 Versionamento de Código (Git & GitHub) Teoria, Prática Guiada, Quiz e Exercícios
08 Design de Software e SOLID Teoria, Prática Guiada, Quiz e Exercícios
09 Qualidade de Software e QA Teoria, Prática Guiada, Quiz e Exercícios
10 Testes de Software Teoria, Prática Guiada, Quiz e Exercícios
11 DevOps e CI/CD Teoria, Prática Guiada, Quiz e Exercícios
12 Segurança de Software Teoria, Prática Guiada, Quiz e Exercícios
13 Gerenciamento de Projetos e Estimativas Teoria, Prática Guiada, Quiz e Exercícios
14 Documentação Técnica Teoria, Prática Guiada, Quiz e Exercícios
15 Manutenção e Evolução Teoria, Prática Guiada, Quiz e Exercícios
16 Carreira e Ética na Engenharia de Software Teoria, Prática Guiada, Quiz e Exercícios
17 Engenharia de Requisitos Avançada e Casos de Uso Teoria, Prática Guiada, Quiz e Exercícios
18 Arquitetura Orientada a Eventos (EDA) e Mensageria Teoria, Prática Guiada, Quiz e Exercícios
19 Estimativa de Esforço em Software e Métricas de Pontos de Função Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Documento de Arquitetura e Engenharia Completo Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Engenharia de Software para Iniciantes.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

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

📚 Módulos do Curso

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

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

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

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

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

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

Aula 17 - Engenharia de Requisitos Avançada e Casos de Uso 📝

Objetivo Pedagógico

Objetivo: Conceber e especificar requisitos de software complexos utilizando técnicas avançadas de elicitação, critérios INVEST para Histórias de Usuário, Casos de Uso detalhados e especificação por exemplos com Behavior-Driven Development (BDD / Gherkin).

📑 1. Fundamentos Teóricos & Análise Técnica

A maior causa de fracasso em projetos de software não reside em erros de codificação ou bugs de compilador, mas no desenvolvimento de funcionalidades que não atendem às necessidades reais dos usuários ou que foram especificadas de forma ambígua.

A Engenharia de Requisitos contemporânea estrutura-se sobre práticas rigorosas de elicitação e validação: 1. Requisitos Funcionais (RF) vs. Não-Funcionais (RNF): - Requisitos Funcionais: O que o sistema deve fazer (comportamento de negócio, cálculos, integrações). - Requisitos Não-Funcionais (Atributos de Qualidade): Como o sistema deve operar (latência de resposta em percentis, disponibilidade de 99.99%, escalabilidade, conformidade de acessibilidade e segurança). Devem ser obrigatoriamente mensuráveis através de métricas objetivas. 2. O Critério INVEST para Histórias de Usuário: - Independent: Historietas desacopladas que podem ser desenvolvidas em qualquer ordem. - Negotiable: Não é um contrato estático; representa o convite para uma conversa. - Valuable: Entrega valor tangível e perceptível para o usuário final. - Estimable: Clareza suficiente para permitir previsões de esforço. - Small: Pequena o suficiente para ser concluída em poucos dias de trabalho. - Testable: Possui critérios de aceitação objetivos e verificáveis. 3. Behavior-Driven Development (BDD / Gherkin): - Especificação de comportamentos através de exemplos concretos na sintaxe Dado que ... Quando ... Então ... (Given-When-Then), servindo simultaneamente como documentação viva compreensível por pessoas de negócio e suíte de testes automatizados executáveis.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Stakeholder["Usuário / Stakeholder"] --> Elicitation["Elicitação & Descoberta de Necessidades"]
    Elicitation --> Story["Histórias de Usuário (INVEST)"]
    Story --> BDD["Especificação com Exemplos BDD (Gherkin)"]
    BDD --> Acceptance["Critérios de Aceitação Automatizados (Cucumber / Playwright)"]
    Acceptance --> Code["Desenvolvimento TDD / Código de Produção"]
    Code --> TestPass["Testes Executáveis Validam Comportamento de Negócio!"]
    style Stakeholder fill:#e1f5fe,stroke:#01579b
    style Story fill:#fff3e0,stroke:#e65100
    style BDD fill:#f3e5f5,stroke:#7b1fa2
    style Acceptance fill:#e8f5e9,stroke:#2e7d32
    style TestPass fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de Ambiguidade: Especificações por exemplos eliminam interpretações divergentes entre engenharia e produto. - Critérios de Aceitação Automatizáveis: Cada cenário Gherkin é diretamente convertido em um teste funcional automatizado. - Rastreabilidade Bidirecional: Garantia de que todo teste unitário e de aceitação esteja mapeado a um requisito de negócio formal. - Foco no Comportamento do Usuário: Descrições centradas no valor gerado em vez de implementações técnicas de banco de dados.

🛠️ 2. Implementação Prática em Engenharia de Requisitos, Histórias de Usuário e BDD

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// checkout_regras.feature (Especificação BDD Executável em Gherkin)
# language: pt
Funcionalidade: Finalização de Compra com Validação de Crédito
  Como um cliente autenticado no portal
  Quero finalizar o checkout do meu carrinho de compras
  Para adquirir os produtos selecionados com entrega garantida

  Contexto:
    Dado que o usuário "carlos.silva@empresa.com" está autenticado no sistema
    E possui um carrinho com o produto "Notebook Pro 16" no valor de 8500.00
    E o endereço de entrega principal está selecionado

  Cenário: Compra aprovada com limite suficiente no cartão corporativo
    Dado que o cartão de crédito corporativo possui limite disponível de 10000.00
    Quando o usuário confirma o pagamento em 1 parcela
    Então o sistema deve autorizar a transação junto ao gateway bancário
    E o pedido deve ser gravado com status "PAGAMENTO_CONFIRMADO"
    E uma notificação de confirmação deve ser enviada para "carlos.silva@empresa.com"

  Cenário: Compra rejeitada por limite de crédito insuficiente
    Dado que o cartão de crédito corporativo possui limite disponível de 3000.00
    Quando o usuário tenta confirmar o pagamento
    Então o sistema deve recusar a operação com a mensagem "Limite de crédito insuficiente"
    E o pedido deve permanecer em estado "AGUARDANDO_PAGAMENTO"
    E nenhum valor deve ser debitado da conta do cliente

💡 Análise Passo a Passo do Código

  1. Uso da Sintaxe Padrão Gherkin: Especificação em linguagem natural estruturada que atua como documentação viva executável.
  2. Cenários de Sucesso e Exceção: Mapeamento explícito de caminhos felizes e tratamentos de recusa de transação.
  3. Testabilidade Absoluta: Permite que frameworks como Cucumber executem os passos diretamente contra o sistema.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Arquitetura Orientada a Eventos (EDA) e Mensageria ⚡

Objetivo Pedagógico

Objetivo: Conceber sistemas distribuídos altamente desacoplados e resilientes aplicando Arquitetura Orientada a Eventos (EDA), mensageria assíncrona (RabbitMQ vs Kafka), padrões Event Sourcing e CQRS (Command Query Responsibility Segregation).

📑 1. Fundamentos Teóricos & Análise Técnica

Sistemas construídos exclusivamente sobre chamadas síncronas ponto a ponto (HTTP/REST) criam acoplamento temporal rígido: se um serviço downstream falhar ou sofrer lentidão, toda a cadeia de chamadas cascata em lentidão e falhas generalizadas.

A Arquitetura Orientada a Eventos (Event-Driven Architecture - EDA) resolve esse acoplamento através do paradigma produtor-consumidor: 1. Eventos de Domínio e Assincronismo: - Um evento representa um fato imutável ocorrido no passado do negócio (PedidoCriado, PagamentoConfirmado). - O produtor publica o evento no broker de mensagens sem qualquer conhecimento sobre quem consumirá aquele evento ou quantos consumidores existem. 2. RabbitMQ (Message Broker Tradicional) vs. Apache Kafka (Event Streaming Platform): - RabbitMQ: Focado em roteamento sofisticado de mensagens (Exchange direct, topic, fanout), confirmações individuais (ACK) e descarte da mensagem após o consumo. Ideal para filas transacionais de tarefas e comandos. - Apache Kafka: Log de eventos distribuído, append-only e persistente em disco particionado. Múltiplos consumidores independentes leem o log em suas próprias velocidades através de seus próprios ponteiros (Offsets). Permite reprocessamento histórico (Event Replay). 3. Padrões Avançados: CQRS e Event Sourcing: - CQRS: Separa os modelos de gravação (Comandos que alteram estado) dos modelos de leitura (Consultas altamente otimizadas e desnormalizadas). - Event Sourcing: O estado da aplicação não é gravado como uma linha mutável de banco de dados, mas reconstruído pelo somatório histórico de todos os eventos que já ocorreram na vida do sistema.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph LR
    Produtor["Serviço de Checkout (Order Service)"] -->|Publica PedidoCriado| Kafka["Broker Kafka: Tópico 'orders.events'"]
    Kafka -->|Consumo Assíncrono Partição 0| Estoque["Serviço de Estoque (Separação)"]
    Kafka -->|Consumo Assíncrono Partição 0| Faturamento["Serviço Fiscal (Nota Fiscal)"]
    Kafka -->|Consumo Assíncrono Partição 0| Notificacao["Serviço de Push / E-mail"]
    Note["Desacoplamento Temporal: Se o Fiscal cair, Checkout continua funcionando normalmente!"]
    style Produtor fill:#e1f5fe,stroke:#01579b
    style Kafka fill:#fff3e0,stroke:#e65100
    style Estoque fill:#f3e5f5,stroke:#7b1fa2
    style Faturamento fill:#ffebee,stroke:#c62828
    style Notificacao fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Desacoplamento Temporal e Espacial: Produtores e consumidores operam em momentos e servidores completamente independentes. - Garantias de Entrega (At-least-once / Exactly-once): Configuração rigorosa de confirmações para evitar perda ou duplicação de eventos críticos. - Padrão Outbox Transacional: Gravação atômica da alteração no banco de dados local conjuntamente com a tabela de saída de eventos para evitar inconsistência distribuída. - Escalabilidade Horizontal por Partições: Distribuição paralela de carga do Kafka permitindo milhões de eventos por segundo.

🛠️ 2. Implementação Prática em Arquitetura Orientada a Eventos, Kafka e RabbitMQ

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// order_event_publisher.ts (Publicação Confiável de Eventos com KafkaJS)
import { Kafka, Partitioners } from 'kafkajs';

const kafka = new Kafka({
  clientId: 'order-service',
  brokers: ['kafka-broker-1:9092', 'kafka-broker-2:9092'],
});

const producer = kafka.producer({
  createPartitioner: Partitioners.DefaultPartitioner,
  idempotent: true, // Garante entrega exatamente-uma-vez sem duplicações
});

interface OrderCreatedEvent {
  orderId: string;
  customerId: string;
  totalAmount: number;
  timestamp: string;
}

export async function publishOrderCreated(event: OrderCreatedEvent) {
  await producer.connect();

  await producer.send({
    topic: 'orders.events',
    messages: [
      {
        key: event.customerId, // Garante que eventos do mesmo cliente caiam na mesma partição!
        value: JSON.stringify(event),
        headers: {
          'event-type': 'OrderCreated',
          'source-app': 'ecommerce-checkout',
        },
      },
    ],
  });

  console.log(`[EVENT PUBLISHED] Evento do Pedido ${event.orderId} emitido com sucesso.`);
}

💡 Análise Passo a Passo do Código

  1. Uso de Chave de Particionamento (key: event.customerId): Garante que todos os eventos do mesmo cliente sejam processados estritamente em ordem na mesma partição do Kafka.
  2. Configuração idempotent: true: Habilita garantias nativas no broker para evitar duplicações causadas por retentativas de rede.
  3. Metadados em Headers: Permite que roteadores e filtros downstream inspecionem o tipo de evento sem deserializar todo o payload.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Estimativa de Esforço em Software e Métricas de Pontos de Função 📐

Objetivo Pedagógico

Objetivo: Aplicar métodos científicos de medição e estimativa de software utilizando Análise de Pontos de Função (APF - IFPUG), Funções de Dados (ALI/AIE), Funções de Transação (EE/SE/CE) e modelos empíricos como COCOMO II.

📑 1. Fundamentos Teóricos & Análise Técnica

Estimar projetos de software utilizando linhas de código (LOC) é falho e distorcido, pois linguagens modernas exigem muito menos linhas que linguagens legadas para expressar a mesma funcionalidade de negócio.

A Análise de Pontos de Função (APF), normatizada pela ISO/IEC 20926 e mantida pelo IFPUG (International Function Point Users Group), mede o software a partir da perspectiva do usuário, mensurando o tamanho funcional de forma independente da tecnologia: 1. Funções de Dados (Armazenamento Lógico): - Arquivo Lógico Interno (ALI): Grupo de dados logicamente relacionados mantido internamente dentro da fronteira da aplicação (ex: tabelas de banco de dados gerenciadas). - Arquivo de Interface Externa (AIE): Dados referenciados pelo sistema, mas cuja manutenção reside em outra aplicação externa (ex: consulta a API de CEP dos Correios ou catálogo do ERP corporativo). 2. Funções de Transação (Processamento Dinâmico): - Entrada Externa (EE): Processo elementar que processa dados provenientes de fora da fronteira e atualiza um ALI (ex: cadastrar cliente, alterar pedido). - Saída Externa (SE): Processo elementar que envia dados para fora da fronteira e contém lógica de processamento matemático, relatórios sumarizados ou cálculos derivados. - Consulta Externa (CE): Processo elementar que envia dados para fora sem realizar cálculos ou alterar o estado do sistema (ex: listagem simples de clientes com filtro). 3. Complexidade Funcional e Cálculo Final: - Cada função é classificada em Baixa, Média ou Alta complexidade com base na quantidade de Tipos de Dados (TD) e Tipos de Registro (TR). A soma ponderada resulta no total de Pontos de Função Não Ajustados (PFNA).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    User["Requisitos Funcionais do Usuário"] --> APF["Análise de Pontos de Função (IFPUG)"]
    APF --> Data["Funções de Dados: ALIs (Internos) e AIEs (Externos)"]
    APF --> Trans["Funções de Transação: EEs (Entradas), SEs (Saídas), CEs (Consultas)"]
    Data & Trans --> Matrix["Matriz de Complexidade (TDs e TRs)"]
    Matrix --> TotalPF["Total de Pontos de Função (Tamanho Funcional)"]
    TotalPF --> Estima["Estimativa de Prazo e Custo (Produtividade: Horas/PF)"]
    style User fill:#e1f5fe,stroke:#01579b
    style APF fill:#fff3e0,stroke:#e65100
    style Data fill:#f3e5f5,stroke:#7b1fa2
    style Trans fill:#f3e5f5,stroke:#7b1fa2
    style TotalPF fill:#e8f5e9,stroke:#2e7d32
    style Estima fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Independência Tecnológica: Um sistema de compras terá exatamente os mesmos Pontos de Função quer seja escrito em Java, Python, Go ou C#. - Normalização de Produtividade: Permite comparar com precisão a produtividade de diferentes equipes através da métrica Horas gastas por Ponto de Função. - Estimativa Precoce de Projetos: Capacidade de dimensionar cronogramas e custos ainda na fase de especificação de requisitos. - Norma Internacional ISO/IEC 20926: Adoção de padrão reconhecido mundialmente e exigido em licitações públicas e contratos corporativos.

🛠️ 2. Implementação Prática em Engenharia de Software, Métricas de Tamanho e Análise de Pontos de Função (APF)

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// function_points_calculator.py (Calculadora de Pontos de Função Não Ajustados)
def calculate_function_points():
    """Calcula Pontos de Função segundo a tabela de pesos IFPUG."""
    # Matriz de pesos [Baixa, Média, Alta]
    WEIGHTS = {
        "ALI": [7, 10, 15],
        "AIE": [5, 7, 10],
        "EE":  [3, 4, 6],
        "SE":  [4, 5, 7],
        "CE":  [3, 4, 6]
    }

    # Inventário Funcional do Sistema de E-Commerce
    inventory = {
        "ALI": {"baixa": 2, "media": 3, "alta": 1}, # Tabelas de Usuários, Pedidos, Produtos...
        "AIE": {"baixa": 1, "media": 1, "alta": 0}, # Gateway de Pagamento, ERP Fiscal
        "EE":  {"baixa": 5, "media": 4, "alta": 2}, # Cadastros e Mutações
        "SE":  {"baixa": 3, "media": 2, "alta": 1}, # Relatórios Analíticos com Cálculos
        "CE":  {"baixa": 6, "media": 3, "alta": 0}  # Listagens e Consultas Simples
    }

    total_pf = 0
    print("=== Apuração de Pontos de Função (IFPUG) ===")
    for func_type, counts in inventory.items():
        w = WEIGHTS[func_type]
        subtotal = (counts["baixa"] * w[0]) + (counts["media"] * w[1]) + (counts["alta"] * w[2])
        total_pf += subtotal
        print(f"{func_type:4} -> Baixas: {counts['baixa']} | Médias: {counts['media']} | Altas: {counts['alta']} | Subtotal: {subtotal:3d} PF")

    print("-" * 50)
    print(f"Total de Pontos de Função Não Ajustados: {total_pf} PF")

    # Estimativa de esforço assumindo taxa média da indústria de 10 horas/PF
    taxa_produtividade = 10 # Horas por PF
    esforco_total_horas = total_pf * taxa_produtividade
    print(f"Esforço Estimado de Engenharia         : {esforco_total_horas} horas")
    print(f"Prazo para Equipe de 4 Engenheiros     : {esforco_total_horas / (4 * 140):.1f} meses")

if __name__ == '__main__':
    calculate_function_points()

💡 Análise Passo a Passo do Código

  1. Tabela de Pesos Padrão IFPUG: Aplica multiplicadores formais consagrados internacionalmente para cada tipo de componente.
  2. Classificação por Complexidade: Pondera o esforço real considerando se a tela ou tabela possui dezenas de campos ou poucos atributos.
  3. Conversão em Prazos Reais: Transforma pontos abstratos de software em horas e meses de trabalho baseados na velocidade histórica da equipe.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀

Objetivo Pedagógico

Objetivo: Conceber e consolidar o Software Architecture Document (SAD) integral de um ecossistema corporativo distribuído: especificação de requisitos não-funcionais (SLOs/SLAs), diagramação arquitetural completa no C4 Model, matriz de rastreabilidade e estratégias de observabilidade.

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de Engenharia de Software coroa a formação técnica e metodológica através da construção de um documento canônico de arquitetura (SAD): 1. Estrutura Canônica de um SAD Enterprise: - Declaração de Objetivos de Negócio e Contexto de Mercado. - Atributos de Qualidade (Disponibilidade, Latência, Segurança, Manutenibilidade). - Visão Arquitetural em Camadas e Padrões Estruturantes adotados. 2. O C4 Model como Linguagem Arquitetural Universal: - Nível 1: Contexto: Os sistemas e os atores humanos no ecossistema global. - Nível 2: Containers: Aplicações executáveis, serviços, bancos de dados e gateways. - Nível 3: Componentes: A organização interna de cada microsserviço ou container. - Nível 4: Código: Detalhamento em classes UML dos elementos mais críticos. 3. Matriz de Decisões e ADRs (Architectural Decision Records): - Registro formal do contexto, opções consideradas e justificativa técnica para as escolhas definitivas de engenharia.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    SAD["Documento Canônico de Arquitetura (SAD Enterprise)"] --> Context["C4 Nível 1: Contexto Sistêmico"]
    Context --> Containers["C4 Nível 2: Containers e Bancos"]
    Containers --> Components["C4 Nível 3: Componentes e Interfaces"]
    SAD --> Quality["Requisitos Não-Funcionais Mensuráveis (SLA / SLO)"]
    SAD --> ADR["Decisões Arquiteturais Justificadas (ADR 001..N)"]
    style SAD fill:#e1f5fe,stroke:#01579b
    style Context fill:#fff3e0,stroke:#e65100
    style Containers fill:#f3e5f5,stroke:#7b1fa2
    style Quality fill:#e8f5e9,stroke:#2e7d32
    style ADR fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Rigor e Completude Arquitetural: Cobertura holística que alinha expectativas de clientes, diretores, desenvolvedores e operadores. - Rastreabilidade Fim a Fim: Demonstração clara de como cada escolha de infraestrutura satisfaz diretamente um requisito de negócio. - Preservação da Memória Técnica (ADRs): Garantia de que as razões de decisões arquiteturais históricas permaneçam compreensíveis para futuras equipes. - Excelência na Engenharia de Software: Materialização dos mais avançados padrões de confiabilidade, modularidade e manutenibilidade.

🛠️ 2. Implementação Prática em Engenharia de Software Corporativa, SAD e C4 Model

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// adr_template_microservices.md (Exemplo de Registro de Decisão Arquitetural - ADR)
# ADR 007: Adoção de Kafka para Comunicação Assíncrona de Pedidos

## Status
Aprovado (2026-09-05)

## Contexto
O aumento do tráfego do portal gerou lentidão crítica na finalização de compras devido a chamadas HTTP síncronas em cadeia para emissão fiscal, separação de estoque e disparo de e-mails. Quando o serviço fiscal apresenta instabilidade, as compras de clientes travam.

## Decisão
Decidimos adotar o **Apache Kafka** como espinha dorsal de mensageria assíncrona para todos os eventos de pedidos (`OrderCreated`, `OrderPaid`, `OrderCancelled`).
- O serviço de checkout publicará eventos no tópico `orders.events`.
- Todos os serviços downstream consumirão os eventos em seus próprios ritmos.

## Consequências
### Positivas
- **Desacoplamento Temporal**: A indisponibilidade de serviços terceiros não afeta a captura de novas vendas.
- **Performance**: Tempo de resposta do checkout reduzido de 1200ms para 45ms.
- **Auditoria Histórica**: O log imutável do Kafka permite reprocessar eventos do passado caso ocorram erros de faturamento.

### Negativas
- Necessidade de gerenciar a complexidade de um cluster Kafka e tópicos particionados.
- A consistência de dados passa a ser eventual (*Eventual Consistency*).

💡 Análise Passo a Passo do Código

  1. Registro Estruturado de Contexto: Documenta com números reais o problema técnico que motivou a intervenção arquitetural.
  2. Transparência nas Consequências Negativas: Reconhece os trade-offs e novas responsabilidades operacionais assumidas pela equipe.
  3. Imutabilidade da Decisão: Cria histórico auditável e imutável que orienta o crescimento da engenharia.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Identificação de Fases **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos da Engenharia de Software**, o conceito abordado (Identificação de Fases) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Cenário de Erro **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos da Engenharia de Software**, o conceito abordado (Cenário de Erro) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Debate **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos da Engenharia de Software**, o conceito abordado (Debate) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Estudo de Caso **Resposta Comentada:** - **Fundamentação:** No contexto de **Processos de Software: Cascata e Ágil**, o conceito abordado (Estudo de Caso) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Comparação **Resposta Comentada:** - **Fundamentação:** No contexto de **Processos de Software: Cascata e Ágil**, o conceito abordado (Comparação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Reflexão **Resposta Comentada:** - **Fundamentação:** No contexto de **Processos de Software: Cascata e Ágil**, o conceito abordado (Reflexão) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Simulação de Daily **Resposta Comentada:** - **Fundamentação:** No contexto de **Metodologias Ágeis: Scrum e Kanban**, o conceito abordado (Simulação de Daily) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Quadro Kanban **Resposta Comentada:** - **Fundamentação:** No contexto de **Metodologias Ágeis: Scrum e Kanban**, o conceito abordado (Quadro Kanban) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Papéis **Resposta Comentada:** - **Fundamentação:** No contexto de **Metodologias Ágeis: Scrum e Kanban**, o conceito abordado (Papéis) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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?)

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Classificação **Resposta Comentada:** - **Fundamentação:** No contexto de **Requisitos de Software**, o conceito abordado (Classificação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Escrita de User Story **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escrita de User Story
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Requisitos de Software**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Critérios de Aceite **Resposta Comentada:** - **Fundamentação:** No contexto de **Requisitos de Software**, o conceito abordado (Critérios de Aceite) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Observação **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Observação
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Modelagem de Sistemas e UML**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Caso de Uso **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de Sistemas e UML**, o conceito abordado (Caso de Uso) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Leitura **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Leitura
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Modelagem de Sistemas e UML**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

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?).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Análise de App **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Software**, o conceito abordado (Análise de App) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Desenho **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Desenho
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Arquitetura de Software**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Reflexão **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Software**, o conceito abordado (Reflexão) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Analogia **Resposta Comentada:** - **Fundamentação:** No contexto de **Versionamento de Código (Git & GitHub)**, o conceito abordado (Analogia) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Cenário **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Cenário
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Versionamento de Código (Git & GitHub)**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Fluxo **Resposta Comentada:** - **Fundamentação:** No contexto de **Versionamento de Código (Git & GitHub)**, o conceito abordado (Fluxo) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Refatoração (Teórica) **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Refatoração (Teórica)
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Design de Software e SOLID**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Identificando DRY **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Identificando DRY
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Design de Software e SOLID**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Monstro de Espaguete **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Monstro de Espaguete
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Design de Software e SOLID**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Classificação **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Classificação
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Qualidade de Software e QA**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Debate **Resposta Comentada:** - **Fundamentação:** No contexto de **Qualidade de Software e QA**, o conceito abordado (Debate) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: QA vs Teste **Resolução e Implementação:** 
// Estrutura de implementação recomendada para QA vs Teste
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Qualidade de Software e QA**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

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

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Escrevendo Testes (Papel) **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escrevendo Testes (Papel)
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Testes de Software**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Classificação **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes de Software**, o conceito abordado (Classificação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Reflexão TDD **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Reflexão TDD
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Testes de Software**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

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

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Desenho **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Desenho
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **DevOps e CI/CD**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Cenário **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Cenário
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **DevOps e CI/CD**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Pesquisa **Resposta Comentada:** - **Fundamentação:** No contexto de **DevOps e CI/CD**, o conceito abordado (Pesquisa) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Cenário de Ataque **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança de Software**, o conceito abordado (Cenário de Ataque) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Engenharia Social **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança de Software**, o conceito abordado (Engenharia Social) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Senha Fraca **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança de Software**, o conceito abordado (Senha Fraca) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: MoSCoW na Prática **Resposta Comentada:** - **Fundamentação:** No contexto de **Gerenciamento de Projetos e Estimativas**, o conceito abordado (MoSCoW na Prática) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: MVP **Resposta Comentada:** - **Fundamentação:** No contexto de **Gerenciamento de Projetos e Estimativas**, o conceito abordado (MVP) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Triângulo **Resposta Comentada:** - **Fundamentação:** No contexto de **Gerenciamento de Projetos e Estimativas**, o conceito abordado (Triângulo) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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;

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Refatorando README **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Refatorando README
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Documentação Técnica**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Markdown na Veia **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Markdown na Veia
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Documentação Técnica**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Comentários **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação Técnica**, o conceito abordado (Comentários) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Metáfora **Resposta Comentada:** - **Fundamentação:** No contexto de **Manutenção e Evolução**, o conceito abordado (Metáfora) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Identificando Oportunidade **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Identificando Oportunidade
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Manutenção e Evolução**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Decisão **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Decisão
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Manutenção e Evolução**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

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.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Dilema Ético **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Dilema Ético
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Carreira e Ética na Engenharia de Software**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Autoavaliação **Resposta Comentada:** - **Fundamentação:** No contexto de **Carreira e Ética na Engenharia de Software**, o conceito abordado (Autoavaliação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Portfólio **Resposta Comentada:** - **Fundamentação:** No contexto de **Carreira e Ética na Engenharia de Software**, o conceito abordado (Portfólio) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

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.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Fundamentos da Engenharia de Software

  1. Qual é o conceito fundamental e objetivo principal de Fundamentos da Engenharia de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fundamentos da Engenharia de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fundamentos da Engenharia de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fundamentos da Engenharia de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fundamentos da Engenharia de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fundamentos da Engenharia de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fundamentos da Engenharia de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fundamentos da Engenharia de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fundamentos da Engenharia de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fundamentos da Engenharia de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Processos de Software: Cascata e Ágil

  1. Qual é o conceito fundamental e objetivo principal de Processos de Software: Cascata e Ágil?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Processos de Software: Cascata e Ágil?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Processos de Software: Cascata e Ágil, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Processos de Software: Cascata e Ágil?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Processos de Software: Cascata e Ágil atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Processos de Software: Cascata e Ágil, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Processos de Software: Cascata e Ágil?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Processos de Software: Cascata e Ágil estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Processos de Software: Cascata e Ágil com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Processos de Software: Cascata e Ágil deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Metodologias Ágeis: Scrum e Kanban

  1. Qual é o conceito fundamental e objetivo principal de Metodologias Ágeis: Scrum e Kanban?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Metodologias Ágeis: Scrum e Kanban?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Metodologias Ágeis: Scrum e Kanban, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Metodologias Ágeis: Scrum e Kanban?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Metodologias Ágeis: Scrum e Kanban atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Metodologias Ágeis: Scrum e Kanban, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Metodologias Ágeis: Scrum e Kanban?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Metodologias Ágeis: Scrum e Kanban estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Metodologias Ágeis: Scrum e Kanban com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Metodologias Ágeis: Scrum e Kanban deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Requisitos de Software

  1. Qual é o conceito fundamental e objetivo principal de Requisitos de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Requisitos de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Requisitos de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Requisitos de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Requisitos de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Requisitos de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Requisitos de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Requisitos de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Requisitos de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Requisitos de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Modelagem de Sistemas e UML

  1. Qual é o conceito fundamental e objetivo principal de Modelagem de Sistemas e UML?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Modelagem de Sistemas e UML?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Modelagem de Sistemas e UML, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Modelagem de Sistemas e UML?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Modelagem de Sistemas e UML atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Modelagem de Sistemas e UML, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Modelagem de Sistemas e UML?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Modelagem de Sistemas e UML estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Modelagem de Sistemas e UML com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Modelagem de Sistemas e UML deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Arquitetura de Software

  1. Qual é o conceito fundamental e objetivo principal de Arquitetura de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Arquitetura de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Arquitetura de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Arquitetura de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Arquitetura de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Arquitetura de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Arquitetura de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Arquitetura de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Arquitetura de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Arquitetura de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

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

  1. Qual é o conceito fundamental e objetivo principal de Versionamento de Código (Git & GitHub)?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Versionamento de Código (Git & GitHub)?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Versionamento de Código (Git & GitHub), assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Versionamento de Código (Git & GitHub)?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Versionamento de Código (Git & GitHub) atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Versionamento de Código (Git & GitHub), o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Versionamento de Código (Git & GitHub)?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Versionamento de Código (Git & GitHub) estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Versionamento de Código (Git & GitHub) com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Versionamento de Código (Git & GitHub) deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Design de Software e SOLID

  1. Qual é o conceito fundamental e objetivo principal de Design de Software e SOLID?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Design de Software e SOLID?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Design de Software e SOLID, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Design de Software e SOLID?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Design de Software e SOLID atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Design de Software e SOLID, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Design de Software e SOLID?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Design de Software e SOLID estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Design de Software e SOLID com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Design de Software e SOLID deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Qualidade de Software e QA

  1. Qual é o conceito fundamental e objetivo principal de Qualidade de Software e QA?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Qualidade de Software e QA?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Qualidade de Software e QA, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Qualidade de Software e QA?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Qualidade de Software e QA atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Qualidade de Software e QA, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Qualidade de Software e QA?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Qualidade de Software e QA estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Qualidade de Software e QA com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Qualidade de Software e QA deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Testes de Software

  1. Qual é o conceito fundamental e objetivo principal de Testes de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – DevOps e CI/CD

  1. Qual é o conceito fundamental e objetivo principal de DevOps e CI/CD?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de DevOps e CI/CD?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em DevOps e CI/CD, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em DevOps e CI/CD?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de DevOps e CI/CD atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em DevOps e CI/CD, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em DevOps e CI/CD?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a DevOps e CI/CD estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar DevOps e CI/CD com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a DevOps e CI/CD deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Segurança de Software

  1. Qual é o conceito fundamental e objetivo principal de Segurança de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Segurança de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Segurança de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Segurança de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Segurança de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Segurança de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Segurança de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Segurança de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Segurança de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Segurança de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Gerenciamento de Projetos e Estimativas

  1. Qual é o conceito fundamental e objetivo principal de Gerenciamento de Projetos e Estimativas?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Gerenciamento de Projetos e Estimativas?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Gerenciamento de Projetos e Estimativas, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Gerenciamento de Projetos e Estimativas?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Gerenciamento de Projetos e Estimativas atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Gerenciamento de Projetos e Estimativas, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Gerenciamento de Projetos e Estimativas?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Gerenciamento de Projetos e Estimativas estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Gerenciamento de Projetos e Estimativas com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Gerenciamento de Projetos e Estimativas deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Documentação Técnica

  1. Qual é o conceito fundamental e objetivo principal de Documentação Técnica?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Documentação Técnica?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Documentação Técnica, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Documentação Técnica?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Documentação Técnica atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Documentação Técnica, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Documentação Técnica?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Documentação Técnica estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Documentação Técnica com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Documentação Técnica deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Manutenção e Evolução

  1. Qual é o conceito fundamental e objetivo principal de Manutenção e Evolução?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Manutenção e Evolução?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Manutenção e Evolução, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Manutenção e Evolução?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Manutenção e Evolução atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Manutenção e Evolução, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Manutenção e Evolução?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Manutenção e Evolução estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Manutenção e Evolução com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Manutenção e Evolução deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Carreira e Ética na Engenharia de Software

  1. Qual é o conceito fundamental e objetivo principal de Carreira e Ética na Engenharia de Software?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Carreira e Ética na Engenharia de Software?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Carreira e Ética na Engenharia de Software, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Carreira e Ética na Engenharia de Software?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Carreira e Ética na Engenharia de Software atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Carreira e Ética na Engenharia de Software, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Carreira e Ética na Engenharia de Software?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Carreira e Ética na Engenharia de Software estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Carreira e Ética na Engenharia de Software com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Carreira e Ética na Engenharia de Software deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Engenharia de Requisitos Avançada e Casos de Uso 🚀

  1. Qual o propósito principal de Engenharia de Requisitos Avançada e Casos de Uso 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Engenharia de Requisitos Avançada e Casos de Uso 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Engenharia de Requisitos Avançada e Casos de Uso 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Engenharia de Requisitos Avançada e Casos de Uso 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Engenharia de Requisitos Avançada e Casos de Uso 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Engenharia de Requisitos Avançada e Casos de Uso 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Engenharia de Requisitos Avançada e Casos de Uso 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Engenharia de Requisitos Avançada e Casos de Uso 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Engenharia de Requisitos Avançada e Casos de Uso 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Engenharia de Requisitos Avançada e Casos de Uso 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀

  1. Qual o propósito principal de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Arquitetura Orientada a Eventos (EDA) e Mensageria 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀

  1. Qual o propósito principal de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Estimativa de Esforço em Software e Métricas de Pontos de Função 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀

  1. Qual o propósito principal de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Documento de Arquitetura e Engenharia Completo 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

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.

Sobre

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?

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.

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

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