Preparatório Caixa TI: Engenharia de Software e ciclo de vida de desenvolvimento

Engenharia de Software no contexto de prova

Engenharia de Software organiza o desenvolvimento de sistemas por meio de processos, papéis e artefatos (documentos/itens produzidos). Em provas, o foco costuma ser: identificar artefatos corretos para cada fase, entender requisitos e priorização, reconhecer diagramas UML essenciais e relacionar tipos de teste e qualidade ao ciclo de vida.

Ciclo de vida e processos (visão prática)

Um ciclo de vida descreve como o trabalho evolui de ideia para software em produção e manutenção. Modelos comuns (cascata, incremental, iterativo/ágil) mudam a forma de planejar e entregar, mas preservam atividades essenciais: levantar requisitos, projetar, implementar, testar, entregar e evoluir.

• Planejamento e requisitos: entender o problema, restrições e critérios de sucesso.
• Análise e modelagem: representar comportamento e estrutura (ex.: casos de uso, classes).
• Implementação: codificar conforme padrões e arquitetura definida.
• Testes: verificar e validar em diferentes níveis.
• Entrega e operação: disponibilizar com controle de versão, automação e monitoramento.
• Manutenção: corrigir defeitos, adaptar e evoluir funcionalidades.

Artefatos de requisitos: funcionais, não funcionais e regras

Requisitos Funcionais (RF)

Descrevem o que o sistema deve fazer (serviços, comportamentos, cálculos, fluxos). São observáveis do ponto de vista do usuário ou de sistemas integrados.

• Ex.: “Permitir que o cliente consulte o saldo da conta.”
• Ex.: “Gerar comprovante de pagamento com data, valor e identificador.”

Requisitos Não Funcionais (RNF)

Descrevem como o sistema deve se comportar (qualidade, restrições, padrões, desempenho, disponibilidade, usabilidade, conformidade). Em prova, é comum confundir RNF com RF: RNF não descreve uma funcionalidade, mas uma característica/limite.

• Desempenho: “Responder em até 2 segundos para 95% das consultas.”
• Disponibilidade: “Disponibilidade mensal de 99,9%.”
• Segurança (como qualidade): “Bloquear conta após 5 tentativas inválidas.”
• Conformidade: “Registrar trilha de auditoria para operações críticas.”
• Compatibilidade: “Suportar navegadores X e Y.”

Regras de negócio

São políticas/condições do domínio que podem impactar RF e RNF. Muitas vezes aparecem como validações ou restrições.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Ex.: “Transferências acima de R$ 10.000 exigem autenticação adicional.”

Passo a passo prático: escrever requisitos melhores

• 1) Use linguagem verificável: evite “rápido”, “fácil”, “intuitivo” sem métrica.
• 2) Separe RF de RNF: RF descreve ação/serviço; RNF descreve qualidade/limite.
• 3) Inclua contexto e exceções: o que acontece em erro, indisponibilidade, dados inválidos.
• 4) Defina critérios de aceitação: como provar que o requisito foi atendido.
• 5) Garanta rastreabilidade: cada requisito deve se ligar a casos de uso/histórias, testes e entregas.

Casos de uso e histórias de usuário

Casos de uso (UML)

Um caso de uso descreve uma interação entre ator (usuário ou sistema externo) e o sistema para atingir um objetivo. Em prova, é comum cobrar: ator vs caso de uso, fronteira do sistema, relações include/extend e generalização.

• Ator: entidade externa que interage com o sistema (ex.: “Cliente”, “Sistema de Pagamentos”).
• Caso de uso: objetivo (ex.: “Realizar Pagamento”).
• Fronteira do sistema: o que está dentro do sistema vs fora.

Include (inclusão): comportamento obrigatório e reutilizável (sempre ocorre). Extend (extensão): comportamento opcional/condicional (ocorre sob condição).

• Ex. include: “Realizar Pagamento” inclui “Validar Dados do Pagamento”.
• Ex. extend: “Realizar Pagamento” estende “Aplicar Desconto” quando há cupom válido.

Histórias de usuário (ágeis)

História é uma descrição curta de valor para o usuário, frequentemente no formato: “Como [persona], quero [objetivo] para [benefício]”. Ela é detalhada por critérios de aceitação e pode ser quebrada em tarefas técnicas.

• Ex.: “Como cliente, quero agendar transferência para não esquecer pagamentos.”

Critérios de aceitação

São condições objetivas para considerar a história/requisito pronto. Podem ser escritos em linguagem natural ou no estilo BDD (Dado/Quando/Então).

Dado que o cliente está autenticado e possui saldo suficiente
Quando ele agenda uma transferência para uma data futura
Então o sistema deve registrar o agendamento e exibir confirmação com identificador

Priorização: o que entra primeiro

Priorização decide a ordem de entrega com base em valor, risco, dependências e esforço. Em provas, aparecem técnicas e critérios.

Técnicas comuns

• MoSCoW: Must (deve), Should (deveria), Could (poderia), Won’t (não agora).
• Valor x Esforço: matriz para identificar “ganhos rápidos” (alto valor, baixo esforço).
• Risco primeiro: atacar itens de maior incerteza cedo para reduzir retrabalho.

Passo a passo prático: priorizar um backlog pequeno

• 1) Liste itens (histórias/casos de uso): ex.: autenticação, consulta de saldo, pagamento, comprovante.
• 2) Atribua valor: impacto no usuário/negócio (alto/médio/baixo).
• 3) Estime esforço: relativo (pontos) ou categorias (P/M/G).
• 4) Identifique dependências: ex.: “Emitir comprovante” depende de “Realizar pagamento”.
• 5) Ordene: maximize valor cedo e reduza risco, respeitando dependências.
• 6) Defina pronto (DoD) e critérios de aceitação: para evitar “feito pela metade”.

Modelagem básica (UML essencial) para leitura em prova

O objetivo aqui é reconhecer elementos e interpretar o que o diagrama comunica. Em questões, geralmente pedem: identificar tipo de diagrama, significado de setas/relacionamentos e coerência com o cenário.

Diagrama de Casos de Uso

Mostra atores, casos de uso e relações (include/extend/generalização). Dicas de leitura:

• Se há muitos detalhes de passos, isso não é o diagrama; é a especificação textual do caso de uso.
• Ator não é “tela” nem “módulo interno”; é externo ao sistema.
• Include = obrigatório; Extend = opcional/condicional.

Diagrama de Classes (estrutura)

Mostra classes, atributos, operações e relacionamentos. Elementos cobrados:

• Associação: relação estrutural (ex.: Cliente — Conta).
• Multiplicidade: 1, 0..1, 1..*, 0..* (quantidade de instâncias relacionadas).
• Agregação: relação todo-parte fraca (parte pode existir sem o todo).
• Composição: todo-parte forte (parte depende do todo para existir).
• Generalização (herança): “é um” (ex.: ContaPoupanca é uma Conta).

Exemplo de leitura (conceitual):
Cliente 1 ---- 0..* Conta
Interpretação: um cliente pode ter zero ou muitas contas; cada conta pertence a um cliente.

Diagrama de Sequência (comportamento no tempo)

Mostra a troca de mensagens entre objetos/atores ao longo do tempo (de cima para baixo). O que observar:

• Lifelines: participantes (ator, objeto, serviço).
• Mensagens: chamadas (sincronas/assíncronas) e retornos.
• Fragmentos: alt/opt/loop para condições e repetição.

Exemplo de interpretação:
Cliente -> App: solicitarPagamento()
App -> ServiçoPagamentos: validar()
ServiçoPagamentos -> Banco: debitar()
Banco -> ServiçoPagamentos: OK
ServiçoPagamentos -> App: confirmado(id)
App -> Cliente: exibirComprovante(id)

Testes: níveis, objetivos e armadilhas de prova

Verificação vs validação

• Verificação: “estamos construindo o produto corretamente?” (conforme especificação).
• Validação: “estamos construindo o produto certo?” (atende necessidade do usuário).

Tipos de teste (níveis)

• Teste unitário: valida a menor unidade testável (função/método/classe) isoladamente, com uso de dublês (mocks/stubs) quando necessário.
• Teste de integração: verifica a interação entre módulos/componentes (ex.: serviço + repositório + API externa simulada).
• Teste de sistema: avalia o sistema como um todo, próximo do ambiente real, cobrindo fluxos ponta a ponta.
• Teste de regressão: reexecuta testes após mudanças para garantir que funcionalidades existentes não quebraram.

Passo a passo prático: mapear testes a partir de um requisito

Requisito: “Ao realizar pagamento, o sistema deve gerar comprovante com identificador único.”

• 1) Critérios de aceitação: comprovante contém id, data/hora, valor, favorecido; id não se repete.
• 2) Testes unitários: gerarIdentificador() retorna formato esperado; validações de campos obrigatórios.
• 3) Testes de integração: serviço de pagamento grava transação e recupera dados para o comprovante.
• 4) Teste de sistema: fluxo completo “pagar” até “visualizar comprovante” na interface.
• 5) Regressão: após alterar regra de desconto, reexecutar cenários de pagamento e emissão de comprovante.

Qualidade de software: conceitos essenciais

Qualidade envolve atender requisitos e reduzir defeitos, com foco em atributos. Em prova, aparecem termos como confiabilidade, manutenibilidade e testabilidade.

Atributos de qualidade (exemplos)

• Confiabilidade: operar sem falhas por um período.
• Usabilidade: facilidade de uso e redução de erros do usuário.
• Eficiência/desempenho: tempo de resposta e consumo de recursos.
• Manutenibilidade: facilidade de corrigir/evoluir (código modular, baixo acoplamento).
• Portabilidade: facilidade de executar em diferentes ambientes.
• Testabilidade: facilidade de testar (interfaces claras, dependências controladas).

Boas práticas associadas à qualidade

• Padrões e revisão: revisão de requisitos e de código para detectar defeitos cedo.
• Controle de mudanças: versionamento e gestão de configuração.
• Definição de pronto (DoD): inclui testes, revisão e critérios de aceitação atendidos.

DevOps e CI/CD (nível conceitual)

DevOps integra desenvolvimento e operação para reduzir tempo de entrega e aumentar confiabilidade por meio de automação e feedback contínuo. CI/CD é um conjunto de práticas para integrar, testar e entregar mudanças com frequência.

CI (Integração Contínua)

• Desenvolvedores integram mudanças frequentemente no repositório.
• Pipeline automatizado executa build e testes (principalmente unitários e parte de integração).
• Objetivo: detectar problemas cedo e reduzir “inferno de integração”.

CD (Entrega/Implantação Contínua)

• Entrega contínua: software fica sempre pronto para deploy; deploy pode ser manual/aprovado.
• Implantação contínua: deploy automatizado até produção (quando aplicável e controlado).

Artefatos e práticas típicas em CI/CD

• Pipeline: etapas automatizadas (build, testes, análise estática, empacotamento).
• Artefato de build: pacote versionado gerado (ex.: binário/arquivo de distribuição).
• Ambientes: dev/homologação/produção com promoção controlada.
• Observabilidade: logs, métricas e alertas para feedback pós-deploy.

Rastreabilidade: ligando requisitos, código, testes e entregas

Rastreabilidade é a capacidade de seguir um requisito ao longo do ciclo: de onde surgiu, como foi detalhado, implementado e testado. Em prova, é comum aparecer como “matriz de rastreabilidade” e como mecanismo de controle de mudanças.

Matriz de rastreabilidade (exemplo simplificado)

RF-01 Consultar saldo -> UC-01 Consultar Saldo -> História H-12 -> Testes: TU-05, TI-03, TS-02 -> Release 1.0.0

Benefícios: facilita auditoria, impacto de mudanças e comprovação de cobertura de testes.

Exercícios (cenários): identifique artefatos e melhores práticas

Exercício 1 — Classificação de requisitos

Cenário: Um sistema deve permitir agendar transferências e enviar confirmação.

• a) “O sistema deve permitir agendar transferência para uma data futura.” (RF ou RNF?)
• b) “O sistema deve exibir confirmação em até 2 segundos após o agendamento.” (RF ou RNF?)
• c) “O sistema deve manter registro de auditoria de agendamentos por 5 anos.” (RF, RNF ou regra?)

Exercício 2 — Casos de uso e relações

Cenário: “Realizar Transferência” sempre valida saldo e, opcionalmente, aplica limite especial quando o cliente possui crédito.

• a) Qual relação usar entre “Realizar Transferência” e “Validar Saldo”: include ou extend?
• b) Qual relação usar entre “Realizar Transferência” e “Aplicar Limite Especial”: include ou extend?
• c) Quem é o ator principal: “Cliente” ou “Tela de Transferência”?

Exercício 3 — Leitura de diagrama de classes

Cenário: Um Cliente pode ter várias Contas; uma Conta pertence a um único Cliente.

• a) Indique multiplicidade correta nos dois lados.
• b) Essa relação é associação, agregação ou composição (considerando que Conta pode existir sem Cliente no modelo)?

Exercício 4 — Sequência e responsabilidade

Cenário: Ao pagar um boleto, o app chama um serviço que valida dados e registra a transação.

• a) Em um diagrama de sequência, qual participante deve enviar a mensagem “registrarTransacao()”?
• b) Onde faz sentido aparecer um fragmento alt (alternativa)? Dê um exemplo de condição.

Exercício 5 — Tipos de teste

Cenário: Após alterar a regra de cálculo de tarifa, surgem falhas em funcionalidades antigas.

• a) Qual tipo de teste é mais diretamente associado a detectar essas falhas: unitário, integração, sistema ou regressão?
• b) Dê um exemplo de teste unitário e um de integração relacionados à tarifa.

Exercício 6 — CI/CD e rastreabilidade

Cenário: Uma equipe quer garantir que todo requisito aprovado tenha teste associado e que mudanças não quebrem o sistema.

• a) Qual artefato ajuda a ligar requisito → testes → release?
• b) Em qual etapa do pipeline CI faz sentido executar testes unitários? E testes de sistema?
• c) Cite uma prática para reduzir risco de deploy (ex.: promoção por ambientes, aprovação, monitoramento).