Exercícios resolvidos: panorama, história e fundamentos da Engenharia de Software

Explicação

1. Organização da cadeia causal

O ponto de partida é a mudança de contexto descrita em B. A adoção em seis campi acrescenta usuários, regras, integrações e consequências.

Essas condições expõem dificuldades recorrentes, apresentadas em C. As correções deixam de ser locais e passam a afetar comportamentos relacionados.

A afirmação D registra o reconhecimento do limite encontrado. Programar ainda implementa as mudanças, mas não organiza sozinho requisitos, riscos, responsabilidades e verificações.

A expressão “Em resposta” torna A a consequência desse reconhecimento. A equipe passa a controlar o trabalho e a evolução do produto de forma mais sistemática.

A ordem é:

$$B \rightarrow C \rightarrow D \rightarrow A$$

2. Relação entre escala e Engenharia de Software

O código inicial não ficou necessariamente maior apenas por ter sido adotado. O contexto, porém, ficou mais exigente. Uma reserva incorreta agora pode afetar vários cursos, campi e usuários. As integrações e regras também aumentam as dependências que precisam ser compreendidas antes de uma alteração.

A abordagem de engenharia responde a esse aumento de risco e coordenação. Ela inclui especificação, implementação, verificação, registro de decisões, operação e evolução sob restrições reais.

3. Correção da interpretação histórica

“Crise do software” nomeia dificuldades recorrentes para planejar, produzir e evoluir determinadas aplicações maiores com qualidade, custo e prazo razoáveis. O termo não afirma que todo software fracassava.

A reunião da OTAN de 1968 ajudou a consolidar o reconhecimento do problema e a necessidade de uma abordagem de engenharia. Métodos, padrões, testes, ferramentas e técnicas de manutenção evoluíram ao longo das décadas. O evento não criou diretamente todas essas técnicas.

Resposta esperada

1. Ordem: $B \rightarrow C \rightarrow D \rightarrow A$.
2. Motivo para a abordagem de engenharia: a adoção em seis campi aumentou usuários, regras, integrações, riscos e necessidade de coordenação. A programação continuou necessária, mas deixou de controlar sozinha requisitos, dependências, verificações, decisões e evolução. Por isso, a equipe precisou especificar comportamentos, verificar mudanças, registrar decisões e acompanhar o sistema em uso.
3. Correção histórica: a crise do software descreve dificuldades recorrentes para planejar, produzir e evoluir determinadas aplicações maiores com qualidade, custo e prazo razoáveis. Ela não significa que todo software fracassava. A reunião da OTAN de 1968 consolidou o reconhecimento do problema e a defesa de uma abordagem de engenharia. As técnicas modernas evoluíram ao longo das décadas e não foram criadas diretamente naquele evento.

Explicação

1. Função local

Escrever uma função é uma atividade de Programação quando considerada isoladamente. A ação produz código, mas o enunciado não informa requisito, critério de verificação, contexto de uso ou controle da mudança.

2. Regra acadêmica

Definir quando a segunda solicitação é permitida pertence à Engenharia de Software. A ação especifica o comportamento esperado antes da implementação.

3. Condição implementada e verificada

Alterar o código conforme uma regra e verificar o resultado envolve Ambas. A programação implementa a condição. A Engenharia de Software relaciona essa implementação a um requisito e a uma evidência de correção.

4. Caminhos reais de ocorrência

Reproduzir o problema em diferentes caminhos pertence à Engenharia de Software. A ação amplia a verificação além de uma função local e considera o sistema em seu contexto de uso.

Esse conjunto aumenta a confiança nos caminhos identificados e testados. Ele não prova a ausência de qualquer defeito possível.

5. Registro da decisão

Registrar regra, caminhos e resultados pertence à Engenharia de Software. O registro preserva a motivação da mudança, a evidência obtida e a responsabilidade sobre a decisão.

6. Acompanhamento em uso

Medir duplicidades depois da liberação pertence à Engenharia de Software. A ação observa o produto em operação e fornece evidência para novas decisões.

Resposta esperada

1. Programação: escrever isoladamente a função produz código, sem abranger definição da regra, contexto de uso ou controle da mudança.
2. Engenharia de Software: definir duplicidade, troca de turma e rematrícula permitida especifica o comportamento esperado antes da implementação.
3. Ambas: alterar a condição é programação. Relacionar a alteração à regra e verificar o comportamento esperado integra essa programação ao trabalho de engenharia.
4. Engenharia de Software: reproduzir o problema nos caminhos reais verifica o comportamento do sistema além de uma função local, sem provar a ausência de todos os defeitos possíveis.
5. Engenharia de Software: registrar a regra, os caminhos e os resultados preserva a decisão e as evidências da correção.
6. Engenharia de Software: medir a recorrência depois da liberação acompanha o produto em uso e orienta sua evolução.

Explicação

1. Associação das evidências

A tabela compara a evidência, o atributo principal e o vínculo que sustenta a classificação.

Evidência	Atributo principal	Justificativa
E1	Facilidade de mudança	A duplicação e a ausência da intenção registrada tornam a alteração lenta e aumentam o risco de regressão.
E2	Confiança e proteção	Uma pessoa sem autorização consegue acessar dados de outro chamado.
E3	Eficiência	Na carga prevista, o sistema não responde a tempo e deixa solicitações expirarem.
E4	Aceitabilidade	A interface móvel e as mensagens não permitem que o público conclua a tarefa com compreensão.

Uma evidência pode afetar outros atributos. Por exemplo, a expiração de solicitações também prejudica a experiência de uso. A classificação registra o atributo principal para manter o diagnóstico verificável.

2. Decisão sobre o conflito entre atributos

A proposta aumenta o tempo médio em:

$$170 - 120 = 50\text{ milissegundos}$$

O novo tempo permanece abaixo do limite:

$$170 < 250$$

A verificação busca impedir o acesso não autorizado, que o enunciado declara como prioritário. Portanto, existe justificativa para avançar a proposta aos testes. A decisão ainda precisa confirmar, nos cenários de carga previstos, que a autorização funciona e que o tempo continua dentro do limite.

Não se deve concluir que a mudança está aprovada para produção apenas com a estimativa. O próximo passo é verificar o ganho de proteção e o custo de desempenho.

Resposta esperada

• E1, facilidade de mudança: a regra duplicada em nove telas e a ausência de registro sobre qual comportamento preservar tornam a alteração lenta e sujeita a regressões.
• E2, confiança e proteção: um estudante acessa dados de outra pessoa sem autorização.
• E3, eficiência: sob a carga prevista, o tempo aumenta para 12 segundos e algumas solicitações expiram.
• E4, aceitabilidade: no celular, o botão fica inacessível e os códigos de erro não orientam o estudante a concluir a tarefa.
• Decisão: a verificação de autorização deve avançar para testes. O tempo estimado aumenta em 50 milissegundos, de 120 para 170 milissegundos, mas permanece abaixo do limite de 250 milissegundos. Como impedir acesso indevido é prioritário, os testes devem confirmar a proteção nos cenários previstos e verificar se o tempo permanece dentro do limite. Esses dados ainda não justificam uma liberação direta para produção.

Explicação

1. Classificação das evidências

• A evidência A corresponde às pessoas, pois identifica quem solicita, interpreta, produz, verifica, aprova e usa.
• A evidência B corresponde ao método, pois orienta como executar uma atividade técnica de verificação.
• A evidência C corresponde à organização, pois define restrições, responsabilidades e autoridade.
• A evidência D corresponde ao produto, pois descreve o que será entregue, usado e mantido.
• A evidência E corresponde à ferramenta, pois oferece apoio automatizado ao registro e à execução de testes.
• A evidência F corresponde ao processo, pois organiza atividades, decisões e pontos de controle.

2. Método e ferramenta

O método da evidência B orienta a elaboração dos casos com datas anterior, igual e posterior ao limite. Ele ajuda a decidir o que verificar.

A ferramenta da evidência E registra a solicitação e executa os testes que alguém configurou. Ela apoia o trabalho, mas não define a regra, não escolhe os casos necessários e não decide se o resultado é aceitável.

3. Relações no ciclo

O mapa precisa conter os seis elementos pedidos e usar verbos nas relações. Uma construção coerente liga a organização às decisões das pessoas, as pessoas ao processo, o processo aos métodos e às ferramentas, e estes ao produto. Por fim, o produto em uso devolve resultados e falhas às pessoas.

O processo deve ser proporcional ao risco. Uma data exibida incorretamente pode impedir entregas. Por isso, esclarecer a regra, verificar datas de limite e registrar a aprovação são controles pertinentes ao dano possível.

Resposta esperada

1. Classificação e justificativa:

   • A, pessoas: estudantes, secretaria, desenvolvimento, validação e aprovação interpretam, produzem, verificam, decidem e usam.
   • B, método: a orientação para testar datas anterior, igual e posterior ao limite define como executar a verificação.
   • C, organização: prazo, orçamento e autoridade de aprovação definem restrições e responsabilidades.
   • D, produto: o portal, os relatórios, as mensagens e os artefatos necessários para manutenção constituem o que será usado e mantido.
   • E, ferramenta: o sistema registra a solicitação e automatiza a execução dos testes configurados.
   • F, processo: o fluxo de esclarecimento, alteração, verificação, aprovação e liberação organiza o trabalho e seus pontos de controle.

2. Método e ferramenta: o método da evidência B orienta quais casos elaborar e como verificar a regra. A ferramenta da evidência E apoia o registro e a execução, mas não define a regra, não escolhe os casos e não decide se o resultado é aceitável.

3. Mapa de relações:

flowchart TD
    A["Organização"] -->|"condiciona decisões"| B["Pessoas"]
    B -->|"participam do"| C["Processo"]
    C -->|"organiza a aplicação de"| D["Método"]
    C -->|"organiza o uso de"| E["Ferramenta"]
    D -->|"orienta a alteração e a verificação do"| F["Produto"]
    E -->|"apoia a alteração e a verificação do"| F
    F -->|"produz resultados e falhas para"| B

O mapa representa um ciclo adaptável porque os resultados e as falhas do produto podem exigir a revisão de decisões, atividades, métodos ou ferramentas pertinentes, sem impor o reinício de uma ordem fixa.

Explicação

1. Sintomas observáveis

Três sintomas podem ser descritos sem explicação causal:

1. um código declarado válido é recusado e o sistema exibe E17;
2. depois de reenvios no celular, existem dois pedidos ativos para a mesma tentativa de compra;
3. no pico observado, a operação leva 8 segundos diante de um limite de 2 segundos.

Essas descrições registram o que aconteceu. Elas não afirmam por que aconteceu.

2. Separação por nível

Produto: recusa do código válido, mensagem E17, tela sem resposta, pedidos duplicados e tempo de 8 segundos.

Processo: liberação sem registro da regra, ausência de evidência dos testes e verificação restrita a um pedido comum no computador.

Pessoas: presunção de que E17 seria compreensível e falha na comunicação do contorno descoberto pelo atendimento.

Organização: prazo de um dia e ausência de definição sobre a autoridade que aprovaria a regra.

As categorias organizam a análise, mas não formam caixas isoladas. A falta de autoridade, por exemplo, pode influenciar o processo de aprovação.

3. Atributos afetados pelas evidências

Facilidade de mudança: a regra de desconto não foi registrada. Uma nova correção precisa reconstruir a intenção e corre maior risco de preservar o comportamento errado.

Confiança e proteção: os pedidos duplicados mostram que o comportamento não preserva a expectativa de um único pedido ativo por tentativa. A duplicidade pode gerar cobrança ou preparação indevida.

Eficiência: o tempo observado de 8 segundos ultrapassa o limite de 2 segundos na carga de pico.

Aceitabilidade: a mensagem E17 não orienta a pessoa, e a tela móvel sem resposta incentiva tentativas repetidas sem confirmação clara.

4. Condições contribuintes

As evidências permitem formular relações que precisam de verificação:

• a regra não registrada pode ter permitido interpretações diferentes sobre a validade do desconto;
• a verificação restrita ao computador pode ter deixado o comportamento móvel e o reenvio sem observação;
• a comunicação interrompida pode ter impedido que a equipe usasse o conhecimento do atendimento;
• o prazo curto e a autoridade indefinida podem ter reduzido os controles antes da liberação;
• o tempo elevado pode envolver código, consultas, configuração, arquitetura ou infraestrutura. As medidas disponíveis ainda não localizam o gargalo.

Nenhum desses itens deve ser apresentado como causa confirmada antes da verificação.

5. Primeira ação verificável

A primeira ação pode ser uma reprodução controlada dos caminhos já indicados pelas evidências:

1. executar um pedido com código válido no computador e no celular;
2. em cada ambiente, executar o envio normal, um reenvio depois de espera e dois envios simultâneos;
3. registrar mensagem exibida, quantidade de pedidos ativos e tempo de resposta;
4. comparar os resultados com estes critérios: aceitar o código declarado válido, manter somente um pedido ativo, apresentar orientação compreensível e responder em até 2 segundos na carga definida.

A ação produz uma tabela de resultados observáveis. Ela permite localizar em quais caminhos cada sintoma aparece e fornece uma referência para verificar uma correção posterior. Ainda não prova qual componente causou o problema.

Resposta esperada

1. Sintomas observáveis: um código declarado válido é recusado com E17. Depois de reenvios no celular, surgem dois pedidos ativos para a mesma tentativa. No pico observado, a operação leva 8 segundos diante do limite de 2 segundos. Essas descrições não afirmam as causas.
2. Níveis: no produto estão a recusa do código, a mensagem E17, a tela sem resposta, a duplicidade e o tempo de 8 segundos. No processo estão a regra não registrada, a falta de evidências dos testes e a verificação restrita a um pedido comum no computador. Em pessoas estão a presunção sobre a mensagem e a comunicação interrompida entre atendimento e desenvolvimento. Na organização estão o prazo de um dia e a indefinição da autoridade de aprovação.
3. Atributos e evidências: a facilidade de mudança é prejudicada pela regra não registrada, pois a equipe precisa reconstruir a intenção e pode preservar o comportamento errado. A confiança e proteção são afetadas pelos pedidos duplicados, que violam a expectativa de um único pedido ativo e podem gerar cobrança ou preparação indevida. A eficiência é afetada porque 8 segundos ultrapassam o limite de 2 segundos. A aceitabilidade é afetada porque E17 não orienta o estudante e a tela sem resposta incentiva reenvios.
4. Condições contribuintes possíveis: a regra não registrada pode ter permitido interpretações diferentes. A verificação restrita ao computador pode ter omitido o comportamento móvel e o reenvio. A falha de comunicação pode ter impedido o uso do contorno conhecido. O prazo curto e a autoridade indefinida podem ter reduzido os controles. O tempo elevado ainda pode envolver código, consultas, configuração, arquitetura ou infraestrutura. As evidências não confirmam uma causa única.
5. Primeira ação verificável: executar pedidos com código válido no computador e no celular, usando envio normal, reenvio depois de espera e dois envios simultâneos. Registrar ambiente, mensagem exibida, quantidade de pedidos ativos e tempo de resposta. Considerar o resultado satisfatório quando o código válido for aceito, houver somente um pedido ativo, a mensagem orientar a pessoa e o tempo permanecer em até 2 segundos na carga definida.