Tecnologias e práticas frontend web: HTML, CSS, Ajax, frameworks (Bootstrap,

Angular, VueJS e React).

Padrões de frontend.

SPA e PWA.

Design de interface e de experiência do usuário, responsividade, usabilidade e acessibilidade,

prototipação, testes A/B.

Tecnologias backend.

Frameworks: Hibernate, .NET Core, Quarkus, SpringBoot, Flask, Django, NodeJS, Express e
NestJS.

Especificações: JEE (JPA, EJB, JSF, JMS e JTA), JVM.

Tecnologia de desenvolvimento móvel: Android (Kotlin), IOS (Swift), Flutter,

ReactNative, Ionic, Xamarin e Banco de Dados SQLite.

Ferramentas de gestão de configuração: versionamento (Git e GitLab), CI/CD (GitLab

CI).

Git: controle de versão distribuído - clientes duplicam localmente o repositório completo.

Protocolos HTTPS, SSL/TLS, HTTP/2, gRPC e WebSockets.

HTTPS: protocolo HTTP com uma camada adicional de segurança

● Porta 443 ou 8443
● Protocolo TLS/SSL
● Permite que os dados sejam transmitidos por meio de uma conexão criptografada
● verifique a autenticidade do servidor e do cliente por meio de certificados digitais
● utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor
seja visualizada por terceiros
○ caso de compras online
○ caso de transmissão de informação sensível

Ferramentas de integração assíncrona.

Protocolos AMQP e MQTT.

Ferramentas Kafka, NATS Streaming, ActiveMQ, RabbitMQ e WebSphereMQ.

Containers.
Engine (Docker).

Orquestração (Kubernetes, OpenShift).

ENGENHARIA DE SOFTWARE
A meta principal da Engenharia de Software: desenvolver sistemas de software com boa relação
custo-benefício

Foco na qualidade. Inclui documentação, gerenciamento e desenvolvimento de técnicas que aprimorem o

próprio desenvolvimento, estágios pós-produção

Foco na qualidade - processos - métodos - ferramentas

● Década de 60: crise do software. Surge engenharia de software

● 80s: Análise Estruturada e algumas Ferramentas CASE
● 90s: orientação a objetos, linguagens visuais
● 2010s: metodologias ágeis

Princípios:
● Formalidade: desenvolvimento segundo passos, com precisão
● Abstração: identificação de determinado fenômeno da realidade, aspectos mais relevantes, sem
preocupação com detalhes
● Decomposição: divide o problema em partes
● Generalização: resolução do problema de forma genérica, a fim de aproveitar soluções
● Flexibilização: permite ao software ser alterado, sem causar problemas para execução

Modelo de processos de software: conjunto de atividades, métodos, práticas e transformações que guiam
pessoas na produção. Deve ser definido caso a caso, considerando:
● Características da aplicação
● Tecnologia a ser adotada na sua construção
● Organização onde o produto será desenvolvido e a equipe de desenvolvimento alocada

Fases básicas do modelo de ciclo de vida:

● Planejamento: plano de projeto. Deve ser revisto ao menos uma vez a cada etapa
● Análise e Especificação de Requisitos: descreve o que o software tem que fazer
● Projeto: incorpora requisitos tecnológicos aos essenciais
● Implementação: traduzido de forma passível de execução pela máquina
● Testes: teste de unidade, teste de integração e teste de sistema, gradativamente
● Entrega e Implantação: treinar usuários, configurar ambiente, converter base de dados. Testes de
aceitação (indica que o software satisfaz os requisitos do usuário)
● Operação: software utilizado em ambiente real de uso
● Manutenção: erros, adaptações, novas funções exigem alterações. Pode requerer novo processo, com
retorno ao ciclo

4 Fases essenciais:
● Especificação de Software
● Desenvolvimento de Software (Projeto e Implementação)
● Validação de Software
● Evolução de Software
DICA: esboço do projeto se dá na modelagem

Modelos de ciclo de vida

Modelos de Ciclo de Vida:

● Cascata: Sequencial: uma fase só se inicia após o término e aprovação da fase anterior. O resultado
de cada estágio é a aprovação de um ou mais documentos (assinados). Maior problema é a divisão
inflexível do projeto em estágios distintos, além de atrasar a detecção de riscos, que só são
averiguados nas fases finais. Método tradicional e fortemente prescritivo (busca dizer o que fazer no
início do projeto)
● Modelo em V: variação da cascata
● Modelo iterativo/incremental: parte iterativa - cada requisito vira um mini projeto, porém são entregues
incompletos até o produto final; produz releases, isto é, versões melhoradas a cada iteração. parte
incremental - divisão de projeto em mini projetos, utilizando-se, por exemplo, cascata para cada um;
várias equipes montam pedaços; produz builds, isto é, partes do software. Menos documentações,
mais flexibilidade para mudanças, feedback mais fácil e mais rápido. Ruim para complexidade, com
várias equipes envolvidas
● Rapid Application Development (RAD): processo de desenvolvimento de software iterativo e
incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias) com
reúso de componentes. Usa protótipos desde o início para obter feedback dos usuários. Número de
fases varia com autor.

Obs.: modelos iterativos e incrementais atuam na prática de forma combinada

Engenharia de requisitos.

Objetivo: criar e manter um documento de requisitos de sistema

Fase mais crítica do desenvolvimento. Principais defeitos de software são oriundos da fase de especificação
de software.

Fases (Pressman):
● Concepção
● Levantamento
● Elaboração: análise de requisitos (expansão e detalhes)
● Negociação
● Especificação: documentação
● Validação
 ● Gestão

DICA: CENAS LAMENTÁVEIS EM NOVO EMPATE DO VASCO DA GAMA

Fases (Sommerville):
● Estudo de viabilidade: gera relatório de viabilidade. Identifica se as necessidades do usuário podem
ser satisfeitas. Em geral rápida e preferencialmente barata. Como o sistema pode contribuir para a
organização? É rentável? É viável? Conjunto preliminar de requisitos de negócios, um esboço da
descrição. A direção decide prosseguir ou não.
● Elicitação e análise de requisitos: gera modelos de sistema: Descobre, identifica informações. Deve-se
trabalhar com os clientes para entender o domínio, serviços que devem ser fornecidos, desempenho
esperado.
○ Obtenção de requisitos: interação com os stakeholders para coletar requisitos. Descobrem-se
os requisitos de domínio
○ Classificação e organização: organiza os req em conjuntos coerentes (classificações de req)
○ Priorização e negociação: resolve conflitos e prioriza reqs.
○ Documentação de requisitos: podem ser formais ou informais. Documenta-se para os
engenheiros, não clientes. Em seguida volta a “obtenção de reqs”
● Especificação: gera requisitos de usuário e de sistema. Cria uma documentação que serve como
contrato entre as partes para ser consultado ao longo do desenvolvimento.
● Validação: estágio focado no cliente.
● Gestão (Gerenciamento de Reqs): fase onde ocorre a rastreabilidade e eventual mudança de
requisitos

DICA: ESTÃO VIABILIZANDO ELIANA ESPECIALMENTE NO VASCO DA GAMA

Técnicas de elicitação e análise de requisitos:

● entrevistas: abertas ou fechadas. As formais podem ser pirâmide, funil ou diamante, a depender de em
que momento entra nos detalhes
● etnografia: técnica de observação, geralmente utilizada com outras. Permite descobrir os req
implícitos.
● cenários: descrições de exemplos, esboço da interação com o sistema, casos de uso
● questionários: útil para grande quantidade de stakeholders e de baixo custo
● workshop de req: reunião estruturada e intensa. Permite utilizar brainstorming ou interpretação de
papéis.
● brainstorming: ocorre em grupos. busca-se explorar potencialidade criativa do grupo, de forma
democrática, porém depende de disponibilidade
● leitura de docs: estrutura organizacional da empresa, padrões de mercado, leis, manuais de usuário,
relatório de pesquisas de mercado, coleta informações mais difíceis de obter por entrevistas,
questionário ou observação, como informações financeiras, histórico, relacionamentos setoriais.
● JAD (Joint Application Design): da IBM, similar a workshop, bastante interativa
● Prototipação: desenvolve forte noção sobre a aplicação a ser implementada. Permite alcançar
feedback antecipado e sensação de segurança aos users por verem algo próximo do real.
● reúso de reqs: requisitos reutilizados têm uma chance maior de serem compreendidos
● Histórias de Usuários: veio do Extreme Programming (XP). histórias concisas capazes de capturar o
que o user de fato precisa fazer, no formato “Como um <papel>, eu quero <meta> de modo que
<benefício>”.
● Participação Ativa de Usuários: incorpora usuários e clientes ao grupo de eng de req.
● encenação
● Interpretação de Papéis: atribui a cada membro do grupo um papel de interesse para o sistema
● grupo focal: grupo de discussão informal e tamanho reduzido para obter informações qualitativas.
Eficiente para esclarecer questões complexas. Depende de seleção criteriosa.
 ● Análise de protocolos: analisa trabalho da pessoa pela verbalização. “O que você faria se...?”
● Pontos de Vista (Viewpoint-Oriented Requirements Definition – VORD): considera perspectivas de
diversas partes interessadas.

Técnicas de validação e revisão de reqs:

● Revisão Técnica: Requisitos são analisados sistematicamente por uma equipe de revisores, podendo
ser informal ou formal. Considera-se Compreensibilidade; Redundância; Completude; Consistência;
Organização; Conformidade; e Rastreabilidade
● Prototipação: Um modelo executável do sistema é apresentado para usuários finais e clientes, para
que verifiquem se atende às necessidades reais.
● Geração de casos de teste: reqs devem ser testáveis.

Disponibilização da função de qualidade (Quality Function Deployment, QFD): técnica aplicável à atividade de
levantamento de requisitos a qual traduz as necessidades do cliente para requisitos técnicos de software.

Classificação de requisitos:
● Nível de abstração (requisitos funcionais ou não funcionais)
○ Requisitos de usuário: alto nível de abstração, para leigos
○ Requisitos de sistema: baixo nível de abstração, para pessoas técnicas
● Qualidade:
○ Req Normais: refletem objetivos e metas estabelecidos para o produto em reuniões com cliente
○ Esperados: implícitos e tão fundamentais que o cliente pode não declarar formalmente.
Exemplo: facilidade de uso, confiabilidade
○ Fascinantes: vão além da expectativa do cliente
● Evolução
○ Permanentes: estáveis
○ Voláteis: instáveis. Específicos para ambiente ou cliente em particular. Modificam-se quando o
sistema está em desenvolvimento ou em uso
■ Mutáveis: modificam em função do ambiente (ex.: baseados em leis fiscais)
■ Emergentes: não podem ser completamente definidos quando o sistema é especificado
e emergem à medida que a compreensão do cliente sobre o sistema se desenvolve.
Em geral só aparecem durante desenvolvimento
■ Consequentes: baseados em suposições de como o sistema será utilizado. O user
percebe a necessidade deles enquanto usa
■ De compatibilidade: que dependem de outro equipamento
● Funcionalidade
○ Funcionais: ações ou funcionalidades que o sistema deve fornecer. Tratam do que o sistema
deve (ou não) fazer. Podem ser descritos como requisitos de usuários (abstratos)
○ Não-funcionais: tratam de como o sistema deve fazer. Restrições e condições estipuladas
sobre as quais o sistema deve funcionar. Fazem parte da arquitetura técnica. Não se
preocupam diretamente com a funcionalidade. Incluem: custo, performance, segurança,
robustez, usabilidade etc. Utilizam-se medidas que possam ser testadas ou mensuradas.
Problema: req conflitantes - alto desempenho com baixo custo. Sub classificam-se quanto à
ORIGEM:
■ Produto: especificam comportamento do produto (rapidez, confiabilidade, usabilidade).
■ Organizacionais: derivados de políticas e procedimentos da organização do cliente e do
desenvolvedor (padrões, linguagem, tempo de entrega da documentação)
■ Externos: req legais, como o sistema interage com outros (interoperabilidade), ética
● Requisitos de domínio: derivados do domínio e refletem características do negócio. Podem ser
funcionais ou não-funcionais. Geralmente escrito no jargão do negócio e entendido pelo especialista
da área.
Gestão de backlog.

Produto mínimo viável (MVP).

A versão de um novo produto que permite que uma equipe colete o máximo de aprendizado sobre os clientes
com a menor quantidade de esforço.
● Relação com feedback do cliente o mais cedo possível.
● Comum no projeto ágil, onde as entregas são rápidas e frequentes.
● NÃO É PROTÓTIPO
● NÃO DISPENSA QUALIDADE

Gestão de Dívida Técnica.

Dívida do desenvolvedor:
● refatoração do código
● realização de testes
● atualização de bibliotecas
● documentação

Métrica de medição: tempo necessário para corrigir problemas encontrados.

Priorizar:
● Segurança
● Problemas que afetam desempenho
● Problemas que afetam mais áreas
● Problemas que afetam capacidade de adicionar funcionalidades

Técnicas de priorização, de estimativas (Análise de Pontos de Função, Story Points).

Story points (histórias de usuário): mede esforço e complexidade dentro da história de usuário. Vem do
Scrum.
● Planning poker: técnica para estimação de pontos. Cartas com valores da sequência Fibonacci (ou
outra). Para cada história, devs escolhem uma carta.
Ponto de função: unidade de medida do software. Indiretamente, permite medir custo do desenvolvimento e
quantidade esperada de erros, a depender de histórico da organização.

Análise de pontos de função (AFP) é um método para dividir o aplicativo de software em componentes
menores e medi-los em relação às suas funcionalidades para estimar o seu tamanho. Independe de
tecnologia, linguagem, plataforma.
● Sob ponto de vista do usuário, ou seja, não importa a complexidade da implementação, importa se é
percebida pelo usuário
● NÃO MEDE, ao menos não diretamente, esforço, custo, qualidade

Fronteira da aplicação: define o que é interno e externo à aplicação. Sua identificação é importante para
contagem correta dos pontos de função.

Funções ou características que devem ser considerados na APF:

● Funções do tipo dado: requisitos de ARMAZENAMENTO. Arquivo se refere a um grupo de dados
logicamente relacionados
○ ALI - Arquivo Lógico Interno: armazena dados mantidos dentro da fronteira da aplicação, ou
seja, podem ser lidos, modificados, incluídos ou excluídos por transações. Ex.: uma ou mais
tabelas que armazenam informações da aplicação.
○ AIE - Arquivo de Interface Externa: semelhante ao ALI, porém mantidos dentro da fronteira de
outra aplicação, portanto fora da fronteira da aplicação. Armazena dados referenciados pela
aplicação em questão. É sempre um ALI de outra aplicação.
● Funções do tipo transação: requisitos de PROCESSAMENTO. Criação, modificação, exclusão de
dados.
○ EE - Entrada Externa: PODE alterar comportamento do sistema. Dados recebidos fora da
fronteira da aplicação (user ou outra app) que altera dados no ALI. Ex.: form de cadastro. Não
faz leitura de dados.
○ CE - Consulta Externa: NUNCA altera comportamento do sistema. Envia dados para fora da
fronteira da aplicação. Não cria dados derivados, não efetua cálculo, não atualiza ALI. Sempre
recupera dados de ALI ou A
○ SE - Saída Externa: SEMPRE altera comportamento do sistema (mesmo que seja um cálculo
de idade - dado derivado). Não é uma simples recuperação de dados; são saídas de
processamentos lógicos. Ex.: contar quantos funcionários.

Tipos de contagem:
● Projeto de desenvolvimento: mede funcionalidades
● Projeto de manutenção/melhoria: mede modificações na aplicação existente. Somente evolutivas, e
não corretivas ou preventivas
● Projeto de aplicação/produção: mede aplicação instalada e em pleno funcionamento (baseline)

Para medir complexidade de ALI/AIE: quantidade de DER e RLR. Para medir complexidade de transações:
DER e ALR.
 ● Dados Elementares Referenciados (DER) ou Tipo de Dado (TD): atributo único, reconhecido pelo
usuário e não repetido
● Registros Lógicos Referenciados (RLR) ou Tipo de Registro (TR): subgrupo de dados elementares.
Ex.: endereço, formado por CEP, rua, número, etc.
● Arquivos Lógicos Referenciados (ALR): é um ALI/AIE que foi acessado por uma função de transação.

Pontos de Função Não-Ajustados (PFNA): multiplica total de funções de dado e transações por suas
respectivas complexidades:

Pontos de Função Ajustado = PFNA x Valor do Fator de Ajuste (VFA)

● PFNA não leva em conta tecnologia ou RNF
● VFA leva em conta 14 Características Gerais do Sistema (CGS)

SNI: somatório do nível de influencia

Abordagem NESMA. Três tipos de contagem:

● Contagem indicativa: Simplifica a contagem, contando apenas AIL e AIE e não atribuindo
complexidade a eles:
○ PFNA = 35 x ALI + 15 x AIE
● Contagem estimativa: quando não existe precisão da complexidade, portanto determina que dados
possuem complexidade baixa e transações, média.
○ PFNA = 4xEE + 4xCE + 5xSE + 5xAIE + 7xALI
● Contagem detalhada: basicamente semelhante à contagem do IFPUG.

Método Backfiring: estimativa dos pontos de função pelo tamanho físico (linhas de código x fator de
conversão dependente da linguagem de prog)

Análise e projeto.

Implementação: orientação a objetos, estrutura de dados e algoritmos.

Qualidade.

Diversos fatores versam sobre qualidade, além das necessidades do usuário. Sistemas devem atender seus
objetivos

DICA: Atributos de qualidade ISO 9126 - Caixa Econômica Federal + Ministério Público da União (CEFMPU):
● Confiabilidade: quantidade de tempo que o software fica disponível, tolerância a falhas, facilidade de
recuperação.
● Eficiência: Grau de otimização de uso dos recursos
● Funcionalidade: grau de satisfação das necessidades declaradas, exatidão, segurança
● Manutenibilidade: facilidade de correção, de análise, de mudanças, estabilidade, testabilidade
● Portabilidade: facilidade de transportar de ambiente a outro, de instalação, de substituição
● Usabilidade: facilidade de uso, compreensão, operabilidade, aprendizagem

Gerenciamento de qualidade:
● Garantia de qualidade: foca no processo de desenvolvimento de software e prevenção de defeitos.
Orientado a processo e prevenção. Processos.
● Controle de qualidade: foca no produto entregue ao usuário e na detecção e correção de defeitos.
Orientado a produto e detecção. Ações.

DICA: Teste x depuração. Teste: estabelece a existência de defeitos; depuração: localiza e conserta.

● Defeito/Falta: ato insconsciente cometido por um indivíduo (ex.: instrução ou comando incorreto).
Causam erro.
● Erro/Engano: trata-se da ação humana que produz um resultado incorreto (ex.: lógica incorreta
escrita). Manifestação concreta de defeito. Diferença entre valor obtido e esperado.
● Falha: comportamento operacional do software diferente do esperado. Consequência de defeitos e
erros.
● D - causam E - causam F: DEF
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.