Parte 1 — Introdução à carreira, pensamento sistêmico e base computacional

Prefácio — Antes do código existe um problema

Uma empresa pode contratar desenvolvedores, comprar servidores, assinar serviços em nuvem e adotar as ferramentas mais modernas do mercado. Ainda assim, pode terminar com um sistema caro, difícil de manter e incapaz de resolver o problema para o qual foi criado.

Isso acontece porque tecnologia não corrige, por si só, uma compreensão ruim da realidade.

Imagine uma solicitação aparentemente simples: “Precisamos de uma tela para abrir chamados”. Se a equipe começar pelo formulário, poderá entregar uma interface bonita em poucos dias. Mas o que acontecerá depois que o usuário clicar em Enviar? Quem receberá a solicitação? Qual regra definirá a prioridade? O prazo será contado em horas corridas ou úteis? Um usuário poderá enxergar o chamado de outro departamento? O que ocorrerá se o serviço responsável pelas notificações estiver indisponível? Como a gestão saberá se o atendimento melhorou?

A tela é visível. O sistema, quase sempre, é maior do que ela.

Análise e Desenvolvimento de Sistemas nasce exatamente dessa diferença: o profissional não trabalha apenas com código, mas com problemas, objetivos, pessoas, processos, dados, regras e componentes tecnológicos que precisam funcionar como um conjunto. Diretrizes curriculares internacionais da ACM e da IEEE tratam a computação como um campo composto por competências — combinação de conhecimento, habilidade e disposição para agir — e não como uma coleção de ferramentas isoladas [1]. O modelo de competências de Sistemas de Informação da ACM e da AIS reforça essa ligação entre tecnologia, contexto organizacional e geração de valor [2].

Este volume começa, portanto, antes da linguagem de programação. O objetivo é construir o modelo mental que permitirá compreender o que um sistema é, como suas partes se relacionam, onde o software entra e como um problema humano pode ser transformado em uma solução computacional verificável.

Ao concluir esta parte, você deverá ser capaz de:

• distinguir sistema, sistema de informação, software, programa e algoritmo;
• identificar propósito, fronteira, ambiente, entradas, transformações, saídas e feedback de um sistema;
• perceber quando uma demanda descreve apenas uma solução aparente, e não a necessidade real;
• relacionar pessoas, processos, regras, dados e tecnologia em um mesmo modelo;
• representar regras simples com variáveis, expressões, condições e repetições;
• acompanhar o estado de um algoritmo passo a passo;
• transformar uma solicitação vaga em uma primeira especificação analisável;
• reconhecer simplificações úteis sem confundi-las com a arquitetura real.

Os volumes seguintes entrarão em sistemas operacionais, redes, bancos de dados, APIs, engenharia de software, segurança, arquitetura e operação. Esses assuntos serão mencionados aqui apenas quando ajudarem a enxergar o sistema completo. O aprofundamento permanecerá no volume ao qual pertence.

Como estudar este livro sem confundir leitura com aprendizagem

Ler produz familiaridade. Familiaridade, porém, pode ser confundida com domínio.

Quando um parágrafo parece claro, é tentador concluir que o conceito foi aprendido. O teste real começa quando o livro é fechado e você precisa explicar o assunto, reconstruir o fluxo, resolver um caso diferente ou diagnosticar uma falha. Por isso, esta obra combina quatro práticas: notas interconectadas, autoexplicação, recuperação ativa e estudo distribuído. Elas não possuem o mesmo nível de evidência científica e não devem ser apresentadas como equivalentes.

1. Notas interconectadas: use o Zettelkasten como sistema de conhecimento

Zettelkasten significa, literalmente, “caixa de notas”. O método ficou associado ao sociólogo Niklas Luhmann, que manteve um arquivo de fichas numeradas e conectadas. Estudos históricos sobre esse arquivo mostram seu papel como instrumento de pensamento e produção intelectual [3]. Isso não equivale a dizer que o Zettelkasten, como pacote fechado, tenha o mesmo suporte experimental das práticas de recuperação e espaçamento.

Aqui ele será usado com uma finalidade precisa: construir relações entre conceitos.

Uma nota útil não copia um parágrafo inteiro. Ela registra uma ideia com suas palavras, preserva a fonte e indica conexões. Por exemplo:

ZK-001 — Sistema

Ideia:
Um sistema é um conjunto de elementos relacionados, delimitado para fins de
análise, cujo comportamento produz resultados em determinado ambiente.

Exemplo próprio:
No sistema de chamados, formulário, regras de prioridade, técnicos, SLA,
notificações e relatórios participam do mesmo resultado operacional.

Conexões:
- ZK-002 — Fronteira e ambiente
- ZK-003 — Entrada, transformação e saída
- ZK-004 — Feedback e controle
- ZK-005 — Sistema de informação sociotécnico

Fonte:
Capítulo 1, seção 1.2; Bertalanffy [4]; ISO/IEC/IEEE 15288:2023 [5].

Observe a diferença: a nota não funciona como depósito de frases. Ela funciona como unidade de raciocínio.

2. Autoexplicação: tente ensinar para descobrir as lacunas

O chamado “Método Feynman” costuma ser resumido assim: escolha um conceito, explique-o em linguagem simples, identifique onde sua explicação falha, volte à fonte e tente novamente. A formulação popular é inspirada na reputação didática de Richard Feynman, mas não deve ser apresentada como se fosse um protocolo experimental criado e validado por ele.

O mecanismo educacional mais próximo e bem estudado é a autoexplicação. Em um estudo clássico, Michelene Chi e seus colaboradores observaram que estudantes que geravam explicações sobre os passos e princípios de exemplos resolvidos desenvolviam compreensão mais transferível do que aqueles que apenas acompanhavam o material [6].

Neste livro, a prática será aplicada assim:

1. Feche a seção.
2. Explique o conceito sem consultar o texto.
3. Dê um exemplo diferente do apresentado.
4. Mostre onde a analogia deixa de funcionar.
5. Reabra a seção e corrija as lacunas.
6. Registre a versão corrigida em uma nota curta.

Se você consegue repetir as palavras do texto, demonstrou memória verbal. Se consegue explicar, comparar, aplicar e delimitar, começou a demonstrar compreensão.

3. Recuperação ativa: recupere antes de reler

Active recall, ou recuperação ativa, é a tentativa deliberada de trazer uma informação à mente sem consultar imediatamente a resposta. Em experimentos sobre aprendizagem, a prática de recuperação produziu melhor retenção de longo prazo do que releituras sucessivas e, em determinadas condições, superou até estratégias elaborativas como mapas conceituais feitos com o material disponível [7].

Isso não significa que mapas, resumos e releituras sejam inúteis. Significa que a aprendizagem não deve terminar neles.

Use as perguntas de Active Recall ao final da parte da seguinte maneira:

• responda sem olhar o capítulo;
• marque cada resposta como segura, parcial ou incorreta;
• compare com o texto;
• escreva a correção com suas palavras;
• crie uma nova pergunta que exija aplicação, não mera definição.

Uma boa pergunta não é apenas “o que é feedback?”. Uma pergunta mais forte seria: “Que indicador de um sistema de chamados poderia funcionar como feedback e que ação de controle ele justificaria?”.

4. Prática espaçada: distribua o esforço

Estudar o mesmo conteúdo em sessões separadas tende a produzir melhor retenção do que concentrar toda a exposição em uma única sessão. A síntese quantitativa de Cepeda e colaboradores reuniu centenas de experimentos e mostrou que o efeito depende da relação entre o intervalo de estudo e o tempo durante o qual se deseja reter o conteúdo [8]. Portanto, não existe um calendário universal perfeito.

O ciclo 1–3–7–14–30 dias pode ser usado como ponto de partida operacional, não como lei biológica. Ajuste-o conforme dificuldade, desempenho e objetivo.

5. A regra central de estudo

Não avalie a aprendizagem pelo tempo sentado nem pelo número de páginas destacadas. Avalie-a pelo que você consegue produzir sem apoio:

lembrar → explicar → representar → aplicar → comparar → diagnosticar

Capítulo 1 — O que é Análise e Desenvolvimento de Sistemas?

1.1 A demanda quase nunca é o problema completo

“Crie um botão para reabrir o chamado.”

Essa frase parece um requisito. Ainda não é.

Ela descreve uma solução imaginada por alguém, mas não revela necessariamente a necessidade que a originou. O usuário talvez precise corrigir uma informação depois do encerramento. A auditoria talvez exija preservar o registro original. O suporte talvez esteja fechando solicitações antes da confirmação. Cada causa levaria a uma solução diferente: reabertura controlada, nova solicitação vinculada, período de contestação, mudança no fluxo de fechamento ou correção do processo operacional.

O analista começa separando cinco elementos:

É aqui que a palavra Análise ganha sentido. Analisar não é atrasar o desenvolvimento com documentação. É reduzir o risco de construir corretamente a coisa errada.

O padrão de Análise de Negócios do IIBA organiza a prática em torno de conceitos como mudança, necessidade, solução, contexto, partes interessadas e valor [9]. As diretrizes IS2020, por sua vez, incluem análise e design de sistemas, modelagem de processos, requisitos, dados, tecnologia e contexto organizacional entre as competências da formação em Sistemas de Informação [2]. Ambas as perspectivas apontam para a mesma conclusão: solução técnica e resultado de negócio precisam ser conectados.

1.2 O que é um sistema?

Um sistema pode ser compreendido como um conjunto de elementos relacionados cujo comportamento, observado dentro de uma fronteira e em interação com um ambiente, produz resultados. A Teoria Geral dos Sistemas ajudou a consolidar a ideia de que fenômenos complexos não podem ser explicados adequadamente apenas pela decomposição de suas partes [4].

Essa definição precisa de cuidado. Nem todo conjunto de coisas forma um sistema relevante. Uma CPU, um teclado e uma política de aprovação colocados na mesma sala não constituem, por proximidade física, um sistema coerente. É necessário identificar relações, finalidade ou função, fronteira de análise e comportamento.

Propósito

O propósito responde: para que esse sistema existe?

Um sistema de chamados não existe para armazenar tickets. Esse é apenas um mecanismo. Seu propósito pode ser restaurar serviços, atender solicitações, preservar comunicação, coordenar responsabilidades e produzir informação para melhoria do atendimento.

Quando o propósito é confundido com a ferramenta, surgem decisões frágeis. “Implantar GLPI” é uma ação. “Reduzir perda de solicitações e tornar os prazos mensuráveis” é um resultado pretendido.

Elementos e relações

Os componentes podem incluir pessoas, software, hardware, dados, procedimentos, regras, instalações e serviços externos. A norma ISO/IEC/IEEE 15288 trata sistemas produzidos pelo ser humano como composições que podem incluir exatamente esses tipos de elementos e organiza processos ao longo de todo o ciclo de vida [5].

No caso de um Service Desk:

• o usuário descreve uma necessidade;
• o formulário estrutura parte dos dados;
• regras categorizam e priorizam;
• grupos recebem solicitações;
• técnicos registram diagnóstico e solução;
• notificações mantêm os envolvidos informados;
• calendários e SLAs transformam tempo em compromisso;
• relatórios devolvem informação à gestão;
• decisões de gestão alteram processos, capacidade e prioridades.

O comportamento emerge dessas relações. Um formulário excelente não compensa uma matriz de prioridade incoerente. Um banco rápido não corrige uma fila sem responsáveis. Um dashboard preciso não melhora o serviço se ninguém toma decisões a partir dele.

Fronteira e ambiente

A fronteira define o que será tratado como parte do sistema para determinada análise. Ela não é sempre física nem definitiva.

Se o objeto de estudo é o módulo de autenticação, o diretório corporativo pode ser considerado um serviço externo. Se o objeto é o ecossistema de identidade da organização, esse mesmo diretório passa a integrar o sistema analisado. A fronteira muda conforme a pergunta.

O ambiente reúne elementos externos que influenciam o sistema ou são afetados por ele: legislação, fornecedores, rede, cultura organizacional, orçamento, volume de demanda, integrações e decisões de gestão.

Definir a fronteira não elimina o que ficou fora. Apenas torna explícito o recorte da análise.

Estado

O estado descreve as condições relevantes do sistema em determinado momento. Um chamado pode estar novo, em atendimento, pendente, solucionado ou fechado. O estado não é apenas um rótulo visual: ele pode determinar quem pode editar, qual relógio de SLA continua correndo, que transições são permitidas e quais notificações serão enviadas.

Comportamento

Comportamento é o que acontece quando eventos atingem o sistema e seus elementos reagem segundo regras. A criação de um chamado é um evento. A atribuição automática é uma reação. O vencimento do SLA é outro evento. O escalonamento é outra reação.

Podemos representar a visão inicial assim:

ambiente
   │
   ├── solicitações, restrições, integrações e eventos
   ▼
┌──────────────────── fronteira do sistema ────────────────────┐
│ pessoas ↔ processos ↔ dados ↔ regras ↔ tecnologia            │
│                         │                                     │
│                         └── estado e histórico                │
└───────────────────────────────────────────────────────────────┘
   │
   └── serviços prestados, registros, alertas e indicadores

1.3 Sistema, software e sistema de informação

Os termos são próximos, mas não equivalentes.

Um sistema de informação é sociotécnico: seu resultado depende simultaneamente de arranjos sociais e componentes técnicos. A plataforma registra o chamado, mas uma pessoa descreve o problema; uma regra organizacional define a prioridade; um técnico interpreta evidências; um gestor decide capacidade; uma auditoria exige rastreabilidade.

Considere uma queda do portal. Se os usuários passam a enviar solicitações por mensagens particulares, o serviço não deixa de existir; ele muda para um modo degradado e perde controle. Surgem chamados invisíveis, prioridades negociadas informalmente e históricos fragmentados. O problema não está apenas no software indisponível. Está no sistema de trabalho que não possui contingência adequada.

1.4 Os elementos de um sistema de informação

Uma lista didática comum apresenta pessoas, processos, dados e tecnologia. Ela é útil, mas precisa ser expandida para não esconder relações importantes.

Pessoas e partes interessadas

Nem toda pessoa afetada usa diretamente a aplicação. Solicitantes, atendentes, técnicos, gestores, auditores, fornecedores e titulares de dados podem ter interesses diferentes. O analista precisa identificar poder de decisão, responsabilidade, conhecimento e impacto.

Processos

Processo é uma organização de atividades que transforma uma situação inicial em um resultado. Ele pode atravessar departamentos e sistemas. O processo de admissão de um colaborador, por exemplo, pode envolver RH, gestor, TI, folha, segurança, facilities, e-mail, diretório corporativo e entrega de equipamentos.

Dados e significados

O campo prioridade = 5 não explica sozinho se 5 representa urgência máxima, baixa prioridade ou uma posição numa escala. Estrutura, significado, origem, qualidade, ciclo de vida e responsabilidade pelos dados fazem parte do sistema.

Regras de negócio

Regras expressam restrições, cálculos, classificações, autorizações e políticas. Algumas podem ser automatizadas; outras exigem julgamento humano. A frase “chamados críticos devem ser atendidos imediatamente” ainda é insuficiente: o que caracteriza criticidade, quem pode declará-la, qual prazo se aplica e como exceções serão auditadas?

Tecnologia

Inclui aplicações, infraestrutura, dispositivos, integrações, mecanismos de segurança e ferramentas operacionais. Nesta Parte 1, basta reconhecer que tecnologia implementa capacidades e impõe restrições. Sistemas operacionais, redes, bancos e APIs serão aprofundados nas partes seguintes.

Controles

Controles procuram manter o comportamento dentro de limites aceitáveis: autenticação, autorização, validação, segregação de função, aprovação, auditoria, reconciliação e monitoramento.

Feedback

Feedback devolve informação sobre desempenho, resultado ou mudança de ambiente. Indicadores de tempo, erros, satisfação, reabertura e volume por categoria podem revelar se o serviço está se aproximando do objetivo ou apenas movimentando registros.

1.5 O papel do analista de sistemas

O título varia entre organizações. Analista de sistemas, analista de negócios, analista funcional, analista de sustentação e product analyst podem compartilhar atividades, mas não são sinônimos universais. Da mesma forma, desenvolvedores experientes também analisam requisitos, modelam soluções e discutem processos.

Em vez de definir a profissão por uma lista rígida de cargos, é mais útil observar o ciclo de raciocínio:

necessidade percebida
        ↓
investigação do contexto
        ↓
modelagem do estado atual
        ↓
definição do resultado desejado
        ↓
requisitos, regras e restrições
        ↓
alternativas de solução
        ↓
validação com partes interessadas
        ↓
construção e testes
        ↓
implantação e observação
        ↓
feedback para nova análise

O analista participa de diferentes pontos desse ciclo:

• identifica necessidades e conflitos entre stakeholders;
• investiga causa, impacto e frequência de problemas;
• delimita escopo e fronteiras;
• modela processos, estados, dados e integrações;
• transforma linguagem do negócio em requisitos verificáveis;
• separa regra de negócio de decisão de interface;
• avalia alternativas e trade-offs;
• constrói critérios de aceitação;
• apoia testes e implantação;
• documenta decisões e rastreia mudanças;
• observa o comportamento em produção;
• propõe correções e melhorias a partir de evidências.

O SWEBOK organiza requisitos de software em fundamentos, elicitação, análise, especificação, validação e outras práticas relacionadas [10]. O trabalho real, porém, raramente ocorre como uma linha perfeita. Uma restrição descoberta no teste pode obrigar a revisar o requisito; um incidente de produção pode revelar uma regra implícita; um usuário pode mudar de entendimento depois de ver um protótipo.

Análise é iterativa.

1.6 Analista de sistemas e desenvolvedor: responsabilidades que se sobrepõem

A comparação “analista pensa; desenvolvedor programa” é simples demais e desvaloriza as duas atividades. Desenvolvimento profissional exige análise; análise viável exige compreensão técnica suficiente para avaliar possibilidades e consequências.

Na prática, a fronteira muda com tamanho da equipe, domínio, método de trabalho e senioridade. Em uma equipe pequena, a mesma pessoa pode conversar com usuários pela manhã, modelar dados à tarde e implementar uma API no dia seguinte. Em uma organização regulada, responsabilidades podem ser deliberadamente separadas.

O ponto não é escolher qual função “vale mais”. É garantir que quatro perguntas sejam respondidas:

1. Estamos resolvendo o problema correto?
2. A solução proposta é viável?
3. A implementação corresponde ao comportamento acordado?
4. O resultado observado confirma a hipótese inicial?

1.7 Do pedido à especificação: um exemplo completo

Demanda recebida:

“Quando um chamado urgente for aberto, envie uma mensagem no Slack.”

Uma resposta apressada criaria uma automação. Uma análise mínima investiga:

Necessidade

Por que a mensagem é necessária? Talvez incidentes críticos estejam permanecendo sem atendimento porque a equipe não observa continuamente a fila.

Evento

O disparo ocorre na criação, na mudança de prioridade ou em ambos? Importações e integrações também criam chamados?

Classificação

“Urgente” é escolhido pelo solicitante, calculado por impacto e urgência, ou confirmado por um técnico? Um usuário poderia gerar alertas excessivos?

Destinatário

Qual canal recebe o aviso? Existe separação por entidade, filial, serviço ou horário? Quem responde fora do expediente?

Conteúdo e privacidade

O título ou a descrição pode conter dados pessoais? A mensagem deve incluir link, identificador, categoria e prazo, mas não conteúdo sensível?

Falha

Se o Slack estiver indisponível, o chamado continuará registrado? A tentativa será repetida? Haverá log e alerta da falha? O envio da mensagem não pode bloquear a abertura.

Critério de aceitação

Uma primeira regra verificável poderia ser:

DADO que um chamado foi registrado com impacto alto e urgência alta
E que pertence à entidade Osten Group > TI
QUANDO a prioridade calculada for crítica
ENTÃO o chamado deve ser persistido normalmente
E uma notificação sem dados pessoais deve ser enviada ao canal configurado
E o resultado do envio deve ser registrado
E uma falha de notificação não deve desfazer a criação do chamado.

Agora existe material para desenvolvimento, teste e operação. A diferença não foi produzir mais texto. Foi tornar decisões invisíveis em decisões explícitas.

Nota Zettelkasten

ZK-005 — Análise de sistemas

Analisar um sistema é investigar necessidade, contexto, fronteira, elementos,
regras, restrições e resultados antes e durante a construção da solução.

Conexões:
- ZK-001 — Sistema
- ZK-006 — Necessidade e solução
- ZK-007 — Requisito verificável
- ZK-008 — Trade-off
- ZK-009 — Feedback de produção
```---
# Capítulo 2 — Pensamento sistêmico

## 2.1 O erro confortável de tratar sintomas isolados

O tempo médio de atendimento aumentou. A resposta imediata da gestão é cobrar mais velocidade dos técnicos.

Pode funcionar por alguns dias. Também pode piorar o sistema.

Sob pressão, técnicos podem registrar diagnósticos menores, encerrar chamados prematuramente ou evitar solicitações complexas. A métrica melhora enquanto a taxa de reabertura cresce. Chamados voltam para a fila, interrompem o trabalho planejado e aumentam ainda mais a pressão. A ação local produziu um efeito oposto no conjunto.

Pensamento sistêmico é a capacidade de investigar esse tipo de comportamento por meio de relações, atrasos, estoques, fluxos, feedback e consequências não intencionais. Peter Senge popularizou sua aplicação a organizações que aprendem [11]; Donella Meadows mostrou como estruturas e ciclos de feedback ajudam a explicar o comportamento de sistemas complexos [12].

Pensar sistemicamente não significa “considerar tudo”. Isso seria impossível. Significa construir um recorte explícito e suficientemente amplo para não atribuir a uma parte o comportamento produzido pelas relações.

## 2.2 Eventos, padrões e estruturas

Considere três níveis de observação:

### Evento

“O chamado 20418 ultrapassou o SLA.”

O evento exige tratamento imediato, mas explica pouco.

### Padrão

“A proporção de violações de SLA aumentou durante quatro semanas, principalmente em acessos e permissões.”

O padrão sugere recorrência e permite segmentação.

### Estrutura

“A admissão de colaboradores gera solicitações individuais; as aprovações chegam incompletas; a equipe depende de duas áreas; chamados ficam pendentes sem que o calendário de SLA reflita corretamente essa espera; o volume se concentra às segundas-feiras.”

A estrutura conecta processo, dados, dependências, regras e capacidade. É nela que intervenções duradouras costumam ser encontradas.

Uma pergunta sistêmica transforma “quem atrasou este chamado?” em “que combinação de demanda, capacidade, regra e dependência torna esse atraso recorrente?”. Responsabilidade individual continua importante, mas deixa de ser explicação automática para um padrão estrutural.

## 2.3 Fronteiras: o que incluímos muda a resposta

Suponha que uma API de integração falhe porque recebeu um campo vazio.

Se a fronteira da análise contém apenas a função que enviou a requisição, a correção pode ser adicionar uma validação. Se incluirmos o formulário de origem, descobrimos que o campo não era obrigatório. Se incluirmos o processo, percebemos que usuários não sabem onde obter a informação. Se incluirmos o sistema externo, talvez o contrato da API tenha mudado sem versionamento.

Cada ampliação revela causas e responsabilidades diferentes.

Use este roteiro para definir a fronteira:

- qual decisão precisamos tomar;
- qual resultado estamos tentando explicar;
- em que período o comportamento ocorre;
- quais atores alteram entradas, regras ou capacidade;
- quais serviços externos participam do fluxo;
- quais efeitos relevantes aparecem fora da aplicação;
- o que ficará deliberadamente fora e por quê.

Uma fronteira ampla demais impede ação. Uma fronteira estreita demais produz diagnósticos falsos.

## 2.4 Entrada, transformação e saída — útil, mas incompleto

O modelo `Entrada → Processamento → Saída` é uma primeira lente poderosa. Ele obriga o analista a perguntar o que chega, o que muda e o que é produzido.

No login:

| Etapa | Elementos observáveis |
|---|---|
| Entrada | Identificador, segredo, contexto da tentativa e metadados mínimos |
| Transformação | Validação, localização da identidade, verificação da credencial, avaliação de políticas e registro do evento |
| Saída | Sessão ou token, resposta de falha, log e possíveis alertas |

Há uma correção técnica importante: senhas não devem ser “descriptografadas” nem comparadas como texto armazenado. Sistemas adequados guardam um derivado produzido por função de hash de senha com `salt` e parâmetros de custo; a verificação aplica o procedimento compatível à entrada e compara o resultado. Segurança será aprofundada em volume próprio, mas o vocabulário precisa nascer correto.

O modelo EPS, contudo, congela um recorte do tempo. Sistemas reais também mantêm estado, recebem eventos concorrentes, dependem de outros sistemas, falham parcialmente e devolvem feedback. Por isso, a representação mais completa é:
```text
entrada/evento
      ↓
validação → transformação → saída
      │             │          │
      └──────── estado ─────────┘
                    │
                 feedback
                    │
                  controle

2.5 Feedback não é qualquer retorno

Uma mensagem “chamado criado com sucesso” é uma saída para o usuário. Ela se torna parte de um ciclo de feedback quando informação sobre o resultado retorna a alguém ou a algum mecanismo capaz de ajustar o comportamento.

Exemplo:

volume de chamados aumenta
        ↓
tempo de espera aumenta
        ↓
painel detecta desvio
        ↓
gestor redistribui capacidade
        ↓
fila diminui

Esse é um ciclo de correção: o desvio produz ação que procura reduzi-lo. Na terminologia de sistemas, costuma ser chamado de feedback balanceador ou negativo. “Negativo” não significa ruim; significa que o ciclo contraria a variação.

Outro ciclo pode reforçar o problema:

pressão por velocidade aumenta
        ↓
diagnóstico fica superficial
        ↓
reaberturas aumentam
        ↓
fila aumenta
        ↓
pressão por velocidade aumenta

Esse é um feedback reforçador ou positivo: a mudança alimenta mais mudança na mesma direção. “Positivo” não significa benéfico.

Norbert Wiener colocou comunicação, controle e feedback no centro da cibernética [13]. Para o analista, a consequência prática é direta: um sistema sem mecanismo de observação pode executar regras durante meses sem revelar se produz o efeito desejado.

2.6 Controle: decidir e agir sobre o desvio

Métrica sem decisão é decoração.

O controle começa quando existe:

1. uma referência ou objetivo;
2. uma observação do estado atual;
3. uma comparação entre estado e referência;
4. uma ação possível;
5. nova observação do efeito.

No Service Desk:

O cuidado aparece no último item. Melhorar uma métrica pode deslocar o problema. Se o SLA melhora, mas reaberturas e insatisfação sobem, o controle otimizou uma medida local, não o serviço.

2.7 Atrasos e consequências não imediatas

Sistemas possuem atrasos entre ação e efeito. Um treinamento realizado hoje pode reduzir erros apenas quando novos chamados semelhantes surgirem. Uma mudança de prioridade pode aliviar a fila crítica e acumular solicitações de baixa prioridade. Um índice adicionado ao banco pode acelerar leituras, mas aumentar custo de escrita — assunto que será aprofundado em volume posterior.

Sem considerar atrasos, a equipe pode abandonar uma melhoria antes de seus efeitos aparecerem ou atribuir a ela um resultado causado por outra mudança.

Pergunte sempre:

• quando a ação começa a produzir efeito;
• por quanto tempo o efeito permanece;
• que indicador reage primeiro;
• que consequência aparece mais tarde;
• que grupo recebe o benefício;
• que grupo absorve o custo.

2.8 Otimização local e o erro de “melhorar a tela”

Uma tela de abertura pode ser simplificada removendo campos. A taxa de conclusão cresce. Porém, se os campos removidos eram necessários à triagem, técnicos passam a buscar informações por mensagens, o tempo total aumenta e o histórico perde qualidade.

A interface ficou melhor segundo uma métrica local. O sistema ficou pior.

Para avaliar uma mudança, acompanhe o fluxo completo:

necessidade do usuário
        ↓
registro da solicitação
        ↓
qualidade dos dados
        ↓
classificação e roteamento
        ↓
diagnóstico e comunicação
        ↓
solução e validação
        ↓
aprendizagem e prevenção

O pensamento sistêmico não elimina decisões locais. Ele exige que o efeito local seja confrontado com o resultado do fluxo.

2.9 Um método de análise sistêmica para incidentes

Quando um incidente recorrente surgir, use a sequência:

1. Descreva o comportamento sem atribuir culpa

“Em 18% das admissões, ao menos um acesso não está disponível na data de início.”

2. Defina o período e a população

Quais unidades, tipos de colaborador e meses foram considerados?

3. Reconstrua o fluxo real

Não o processo desenhado, mas o que efetivamente acontece.

4. Localize esperas, retrabalho e decisões

Onde o item fica parado? Que informação volta? Quem decide?

5. Identifique feedback e atrasos

Quem percebe o erro? Quando? O aprendizado retorna à origem?

6. Formule hipóteses concorrentes

Campos ausentes, aprovações tardias, regras divergentes, falha de integração e capacidade insuficiente podem produzir sintomas semelhantes.

7. Procure evidências que diferenciem as hipóteses

Logs, horários, estados, amostras de chamados, entrevistas e testes controlados.

8. Altere uma alavanca observável

Defina o que mudará, qual efeito é esperado e que efeitos colaterais serão monitorados.

9. Verifique o sistema depois da mudança

Correção sem observação posterior é apenas uma nova hipótese em produção.

Nota Zettelkasten

ZK-010 — Pensamento sistêmico

É uma forma de investigar comportamento por relações, fronteiras, padrões,
estoques, fluxos, atrasos e ciclos de feedback, evitando explicar o todo por
um evento ou componente isolado.

Conexões:
- ZK-002 — Fronteira e ambiente
- ZK-004 — Feedback e controle
- ZK-011 — Causa e sintoma
- ZK-012 — Otimização local
- ZK-013 — Observabilidade
```---
# Capítulo 3 — Fundamentos da Computação

## 3.1 Computação não é sinônimo de computador

Computadores eletrônicos são máquinas construídas para executar processos computacionais, mas a ideia de computação é mais ampla. Computar envolve representar um problema, definir operações e executar transformações sobre representações segundo regras.

Uma planilha que calcula desconto, um algoritmo que encontra o menor caminho, um sistema que classifica chamados e um programa que comprime arquivos realizam computações diferentes. Em todos os casos, há uma passagem do mundo observado para uma representação manipulável.

Esse movimento possui quatro etapas intelectuais:

1. **Abstrair:** escolher quais aspectos do problema importam.
2. **Representar:** codificar esses aspectos como dados.
3. **Transformar:** aplicar regras e operações.
4. **Interpretar:** relacionar o resultado de volta ao problema.

Considere a prioridade de um chamado. “O serviço parou para toda a empresa” é uma situação do mundo. O sistema pode representá-la com `impacto = alto` e `urgencia = alta`. Uma regra transforma esses valores em `prioridade = crítica`. A organização interpreta o resultado como obrigação de escalonamento e atendimento dentro de um prazo.
```text
mundo observado
      ↓ abstração
dados representados
      ↓ algoritmo
novo estado/resultado
      ↓ interpretação
ação no mundo

O resultado é útil apenas se a representação preservar o que importa. Se “impacto alto” não possui definição compartilhada, o algoritmo pode executar perfeitamente uma classificação inconsistente.

3.2 Abstração: esconder detalhes sem fingir que desapareceram

Abstração reduz complexidade ao destacar propriedades relevantes e omitir detalhes temporariamente. Um mapa do metrô ignora distâncias e curvas exatas para evidenciar estações e conexões. Ele não é uma reprodução da cidade; é um modelo para uma finalidade.

Na computação, uma função enviar_notificacao(chamado) permite raciocinar sobre a intenção sem observar, naquele momento, resolução de endereço, conexão de rede, autenticação, serialização e tratamento de falhas. Os detalhes continuam existindo em camadas inferiores.

Uma abstração é boa quando:

• facilita a decisão que precisa ser tomada;
• preserva propriedades importantes;
• estabelece um contrato compreensível;
• torna explícitas suas limitações;
• permite descer de camada quando o diagnóstico exige.

Uma abstração se torna perigosa quando o profissional acredita que o detalhe oculto deixou de importar. Dizer “a aplicação salvou no banco” é suficiente para uma conversa funcional. Não é suficiente para investigar perda de dados, concorrência ou latência.

3.3 Dados, informação e conhecimento: um modelo útil, não uma lei

A conhecida hierarquia DIKW organiza dados, informação, conhecimento e sabedoria como estágios de valor crescente. Rowley mostrou como o modelo aparece de forma recorrente na literatura de gestão da informação [14]. Entretanto, revisões críticas apontam que não existe consenso universal sobre as definições nem uma transformação automática e linear de uma camada em outra [15].

Por isso, use a DIKW como lente didática, não como descrição inevitável da realidade.

Dado

Um dado é uma representação registrada: 18818, 2026-07-10 14:32, status = 5. Ele já resulta de escolhas — o que medir, como codificar e em que contexto registrar. “Dado bruto” não significa ausência total de interpretação.

Informação

Informação surge quando dados são interpretados num contexto relevante:

O chamado 18818 foi solucionado em 10 de julho de 2026 às 14h32.

Agora conhecemos entidade, relação e significado.

Conhecimento

Conhecimento envolve modelos, experiência e capacidade de usar informação para explicar ou agir:

Chamados dessa categoria costumam ser solucionados, mas reabrem porque a validação do usuário ocorre depois do encerramento automático.

Isso já contém um padrão e uma hipótese causal.

Julgamento ou sabedoria prática

Decidir alterar o fluxo exige avaliar custo, risco, evidência e consequência:

Antes de mudar o prazo global, criaremos uma etapa de confirmação apenas para essa categoria e acompanharemos reabertura e tempo total durante 30 dias.

O ponto central é que mais dados não geram automaticamente melhor decisão. Qualidade, significado, contexto, modelo e responsabilidade humana continuam necessários.

3.4 Hardware, software e firmware

Hardware é o conjunto de componentes físicos capazes de armazenar, transmitir e transformar sinais. Software é a organização lógica de instruções e dados que define comportamentos executáveis. Firmware é software fortemente associado ao controle de um dispositivo e normalmente armazenado em memória não volátil do próprio equipamento.

A frase “hardware executa, software instrui” é uma primeira aproximação. A realidade é uma cadeia de traduções e controles:

intenção do usuário
      ↓
aplicação
      ↓
bibliotecas e serviços do sistema
      ↓
sistema operacional
      ↓
instruções de máquina e controladores
      ↓
processador, memória, armazenamento e dispositivos

Essa cadeia será aberta nas próximas partes. Por enquanto, retenha duas ideias.

Primeira: software não flutua acima da infraestrutura. Uma decisão no código produz consumo de CPU, memória, armazenamento e rede.

Segunda: o mesmo comportamento aparente pode atravessar várias camadas. Quando um usuário clica em Entrar, a aplicação valida dados, consulta identidade, cria estado de autenticação, registra eventos e devolve uma resposta. Se algo falha, “o botão não funciona” é apenas o sintoma visível.

Componentes fundamentais

Essas perguntas pertencem às próximas partes do Volume I. Aqui estamos construindo o mapa; depois abriremos cada território.

3.5 O que é um programa?

Um programa é uma descrição organizada de comportamento computacional expressa de forma que possa ser traduzida ou interpretada por uma plataforma de execução. Ele contém instruções, mas pode também incluir dados, estruturas, dependências e metadados.

É comum dizer que um programa é uma “receita”. A analogia ajuda a introduzir ordem e instruções, mas falha em três pontos:

1. programas reagem a entradas e estados que não são totalmente conhecidos ao serem escritos;
2. diferentes partes podem executar concorrentemente;
3. alguns programas, como servidores, são projetados para permanecer ativos e responder continuamente, não para terminar após uma única sequência.

Também é útil distinguir programa e processo:

• o programa é a descrição armazenada;
• o processo é uma instância em execução, com estado e recursos.

A diferença será aprofundada no capítulo de sistemas operacionais. Por ora, imagine um arquivo de receita e a cozinha executando aquela receita: o mesmo texto pode originar execuções diferentes, com tempos, entradas e resultados distintos.

3.6 Da linguagem ao efeito

Considere este código em Python:

titulo = "Falha no acesso ao ERP"
impacto = "alto"
urgencia = "alta"

if impacto == "alto" and urgencia == "alta":
    prioridade = "critica"
else:
    prioridade = "normal"

print(titulo, prioridade)

O texto é código-fonte. Antes de produzir o resultado, uma implementação da linguagem precisa analisar sua estrutura, associar nomes a objetos e executar as operações segundo as regras da linguagem. A documentação de Python distingue atribuição, expressões e estruturas compostas de controle; uma atribuição avalia a expressão e associa o resultado ao alvo [16].

Para o iniciante, o fluxo lógico é:

1. associar o nome titulo a um texto;
2. associar impacto e urgencia a valores;
3. avaliar duas comparações;
4. combinar os resultados com and;
5. escolher um bloco;
6. associar prioridade ao valor correspondente;
7. produzir uma saída.

Para o profissional, surge outra camada: de onde vieram os valores? Quem definiu os valores permitidos? A regra está duplicada em outros sistemas? A saída será apenas exibida ou persistida? O que ocorrerá se o valor vier como ALTA, Alta ou vazio?

Código correto começa com significado controlado.

3.7 O que realmente acontece entre a entrada e a saída

Sem antecipar a arquitetura detalhada das próximas partes, um sistema web de chamados pode ser visualizado assim:

usuário descreve a necessidade
        ↓
interface estrutura e envia dados
        ↓
aplicação valida entrada e autorização
        ↓
regras determinam comportamento
        ↓
dados e histórico são registrados
        ↓
integrações e notificações são acionadas
        ↓
resposta volta ao usuário
        ↓
logs e métricas permitem observar o resultado

Cada seta esconde uma futura área de estudo. A função desta Parte 1 é impedir que você confunda o primeiro bloco visível com o sistema inteiro.

Nota Zettelkasten

ZK-014 — Computação

Computar envolve abstrair um problema, representá-lo, transformar a
representação por regras e interpretar o resultado de volta no contexto.

Conexões:
- ZK-015 — Abstração
- ZK-016 — Dados e significado
- ZK-017 — Programa e processo
- ZK-018 — Algoritmo
- ZK-019 — Estado
```---
# Capítulo 4 — Algoritmos e lógica

## 4.1 Antes do algoritmo: definir o problema

Um algoritmo pode estar perfeitamente escrito e ainda resolver o problema errado.

Considere a solicitação: “calcule o SLA do chamado”. Antes de construir passos, precisamos saber:

- qual tipo de SLA está em questão: resposta, solução ou ambos;
- qual calendário é utilizado;
- se o tempo corre durante pendências;
- como feriados são tratados;
- qual momento inicia a contagem;
- que mudanças de prioridade recalculam o prazo;
- como pausas e exceções ficam registradas.

Somente depois dessas decisões existe um problema computacional suficientemente definido.

Um algoritmo é um procedimento efetivo e não ambíguo para transformar entradas em saídas e resolver uma classe de problemas. Definições clássicas enfatizam passos bem definidos e término para cada entrada válida [17]. Essa noção não deve ser confundida com a execução contínua de um sistema reativo: um servidor pode permanecer ativo indefinidamente, embora utilize algoritmos terminantes para tratar requisições individuais.

## 4.2 Decomposição: transformar uma intenção em partes executáveis

“Gerenciar chamados” é amplo demais para virar código diretamente. Podemos decompor:

1. receber solicitação;
2. validar campos;
3. identificar solicitante e entidade;
4. classificar categoria;
5. calcular prioridade;
6. determinar fila responsável;
7. registrar chamado e histórico;
8. calcular prazos;
9. enviar confirmação;
10. acompanhar mudanças de estado.

Cada parte pode ser novamente decomposta. O cálculo de prioridade pode combinar impacto e urgência. A atribuição pode depender de entidade, categoria, localização e horário.

Decompor não significa quebrar até produzir centenas de fragmentos desconectados. Significa encontrar unidades com propósito, entradas, regras e saídas compreensíveis.

## 4.3 Propriedades de um algoritmo útil

### Precisão

“Atenda rapidamente” não é executável. “Defina prioridade crítica quando impacto e urgência forem altos” é mais preciso, mas ainda depende da definição desses valores.

### Entradas definidas

Quais dados são obrigatórios? Quais formatos e domínios são válidos? Uma prioridade aceita números de 1 a 5, nomes ou ambos?

### Saídas observáveis

O algoritmo produz um valor, altera um estado, registra um evento ou envia uma mensagem? Uma alteração invisível é difícil de verificar.

### Terminação quando aplicável

Uma rotina de importação precisa terminar ou falhar de forma controlada. Um laço sem condição de saída consome recursos indefinidamente.

### Correção

Para entradas válidas, o resultado atende à especificação? Correção depende da regra definida, não da aparência do código.

### Custo

Dois algoritmos podem produzir o mesmo resultado consumindo tempos e recursos muito diferentes. A análise formal de complexidade virá depois; aqui basta desenvolver o hábito de perguntar quantos itens são processados e que operações se repetem.

### Tratamento de situações inválidas

O que acontece quando o arquivo está vazio, o solicitante não existe ou a API não responde? Ignorar entradas e falhas não elimina o caso; apenas transfere a decisão para um comportamento acidental.

## 4.4 Variáveis: nomes, valores e estado

A metáfora da “caixa na memória” ajuda no primeiro contato, mas não é universalmente correta. Em Python, por exemplo, uma atribuição associa — ou **vincula** — um nome a um objeto; a documentação da linguagem descreve esse comportamento como `binding` [16]. Em linguagens e contextos diferentes, uma variável pode representar endereço, posição, referência, valor imutável ou elemento sujeito a otimizações.

Para esta etapa, adote o seguinte modelo:

> Uma variável é um nome usado por um programa para acessar um valor dentro de determinado contexto e durante determinado período de execução.
```python
chamado_id = 18818
titulo = "Acesso ao NBS"
prioridade = 3
aberto = True

Cada atribuição possui:

• nome: prioridade;
• valor atual: 3;
• tipo do valor: inteiro;
• contexto ou escopo: região do programa em que o nome pode ser usado;
• tempo de vida: período em que a associação permanece relevante.

Tipo não é decoração

O tipo determina operações possíveis e significados esperados. Somar dois inteiros, concatenar dois textos e comparar datas são operações diferentes.

quantidade = 10          # int
tempo_medio = 42.5       # float
categoria = "Sistemas"  # str
ativo = True             # bool
tecnicos = ["Ana", "Rui"]  # list

O comentário ajuda o leitor, mas é o valor que possui tipo em Python. Outras linguagens adotam modelos diferentes, e essa comparação pertencerá ao estudo de linguagens.

Estado e mudança

Variáveis permitem representar estado:

status = "novo"
status = "em_atendimento"
status = "solucionado"

Mas essa liberdade também permite transições inválidas. Um sistema real não deveria aceitar qualquer texto nem permitir que fechado volte diretamente a novo sem regra e histórico. Mais adiante, modelaremos estados e transições de modo explícito.

Rastreando valores

abertos = 3
abertos = abertos + 1
abertos = abertos - 2

A tabela de rastreamento é simples e poderosa. Pesquisas em educação de programação mostram que iniciantes frequentemente constroem modelos mentais incompletos para variáveis, atribuições e fluxo; acompanhar o estado passo a passo ajuda a tornar a execução explícita [18][19].

4.5 Expressões e operadores

Uma expressão combina valores, nomes, operadores e chamadas para produzir outro valor.

tempo_total = 120
quantidade = 4
tempo_medio = tempo_total / quantidade

A expressão tempo_total / quantidade é avaliada antes da associação a tempo_medio.

Operadores aritméticos

soma = 10 + 5
diferenca = 10 - 5
produto = 10 * 5
quociente = 10 / 5
resto = 10 % 3

Operadores de comparação

prazo_vencido = minutos_decorridos > limite_minutos
mesma_categoria = categoria == "Sistemas"
usuario_ativo = status_usuario != "bloqueado"

O resultado de uma comparação é booleano: True ou False.

Operadores lógicos

critico = impacto == "alto" and urgencia == "alta"
pode_visualizar = tecnico_responsavel or gestor_da_fila
deve_bloquear = not usuario_ativo

No código real, nomes booleanos devem deixar clara a pergunta respondida. x = True informa pouco; usuario_pode_editar = True expressa intenção.

4.6 Condições: escolher caminhos com regras explícitas

Uma estrutura condicional avalia uma expressão e escolhe qual bloco executar.

if impacto == "alto" and urgencia == "alta":
    prioridade = "critica"
elif impacto == "alto" or urgencia == "alta":
    prioridade = "alta"
else:
    prioridade = "normal"

Rastreamento de decisão

A tabela revela uma característica importante: a ordem das condições participa do comportamento. Se a regra mais ampla vier primeiro, pode capturar casos destinados a uma regra específica.

Regra de negócio não é sinônimo de if

A regra “usuários bloqueados não podem autenticar” pode ser implementada com uma condição, mas continua existindo como decisão de negócio e segurança independentemente da sintaxe. Ela precisa de origem, responsável, justificativa, versionamento e testes.

Uma boa especificação separa:

• regra: comportamento esperado no domínio;
• representação: dados necessários para avaliá-la;
• implementação: código que executa a decisão;
• evidência: teste ou registro que demonstra o resultado.

Casos de borda

Se impacto vier vazio, o código acima atribuirá prioridade normal. Isso é correto? Talvez o sistema devesse rejeitar a entrada ou marcar o chamado para triagem. O else não representa apenas “todos os outros casos desejados”; ele também recebe valores inesperados se não houver validação.

4.7 Repetições: processar coleções e controlar continuidade

Laços permitem executar um bloco para vários elementos ou enquanto uma condição permanecer verdadeira. A documentação de Python apresenta for para percorrer itens de uma sequência ou iterável e while para repetir enquanto uma condição for verdadeira [20].

for: percorra uma coleção

chamados = [18818, 18819, 18820]

for chamado_id in chamados:
    print("Processando", chamado_id)
```Rastreamento:
| Iteração | `chamado_id` | Saída |
|---:|---:|---|
| 1 | 18818 | Processando 18818 |
| 2 | 18819 | Processando 18819 |
| 3 | 18820 | Processando 18820 |

### `while`: repita sob uma condição
```python
tentativas = 0
autenticado = False

while tentativas < 3 and not autenticado:
    autenticado = verificar_credencial()
    tentativas = tentativas + 1

O laço termina quando a autenticação ocorre ou quando o limite é atingido.

Três perguntas para qualquer laço

1. Inicialização: que estado existe antes da primeira repetição?
2. Continuidade: em que condição o bloco repete?
3. Progresso: o que muda para que a condição eventualmente deixe de ser verdadeira?

Se tentativas nunca fosse incrementada e autenticado permanecesse falso, o laço não terminaria.

Erro de limite

Erros off-by-one acontecem quando a repetição executa uma vez a mais ou a menos. Eles aparecem em páginas, intervalos de datas, posições de listas e lotes de integração. Não basta olhar o código; teste o primeiro, o último, o vazio e um caso intermediário.

Repetir não significa escalar

Este código é didático:

for cliente in clientes:
    enviar_email(cliente)

Com dez clientes, pode funcionar bem. Com oitocentos mil, surgem limites de tempo, rede, provedor, falhas parciais e necessidade de retomada. A lógica básica permanece, mas a arquitetura muda. Filas, processamento em lotes e concorrência serão estudados depois.

4.8 Funções: nomear uma transformação

Embora funções sejam aprofundadas na parte de programação, introduzi-las agora melhora a decomposição.

def calcular_prioridade(impacto, urgencia):
    if impacto == "alto" and urgencia == "alta":
        return "critica"
    if impacto == "alto" or urgencia == "alta":
        return "alta"
    return "normal"

A função cria um contrato inicial:

• recebe impacto e urgencia;
• avalia regras;
• devolve uma prioridade.

Ela não diz ainda como valores inválidos serão tratados. Esse é um requisito ausente, não apenas um detalhe de código.

4.9 Do pseudocódigo ao programa

Pseudocódigo descreve lógica sem se prender completamente à sintaxe de uma linguagem. Ele é útil para discutir regras com pessoas técnicas e não técnicas, desde que permaneça preciso.

ALGORITMO AbrirChamado

RECEBER solicitante, entidade, título, descrição, impacto, urgência

SE solicitante não estiver ativo
    REJEITAR solicitação e registrar motivo
FIM_SE

VALIDAR campos obrigatórios
CALCULAR prioridade a partir de impacto e urgência
DETERMINAR fila a partir de entidade e categoria
REGISTRAR chamado e evento inicial

SE prioridade for crítica
    SOLICITAR notificação de escalonamento
FIM_SE

DEVOLVER identificador e prazo previsto
FIM_ALGORITMO

O pseudocódigo revela decisões, mas ainda esconde questões:

• a validação acumula todos os erros ou interrompe no primeiro;
• registro e histórico precisam ocorrer juntos;
• o que acontece se a notificação falhar;
• como evitar duplicidade se o usuário enviar duas vezes;
• de onde vêm entidade e categoria;
• quem pode informar impacto e urgência.

Esse é um resultado saudável. Um modelo útil não encerra a análise; ele torna as próximas perguntas visíveis.

4.10 Depuração como investigação do estado

Debugging não é adivinhar linhas até o erro desaparecer. É comparar comportamento esperado e observado, localizar a primeira divergência e testar hipóteses.

Considere:

total = 0
tempos = [20, 40, 60]

for tempo in tempos:
    total = tempo

media = total / len(tempos)
print(media)

O resultado será 20.0, não 40.0. O laço substitui total a cada iteração; ao final, total vale 60.

Tabela de rastreamento:

Correção:

total = 0
tempos = [20, 40, 60]

for tempo in tempos:
    total = total + tempo

media = total / len(tempos)
print(media)

Agora aparece outro caso: se tempos estiver vazio, haverá divisão por zero. A correção de um defeito não prova a correção de todos os casos.

Método de diagnóstico

1. Declare a entrada usada.
2. Declare o resultado esperado.
3. Reproduza o comportamento.
4. Observe valores intermediários.
5. Encontre a primeira divergência.
6. Formule uma hipótese causal.
7. Faça a menor alteração capaz de testá-la.
8. Execute casos normais, limites e inválidos.
9. Verifique se a correção criou regressões.

Essa disciplina conecta lógica de programação, pensamento sistêmico e sustentação de sistemas.

Nota Zettelkasten

ZK-018 — Algoritmo

Procedimento efetivo e não ambíguo que transforma entradas em saídas para
resolver uma classe de problemas. Sua correção depende de uma especificação;
se o problema estiver mal definido, o código pode executar a regra errada.

Conexões:
- ZK-006 — Necessidade e solução
- ZK-019 — Estado
- ZK-020 — Variável e vinculação
- ZK-021 — Condição
- ZK-022 — Repetição
- ZK-023 — Depuração
```---
# Integração dos capítulos — de uma necessidade ao comportamento executável

Os quatro capítulos formam uma única progressão:
```text
uma pessoa percebe um problema
        ↓
o analista investiga necessidade, contexto e valor
        ↓
a fronteira do sistema é definida
        ↓
pessoas, processos, dados, regras e tecnologia são relacionados
        ↓
entradas, estados, transformações, saídas e feedback são modelados
        ↓
regras são expressas como lógica verificável
        ↓
algoritmos organizam transformações
        ↓
programas executam parte do comportamento
        ↓
o resultado é observado no sistema real
        ↓
feedback inicia uma nova análise

Observe onde o código aparece: ele é essencial, mas não é o começo nem o fim.

Exercícios da Parte 1

Nível 1 — Compreensão

Exercício 1 — Sistema e software

Explique por que um sistema de folha de pagamento não se resume ao programa usado pelo RH. Inclua pelo menos pessoas, processos, dados, regras, controles e ambiente.

Exercício 2 — Fronteira

Analise um sistema de login sob duas fronteiras:

1. apenas a aplicação web;
2. todo o ecossistema corporativo de identidade.

Mostre o que entra e sai do sistema em cada recorte.

Exercício 3 — DIKW sob crítica

Use três registros de chamados para construir um exemplo de dado, informação e conhecimento. Depois explique por que essa transformação não ocorre automaticamente.

Exercício 4 — Programa e algoritmo

Explique por que um servidor pode permanecer executando indefinidamente sem invalidar a ideia de que os algoritmos usados para processar requisições individuais devem terminar.

Nível 2 — Aplicação

Exercício 5 — Da solução aparente à necessidade

Demanda: “Adicione um campo obrigatório de telefone no cadastro de todos os usuários.”

Identifique:

• problema observado;
• necessidade provável;
• stakeholders;
• restrições de privacidade;
• alternativas à obrigatoriedade global;
• evidência que demonstraria valor.

Exercício 6 — Entrada, estado, saída e feedback

Escolha um aplicativo de transporte, e-commerce ou sistema corporativo e descreva:

• propósito;
• fronteira;
• ambiente;
• entradas;
• transformações;
• estados;
• saídas;
• feedback;
• controles.

Exercício 7 — Tabela de decisão

Construa uma tabela para uma política com três níveis de impacto e três níveis de urgência. Defina a prioridade resultante e justifique os casos de borda.

Exercício 8 — Rastreamento

Sem executar o código, complete uma tabela com os valores de i, total e quantidade após cada iteração:

valores = [4, 7, 2, 9]
total = 0
quantidade = 0

for i in valores:
    if i > 5:
        total = total + i
        quantidade = quantidade + 1

Depois explique o que o algoritmo calcula e o que ocorreria se nenhum valor fosse maior que 5.

Nível 3 — Análise profissional

Exercício 9 — Métrica que distorce comportamento

Uma equipe passa a ser avaliada apenas por “quantidade de chamados fechados por técnico”. Construa:

• um possível ciclo reforçador indesejado;
• dois indicadores de equilíbrio;
• uma hipótese de melhoria;
• um plano de observação posterior.

Exercício 10 — Incidente recorrente

O ERP fica lento toda segunda-feira entre 8h e 10h. Crie pelo menos quatro hipóteses concorrentes envolvendo demanda, processo, aplicação e infraestrutura. Para cada hipótese, indique uma evidência capaz de fortalecê-la ou enfraquecê-la. Não tente resolver o caso ainda.

Active Recall — responda sem consultar

1. Qual é a diferença entre uma demanda, uma necessidade e uma solução?
2. Por que “implantar uma ferramenta” não é um propósito suficiente?
3. O que muda quando alteramos a fronteira de um sistema?
4. Por que um sistema de informação é sociotécnico?
5. Como estado difere de entrada e saída?
6. O que caracteriza um ciclo de feedback balanceador?
7. Como uma métrica local pode piorar o resultado global?
8. Que limitações existem no modelo Entrada–Processamento–Saída?
9. Por que a DIKW deve ser usada como modelo didático, não como lei?
10. O que uma abstração preserva e o que ela omite?
11. Qual é a diferença introdutória entre programa e processo?
12. Por que “variável é uma caixa na memória” é apenas uma metáfora?
13. O que deve mudar dentro de um while para que ele progrida?
14. Como a ordem de condições pode alterar o resultado?
15. Por que um algoritmo correto pode entregar uma solução errada?
16. Qual é a primeira divergência que você procuraria ao depurar um cálculo?
17. Como critérios de aceitação transformam uma intenção em comportamento verificável?
18. Por que uma falha de notificação não deveria necessariamente desfazer a criação de um chamado?

Autoexplicação — teste seu modelo mental

Escolha uma afirmação e explique-a em voz alta por três minutos:

“A tela é uma interface com o sistema; não é o sistema.”

“Dados não sobem automaticamente uma pirâmide até virar boa decisão.”

“Um erro visível numa camada pode ter sido produzido por relações em outra.”

Depois, avalie sua explicação:

• defini os termos técnicos;
• usei um exemplo real;
• mostrei causa e efeito;
• indiquei pelo menos uma limitação;
• conectei o conceito a outro capítulo;
• consegui responder a uma objeção.

Se algum item estiver ausente, volte apenas ao trecho necessário e tente de novo.

Checklist profissional para a primeira análise

Propósito e valor

• Que problema ou oportunidade motivou a demanda?
• Quem percebe o problema e quem é afetado?
• Que resultado observável justificará a mudança?
• A solução sugerida é a única alternativa ou apenas a primeira ideia?

Fronteira e contexto

• O que está dentro do sistema analisado?
• O que ficou fora deliberadamente?
• Que sistemas, fornecedores, normas e processos compõem o ambiente?
• Em que período e volume o comportamento ocorre?

Pessoas e responsabilidades

• Quem solicita, aprova, executa, recebe e audita?
• Quem possui conhecimento que não está documentado?
• Quem pode decidir sobre regras e exceções?
• Quem arcará com custos ou riscos da mudança?

Dados e regras

• Quais dados entram, de onde vêm e o que significam?
• Que campos são obrigatórios e por qual motivo?
• Quais valores e estados são válidos?
• Que regras calculam, autorizam, restringem ou classificam?
• Como exceções são tratadas e auditadas?

Fluxo e comportamento

• Que evento inicia o processo?
• Que estados o item percorre?
• Onde existem filas, esperas, dependências e retrabalho?
• Quais são as saídas principais e secundárias?
• O que ocorre em falha parcial?

Feedback e controle

• Como saberemos que o sistema funciona?
• Que indicadores podem ser manipulados ou distorcer comportamento?
• Quem recebe o feedback e que ação pode tomar?
• Quando o efeito da mudança deverá aparecer?
• Que consequência indesejada também será observada?

Implementação e validação

• O comportamento esperado é testável?
• Há critérios para casos normais, limites e inválidos?
• As decisões importantes estão documentadas?
• Existe forma segura de reverter ou corrigir a mudança?

Projeto prático — Especificação inicial de um sistema de chamados

Objetivo

Produzir uma especificação conceitual e lógica para um pequeno sistema de chamados. O projeto não exige interface gráfica nem banco de dados. O foco é demonstrar análise, modelagem e raciocínio computacional.

Cenário

Uma empresa com três departamentos recebe solicitações por e-mail, mensagens e conversas presenciais. Pedidos são esquecidos, prioridades não são comparáveis e a gestão não consegue medir tempo ou volume. A empresa deseja centralizar o atendimento.

Entregável 1 — Problema e resultado

Escreva:

• situação atual;
• problemas observados;
• necessidades;
• restrições;
• resultado esperado;
• três métricas com possíveis efeitos colaterais.

Entregável 2 — Mapa do sistema

Defina:

• propósito;
• fronteira;
• ambiente;
• stakeholders;
• pessoas, processos, dados, regras e tecnologia;
• entradas, estados, saídas, feedback e controles.

Entregável 3 — Modelo de chamado

Especifique ao menos:

Chamado
- id
- entidade
- solicitante
- título
- descrição
- categoria
- impacto
- urgência
- prioridade
- status
- responsável
- data de criação
- prazo
- histórico

Para cada atributo, informe tipo conceitual, obrigatoriedade e significado.

Entregável 4 — Estados e transições

Modele um fluxo inicial:

novo → atribuído → em_atendimento → solucionado → fechado
                     ↓                 ↑
                  pendente ────────────┘

Depois responda:

• quem pode realizar cada transição;
• que dados são exigidos;
• quais transições são proibidas;
• como reabertura será tratada;
• que eventos entram no histórico.

Entregável 5 — Tabela de prioridade

Combine impacto e urgência. Não use apenas uma lista: explique por que cada combinação produz determinada prioridade e quem pode alterar o resultado.

Entregável 6 — Pseudocódigo

Crie algoritmos para:

1. validar uma solicitação;
2. calcular prioridade;
3. atribuir a fila;
4. registrar mudança de estado;
5. identificar chamados próximos do vencimento.

Cada algoritmo deve declarar entradas, saídas, regras e tratamento de valores inválidos.

Entregável 7 — Casos de teste

Crie ao menos oito casos:

• dois normais;
• dois de limite;
• dois inválidos;
• um de permissão;
• um de falha de integração.

Entregável 8 — Feedback

Defina um pequeno painel com:

• volume recebido;
• tempo até primeira resposta;
• tempo até solução;
• taxa de reabertura;
• satisfação;
• distribuição por categoria;
• chamados sem responsável.

Para cada indicador, escreva uma decisão possível e um risco de interpretação.

Critérios de avaliação

Resumo da Parte 1

Análise e Desenvolvimento de Sistemas começa quando uma necessidade é investigada antes de ser transformada em solução. Um sistema não é apenas a aplicação visível: é um conjunto delimitado de elementos e relações que produz comportamento em determinado ambiente. Em sistemas de informação, pessoas, processos, dados, regras e tecnologia participam conjuntamente do resultado.

O pensamento sistêmico amplia a análise de eventos para padrões e estruturas. Ele torna visíveis fronteiras, atrasos, feedback, controles e efeitos não intencionais. Essa visão explica por que otimizar um formulário, uma equipe ou uma métrica pode degradar o serviço completo.

A computação transforma representações por meio de regras. Para fazer isso, abstraímos aspectos do mundo, representamos dados, executamos operações e interpretamos resultados. Hardware e software participam de uma cadeia de camadas; programa e execução não são a mesma coisa; dado, informação e conhecimento são distinções úteis, mas não formam uma escada automática para decisões corretas.

Algoritmos organizam transformações. Variáveis representam associações e estado; expressões produzem valores; condições selecionam caminhos; repetições percorrem coleções ou mantêm uma ação enquanto uma condição permanece verdadeira. O código implementa decisões, mas não cria sozinho o significado dessas decisões.

A ideia central pode ser condensada assim:

Um profissional de sistemas não apenas escreve instruções para uma máquina. Ele constrói e testa modelos sobre como uma realidade deve ser representada, transformada e observada.

Limites desta parte e continuidade do Volume I

Esta parte apresentou deliberadamente apenas o mapa conceitual dos componentes técnicos. Não aprofundou:

• processos, memória virtual, filesystem e escalonamento;
• endereçamento, DNS, TCP, HTTP e roteamento;
• arquitetura cliente-servidor;
• bancos de dados, transações, índices e consultas;
• APIs, contratos, autenticação e integrações;
• estruturas de dados e análise de complexidade;
• arquitetura, testes e implantação de software.

Esses assuntos dependem da base construída aqui e serão tratados em suas partes próprias, preservando a progressão do Volume I.

Próxima parte

Na Parte 2, acompanharemos o caminho entre uma ação do usuário e a resposta do sistema. Sistemas operacionais, processos, memória, redes, DNS, HTTP, arquitetura cliente-servidor, APIs e persistência serão introduzidos como componentes relacionados de uma execução real.

A pergunta orientadora será:

O que acontece, camada por camada, entre o clique do usuário e o resultado aparecer?

Referências e leituras recomendadas

Currículos, normas e documentação profissional

[1] ACM & IEEE Computer Society. Computing Curricula 2020: Paradigms for Global Computing Education. 2020. https://www.acm.org/binaries/content/assets/education/curricula-recommendations/cc2020.pdf

[2] ACM & AIS. IS2020: A Competency Model for Undergraduate Programs in Information Systems. 2020/2021. https://is2020.hosting2.acm.org/wp-content/uploads/2021/01/IS-2020-Final-Draft-Report.pdf

[5] ISO/IEC/IEEE. 15288:2023 — Systems and software engineering — System life cycle processes. 2023. https://www.iso.org/standard/81702.html

[9] International Institute of Business Analysis. The Business Analysis Standard e Business Analysis Core Concept Model. https://www.iiba.org/professional-development/knowledge-centre/ba-connection/baccm-overview---the-core-concepts-business-analysis-core-concept-model/

[10] IEEE Computer Society. Guide to the Software Engineering Body of Knowledge — SWEBOK, versão 4.0. 2024. https://www.computer.org/education/bodies-of-knowledge/software-engineering

[16] Python Software Foundation. The Python Language Reference — Assignment statements and execution model. https://docs.python.org/3/reference/simple_stmts.html e https://docs.python.org/3/reference/executionmodel.html

[20] Python Software Foundation. The Python Tutorial — More Control Flow Tools. https://docs.python.org/3/tutorial/controlflow.html

Sistemas, computação e engenharia

[4] Bertalanffy, Ludwig von. General System Theory: Foundations, Development, Applications. George Braziller, 1968.

[11] Senge, Peter M. The Fifth Discipline: The Art & Practice of the Learning Organization. Doubleday, 1990.

[12] Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.

[13] Wiener, Norbert. Cybernetics: Or Control and Communication in the Animal and the Machine. MIT Press, 1948.

[17] Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford. Introduction to Algorithms. 4ª ed. MIT Press, 2022.

Knuth, Donald E. The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3ª ed. Addison-Wesley, 1997.

Pressman, Roger S.; Maxim, Bruce R. Software Engineering: A Practitioner’s Approach. 9ª ed. McGraw-Hill, 2019.

Sommerville, Ian. Software Engineering. 10ª ed. Pearson, 2016.

Brookshear, J. Glenn; Brylow, Dennis. Computer Science: An Overview. 13ª ed. Pearson, 2019.

Aprendizagem e educação em computação

[3] Schmidt, Johannes F. K. Niklas Luhmann’s Card Index: Thinking Tool, Communication Partner, Publication Machine. Rethinking History, 22(1), 53–70, 2018. https://doi.org/10.1080/13642529.2017.1383785

[6] Chi, Michelene T. H.; Bassok, Miriam; Lewis, Matthew W.; Reimann, Peter; Glaser, Robert. Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems. Cognitive Science, 13(2), 145–182, 1989. https://doi.org/10.1207/s15516709cog1302_1

[7] Karpicke, Jeffrey D.; Blunt, Janell R. Retrieval Practice Produces More Learning than Elaborative Studying with Concept Mapping. Science, 331(6018), 772–775, 2011. https://doi.org/10.1126/science.1199327

[8] Cepeda, Nicholas J.; Pashler, Harold; Vul, Edward; Wixted, John T.; Rohrer, Doug. Distributed Practice in Verbal Recall Tasks: A Review and Quantitative Synthesis. Psychological Bulletin, 132(3), 354–380, 2006. https://doi.org/10.1037/0033-2909.132.3.354

Dunlosky, John; Rawson, Katherine A.; Marsh, Elizabeth J.; Nathan, Mitchell J.; Willingham, Daniel T. Improving Students’ Learning With Effective Learning Techniques. Psychological Science in the Public Interest, 14(1), 4–58, 2013. https://doi.org/10.1177/1529100612453266

[18] Robins, Anthony; Rountree, Janet; Rountree, Nathan. Learning and Teaching Programming: A Review and Discussion. Computer Science Education, 13(2), 137–172, 2003. https://doi.org/10.1076/csed.13.2.137.14200

[19] Sorva, Juha. Notional Machines and Introductory Programming Education. ACM Transactions on Computing Education, 13(2), Article 8, 2013. https://doi.org/10.1145/2483710.2483713

Informação e conhecimento

[14] Rowley, Jennifer. The Wisdom Hierarchy: Representations of the DIKW Hierarchy. Journal of Information Science, 33(2), 163–180, 2007. https://doi.org/10.1177/0165551506070706

[15] Frické, Martin. The Knowledge Pyramid: The DIKW Hierarchy. Knowledge Organization, 46(1), 33–46, 2019. https://doi.org/10.5771/0943-7444-2019-1-33

Ficha editorial da Parte 1

Tema central: fundamentos de Análise e Desenvolvimento de Sistemas.

Tese: a competência profissional em sistemas nasce da capacidade de conectar necessidade, contexto, modelo, lógica, implementação e feedback — não do domínio isolado de uma ferramenta.

Público: estudantes iniciantes de ADS e profissionais de suporte ou sustentação em transição para análise e desenvolvimento.

Nível: multicamadas, com intuição inicial e aprofundamento profissional.

Palavra-chave principal: fundamentos de Análise e Desenvolvimento de Sistemas.

Palavras-chave secundárias: pensamento sistêmico, sistema de informação, analista de sistemas, fundamentos da computação, algoritmos, lógica de programação, variáveis, condições, repetições.