Pressman:

● Defeito: problema de qualidade após o lançamento

● Erro: problema de qualidade antes

Qualidade:
● Em uso: Eficácia, produtividade, segurança, satisfação. Ponto de vista do usuário.
● Interna: atributos internos, como tamanho do código
● Externa: conjunto de atributos externos

Análise estática de código.

Detecção de erros de código sem executá-lo. Revisão automática de código. Ex.: Compilador, inspeção.
Prática de encontrar defeitos no código e modelagem.

Verificação x validação (V&V):

● Ocorrem em cada estágio do processo de software
● Verificação (depende da especificação): estamos construindo o produto corretamente? está de acordo
com as especificações do sistema? Desenvolvimento.
○ Estática: Inspeção de software, documentação, não requer rodar, automática, pode ser antes
da implementação. Análise de documento de requisitos, análise de diagramas de projetos,
análise de código-fonte
○ Dinâmica: Teste. Executa e examina comportamento através das saídas para saber se está
dentro do esperado.
● Validação (depende do usuário): estamos construindo o produto correto? está de acordo com as
necessidades do usuário? Ambiente do usuário.

DICA: vERificação: Especificação de Requisitos. Validação: usuários

Inspeção: dirigida por checklists e heurísticas

Analisadores estáticos: ferramentas de software que varrem o código em busca de defeitos e anomalias.
Possibilidade: revisão por pares.

Anomalias: frequentemente resultado de erros de programação ou omissões.

Estágios da análise estática:

● Análise de Fluxo de Controle: loops e códigos inacessíveis
● Análise de Uso de Dados: variáveis sem incialização prévia, escrita duas vezes, não usadas
● Análise de Interface: consistências de rotinas, procedimentos e seus usos. Ex.: funções nunca
chamadas, resultados de funções nunca usados.
● Análise de Fluxo de Informações: identifica dependências entre var de entrada e saída.
● Análise de Caminho: identifica caminhos possíveis.

Teste unitário.

Teste de Componente/Módulo, focaliza o esforço de verificação na menor unidade de projeto do software: o

componente ou módulo. Testam-se unidades do código fonte, como métodos e classes, garantindo
funcionamento adequado.
Mock, stubs.

Dublê de testes: objetos falsos usados no lugar de verdadeiros. Eliminam dependências (ex.: não precisa
fazer conexão). NÃO SÃO ACONSELHADOS EM TESTES DE INTEGRAÇÃO.

Mocks: imitações ou unidades falsas que simulam o comportamento de unidades reais. Simula o resultado de
funções sem precisar executá-las. Contribuem, portanto, para os testes de unidade.
● Testa se métodos são chamados corretamente
● Testa se os parâmetros passados estão corretos
● Testa quantas vezes o método mockado foi chamado

Stubs: parecidos com mocks, porém mais simples.

● Objetos com respostas prontas.
● Testa retorno de dependência externa

Teste de integração.

Teste de Integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que
conduz testes para descobrir erros associados com as interfaces.

Definições:
● Testa interface entre componentes.
● Tem por objetivo construir estrutura de programa a partir de componentes já testados.
● Não ocorrem na execução, e sim na junção de componentes.

Integração não incremental: big bang - todos os componentes são combinados com antecedência e o
programa inteiro é testado como um todo. CAOS.

Integração incremental: programa testado em pequenos incrementos ainda no desenvolvimento.

Teste de RNF (carga, estresse).

Teste de requisito não funcional (RNF).

São testes de desempenho:

● Teste de carga: determina comportamento sob condições específicas ou acordadas. A carga pode ser
número de usuários simultâneos esperado.
● Teste de estresse: coloca o sistema em situações anormais.
○ Deliberadamente intenso e completo utilizado para determinar a estabilidade de um
determinado sistema ou entidade
○ Pode ser ao ponto de ruptura

Revisão e programação por pares.

Revisão por pares: técnica de análise estática.

Programação por pares: análise estática dentro de métodos ágeis.

Gestão de configuração.
DevOps, modelo de versionamento, merge, branch, pipeline, CI/CD e database migration.

Infraestrutura.

Infraestrutura como código (IAC).

Linguagens de script (Ansible, Terraform, ShellScript).

Resiliência de aplicações.

Técnica (Cache, Fallback, Circuitbrake, Disaster Recovery, Contingência, Balanceamento de Carga

Global de Servidores (GSLB), Site Ativo X Ativo).

Monitoração e observabilidade.

Low-code e no-code software development.

Permitem a criação de aplicativos com pouco ou nenhum conhecimento de prog.

● Reduzem tempo de criação, permitindo focar em outras etapas, como testes
● Facilitam a criação de apps
● Democratizam o desenvolvimento
● Limitam personalização e escopo
● Low-code
○ Kits de desenvolvimento pré-fabricados, com interfaces visuais, modelos pré-construídos,
podendo ser personalizados.
○ Quantidade reduzida de prog tradicional
● No-code:
○ Dispensa escrever qualquer linha de código
○ plataformas que oferecem ferramentas de arrastar e soltar.
● Ex.: Microsoft Power Apps (Low), Google App Maker, Salesforce Lightning, OutSystems (Low),
Mendix, Bubble (No), Airtable e Webflow
● Opção de integração: APIs

ARQUITETURA

Padrões de projeto (GoF, de criação, estruturais, comportamentais).

Padrões GRASP (controller, expert).

SOLID e Clean Code.

Tecnologias de integração.

Workflow.

Web services.

RESTful, SOAP e GraphQL.

Mensageria, stream e CORBA.

Design de software.

DDD - Domain-Driven Design.

Arquitetura hexagonal

Microsserviços (orquestração de serviços e API gateway) e containers.

Padrões de microsserviços (SAGA e CQRS).

Transações distribuídas.

NUVEM

12 factories.

Metodologia para desenvolver e publicar SaaS:

1. Base de código: rastreamento utilizando controle de versões, muitos deploys
2. Dependências: Declare e isole as dependências explicitamente
3. Configurações: Armazene as configurações no ambiente
4. Serviços de apoio: Trate os serviços de apoio como recursos anexados
5. Construa, lance, execute: Separe estritamente os builds e execute em estágios
6. Processos: Execute a aplicação como um ou mais processos que não armazenam estado
7. Vínculo de porta: Exporte serviços via vínculo de portas
8. Concorrência: Escale através do modelo de processos
9. Descartabilidade: Maximize robustez com inicialização rápida e desligamento gracioso
10. Paridade entre desenvolvimento e produção: Mantenha o desenvolvimento, homologação e produção
o mais similares possível
11. Logs: Trate logs como fluxos de eventos
12. Processos administrativos: Rode tarefas de administração/gestão em processos pontuais

Orientação a serviço.

IaaS - Infraestrutura com Serviço.

● Ao usuário é disponibilizado hardware
● Usuário capaz de configurar segurança, rede, SO etc

SaaS – Software como Serviço.

● Ao usuário é disponibilizada uma aplicação (ex.: Google Docs)

PaaS – Plataforma como Serviço.

● Ao usuário é disponibilizada ambiente para desenvolvimento e teste de aplicações

TÓPICOS AVANÇADOS
Inteligência artificial.

Análise de dados (Pandas, NumPy, Jupiter, R).

Aprendizado de máquina.

Técnicas de classificação.

Técnicas de regressão.

Técnicas de agrupamento.

Técnicas de redução de dimensionalidade.

Técnicas de associação.

Sistemas de recomendação.

Processamento de linguagem natural (PLN).

Visão computacional.

Deep learning.

Ciência de dados.

Big Data.

Captura, gerenciamento e análise de dados que vão além de dados estruturados típicos.
● Dados não-estruturados são maioria

Fundamentos.
● 5Vs: volume, velocidade, variedade (3Vs iniciais)
○ 4º V: veracidade
○ Valor

● Outros Vs:
○ Visibilidade: relevância
○ Variabilidade (e complexidade): variação nas taxas de fluxo; complexidade: múltiplas fontes
○ Visualização: como são apresentados

Armazenamento de big data.

São, na maioria das vezes, armazenados em seu formato original.

Incompatibilidade de impedância: série de problemas que representam dados de bando de dados relacionais
em linguagens de programação orientada a objetos.

NoSQL (not only SQL):

● Não-relacional
 ● Semi-estruturado
● Consistência eventual
● Emergente
● Escalável
● Flexível

Sistemas de arquivos distribuídos:

● HDFS (Hadoop Distributed File System)

Modelo de dados:
● Agregado: conjunto de objetos relacionados que desejamos tratar como uma unidade.
● Chave-valor:
○ Trata o agregado como um todo opaco, não sendo possível recuperar partes dele.
○ Conjunto de chaves, as quais estão associadas a um único valor.
○ Ex.: Riak, Redis, Amazon DynamoDB, Oracle BerkleyBD
● Documentos:
○ Permite consultas e seleções parciais no agregado.
○ Documento é objeto com identificador único e conjunto de campos. Estes campos se
assemelham à estrutura chave-valor.
○ Possibilita atualizar a estrutura do documento, com adição de novos campos.
○ Ex.: MongoDB, CouchDB, Azure DocumentDB
● Colunar:
○ Divide o agregado em colunas, permitindo tratá-las como unidades.
○ Dados indexados por (linha, coluna, timestamp), sendo que este último permite diferenciar
versões.
○ Ex.: Hbase, Cassandra, HyperTable, BigTable, Hadoop
● Grafos
○ Registros pequenos com interconexões complexas (modelo oposto ao relacional)
○ Neo4J, Infinite Graph, InfoGrid, Titan
● Timeseries
○ Tempo (timestamp) é indexador chave
○ Fornece performance e armazenamento, por ter menos relações e não requer armazenamento
de um número indefinido de entidades
○ Influxdb

CAP: Consistência, disponibilidade e tolerância a partições. Prover os 3 não é possível.

● Consistência: Leitura de qualquer nodo do sistema deve retornar a mesma informação
● Disponibilidade: toda requisição de leitura ou escrita é respondida como sucesso ou falha.
● Tolerância a partições: tolerância a situação de split brain - o cluster pode suportar falhas na
comunicação que o dividam em partições incapazes de se comunicar entre si.

ACID x BASE: na BASE, a consistência não ocorrerá no mesmo instante, gerando uma fila de consistência
(fluxo). Eleva o sistema a níveis de escalabilidade não permitidos no ACID; ganha-se disponibilidade em troca
de consistência
● Basically Available: Disponibilidade garantida, tolerando falhas parciais. Persistência não é efetivada
em tempo real. Se o banco é basicamente disponível, sempre dará conhecimento ao pedido de um
cliente
● Soft State: um banco de dados pode estar em um estado inconsistente quando lido, o que significa
que os dados podem mudar se lidos novamente
● Eventual Consistency: o banco só alcança consistência uma vez as mudanças propagadas para todos
os nós. Permite servir a múltiplos clientes sem latência, embora resultados inconsistentes
Pipeline de dados.

Processamento distribuído.

Conceitos de data lake.

Armazenamento de Dados.

Sistemas de arquivos distribuídos.

Armazenamento orientado a objeto (object store).

Sistemas de indexação.

Processamento de Dados.

Conceitos de processamento massivo e paralelo.

Processamento em lote (batch).

Processamento em tempo real (real time).

Processamento MapReduce.