Exercícios — Aula 4: Dimensões Humanas, Sociais e Éticas da Engenharia de Software

Computação e Sociedade

Autor

Marcos M. Raimundo — Instituto de Computação, UNICAMP

Questões discursivas

Explique, com suas próprias palavras, as duas premissas da Lei de Conway e como elas levam à “Manobra Inversa de Conway” — a ideia de que, para mudar a arquitetura de um sistema de forma duradoura, é preciso mudar primeiro a estrutura das equipes. Use um exemplo próprio (pode ser fora do exemplo do compilador COBOL/ALGOL) para ilustrar sua resposta.
A aula apresenta a elicitação de requisitos como um processo social, não uma extração neutra, conectando essa ideia ao enquadramento de Data Feminism sobre como dados nunca são neutros. Escolha um cenário de coleta de requisitos (pode ser fora da computação — por exemplo, uma política pública, uma pesquisa acadêmica, um produto qualquer) e argumente quem, nesse cenário, provavelmente ficaria de fora de “quem conta como usuário/afetado”, e o que isso mudaria no resultado final.
A aula propõe uma cadeia de tradução — compromisso ético/social → Requisito Não-Funcional testável → Decisão de Arquitetura (ADR) → porta de processo (gate de CI) — e conecta o risco de essa cadeia falhar ao mesmo mecanismo da Lei de Conway (um requisito “cai no buraco” quando não há um time responsável pela fronteira, do mesmo jeito que uma interface técnica cai quando não há comunicação entre equipes). Escolha um compromisso ético ou social (pode ser diferente de acessibilidade) e desenvolva, passo a passo, como ele se traduziria nas quatro etapas da cadeia — e o que, especificamente, precisaria existir na organização para que ele não “caísse no buraco”.

Questões de Verdadeiro/Falso

Cada bloco de 4 itens trata do mesmo tema. A questão só é considerada correta se todos os 4 itens forem julgados corretamente (deixar em branco tem penalidade de 20% da nota da questão).

Teste 1 — Papéis da indústria e a cadeia de tradução de um pedido do usuário

□ Se uma organização substituísse toda a cadeia de papéis (PM, dev, QA, UX, SRE) por um único generalista responsável por tudo, a qualidade final do sistema aumentaria necessariamente, porque eliminaria qualquer perda de informação entre etapas.
□ No limite em que um time de operações/SRE nunca é consultado antes do lançamento de uma funcionalidade, os requisitos de confiabilidade em produção (ex.: comportamento sob picos de tráfego) tendem a ser descobertos só depois do incidente, não antes dele.
□ A mesma lógica de “cada papel intermediário traduz e potencialmente distorce um pedido” se aplicaria a uma cadeia de aprovação de crédito bancário em que o gerente de agência resume o pedido do cliente para um analista de risco, que por sua vez resume para um comitê de crédito.
□ Como um pedido “simples” do usuário passa por várias traduções antes de virar código, isso prova que usuários finais deveriam sempre ser excluídos do processo de definição técnica, já que sua visão inicial do problema é, por definição, imprecisa.

Teste 2 — Lei de Conway — premissas

□ Se a premissa de que “organizações minimizam custo de comunicação alinhando equipes a subsistemas” fosse falsa para uma empresa específica (ela deliberadamente mantém equipes desalinhadas dos módulos, mesmo a um custo de comunicação maior), essa empresa poderia, em princípio, produzir uma arquitetura que não espelha seu organograma.
□ No limite em que duas partes de um sistema não precisam trocar absolutamente nenhuma informação entre si para funcionar (interface totalmente independente), a premissa de que “construir uma interface exige comunicação entre quem constrói cada parte” deixa de impor qualquer restrição sobre como as equipes devem se organizar.
□ A afirmação de Conway de que “não existe uma coisa como um grupo de design que seja ao mesmo tempo organizado e imparcial” se aplicaria a um comitê acadêmico dividido em subcomissões temáticas, no sentido de que a divisão em subcomissões já impede certas propostas interdisciplinares de serem seguidas com a mesma facilidade que propostas dentro do tema de uma única subcomissão.
□ Como a Lei de Conway é sobre comunicação organizacional, ela implica que empresas totalmente remotas, sem escritório físico compartilhado, estão estruturalmente imunes ao fenômeno, já que não há organograma físico a ser espelhado.

Teste 3 — Lei de Conway — a Manobra Inversa

□ Se uma empresa reorganizasse suas equipes para espelhar a arquitetura de microsserviços desejada, mas nunca reescrevesse uma linha do código monolítico existente, a Manobra Inversa de Conway prevê que, ainda assim, alguma pressão estrutural em direção à arquitetura desejada teria sido criada.
□ No limite em que uma reorganização de equipe é revertida imediatamente após ser anunciada (dura um dia), o efeito estrutural da Manobra Inversa de Conway sobre a arquitetura tenderia a ser equivalente ao de uma reorganização que se mantém por anos.
□ A lógica da Manobra Inversa se aplicaria a uma universidade que quer estimular pesquisa interdisciplinar entre departamentos historicamente isolados: criar um programa/comitê formal que force comunicação regular entre pesquisadores de áreas diferentes, antes de esperar que os artigos produzidos sejam naturalmente interdisciplinares.
□ Como a Manobra Inversa de Conway propõe mudar a estrutura do time para mudar a arquitetura, isso significa que mudanças de código feitas sem qualquer mudança organizacional são sempre inúteis para alterar a arquitetura de um sistema.

Teste 4 — O caso concreto do compilador e o organograma militar (Conway, 1968)

□ Se, no exemplo do compilador, a organização tivesse decidido alocar as oito pessoas por competência técnica individual (não por linguagem-alvo), sem formar dois subgrupos distintos, o resultado ainda seria necessariamente um compilador com exatamente cinco fases para COBOL e três para ALGOL.
□ No limite em que as duas forças militares do segundo exemplo tivessem, na verdade, uma única cadeia de comando compartilhada desde o início (sem duplicação de organograma), o resultado descrito no artigo — “produziram uma cópia de seu organograma” — não teria correspondência para reproduzir, pois não haveria dois organogramas distintos.
□ O padrão do exemplo do compilador se aplicaria a uma faculdade que divide o desenvolvimento de um sistema acadêmico em dois subgrupos — um para o módulo de matrícula e outro para o módulo de notas — sem qualquer canal formal de comunicação entre eles.
□ Como o artigo de Conway é de 1968 e trata de compiladores e sistemas de armas, isso significa que sua tese não tem aplicação a equipes de desenvolvimento de software ágil e distribuído da atualidade, que usam metodologias muito diferentes das de 1968.

Teste 5 — Elicitação de requisitos como processo social

□ Se o processo clássico de Engenharia de Requisitos (elicitação, análise e negociação, especificação, validação) fosse conduzido exclusivamente com stakeholders de negócio, sem nenhum usuário final envolvido em nenhuma etapa, o resultado ainda poderia ser tecnicamente “completo” segundo as quatro etapas, mesmo sendo socialmente incompleto.
□ No limite em que a etapa de “validação” do processo de Engenharia de Requisitos é realizada apenas com os mesmos stakeholders que participaram da elicitação original, essa validação tenderia a confirmar os mesmos pontos cegos já presentes desde o início, em vez de corrigi-los.
□ A ideia de que a elicitação de requisitos é um processo social, não uma extração neutra, se aplicaria a uma pesquisa de satisfação de usuários feita apenas por e-mail, em um serviço cujos usuários mais vulneráveis têm menos acesso a e-mail do que os demais.
□ Como a etapa de “análise e negociação” do processo de Engenharia de Requisitos existe justamente para resolver conflitos entre requisitos, isso garante, por construção, que grupos sem poder de voz no processo terão seus requisitos igualmente representados nessa negociação.

Teste 6 — Data Feminism — os quatro pontos de partida

□ Se o ponto de partida “Imaginar” não existisse no framework de Data Feminism, e a ação ficasse restrita a “Coletar” e “Analisar”, o texto ainda argumentaria que isso seria suficiente para alcançar a raiz da injustiça, e não só documentar resultados desiguais.
□ No limite em que uma equipe de dados só pratica “Analisar” (auditar algoritmos para provar resultados desiguais) e nunca pratica “Coletar”, “Imaginar” ou “Ensinar”, segundo a lógica dos quatro pontos de partida, essa equipe ainda estaria atacando a causa raiz da injustiça, não só demonstrando sua existência.
□ O ponto de partida “Ensinar” — sobre quem são as pessoas que fazem ciência de dados — se aplicaria à composição de um time de desenvolvimento de um aplicativo de saúde voltado a gestantes, no sentido de que a ausência de qualquer mulher no time é relevante para a discussão, mesmo que o time tenha alta competência técnica.
□ Como os quatro pontos de partida de Data Feminism são apresentados como formas de “tomar ação”, isso significa que qualquer um dos quatro, isoladamente, é sempre suficiente para resolver uma injustiça de dados, sem precisar dos outros três.

Teste 7 — O caso do DGEI e a lógica de contra-dados

□ Se as autoridades de Detroit já mantivessem, em 1971, um registro público e detalhado dos atropelamentos na rota Pointes-Downtown, a motivação central do DGEI para produzir seu próprio mapa — “Where Commuters Run Over Black Children” — deixaria de existir da forma descrita no caso.
□ No limite em que uma comunidade afetada por um problema não tem absolutamente nenhum meio de registrar ou comunicar sua própria experiência (nem mapas, nem relatos orais, nem qualquer forma de testemunho), a prática de produzir contra-dados, no sentido do caso DGEI, não teria como ocorrer.
□ A lógica de “compilar contra-dados diante da negligência institucional”, do caso DGEI, se aplicaria a um grupo de trabalhadores de plataforma (ex.: entregadores) que cria sua própria planilha compartilhada de acidentes de trabalho, na ausência de qualquer registro oficial da empresa que os contrata.
□ Como Gwendolyn Warren afirma que “não conseguiam obter aquela informação” das autoridades, isso prova que toda ausência de dado institucional é sempre proposital, nunca resultado de limitação de recursos ou de outras causas não intencionais.

Teste 8 — O processo clássico de Engenharia de Requisitos (conhecimento consolidado)

□ Se a etapa de “especificação” produzisse um documento tecnicamente impecável, mas baseado em uma etapa de “elicitação” que ouviu apenas um subconjunto não representativo dos usuários, o documento de especificação ainda seria, no sentido usado nesta aula, um retrato fiel das necessidades de todos os usuários do sistema.
□ No limite em que as quatro etapas (elicitação, análise e negociação, especificação, validação) são executadas em sequência estritamente linear, sem nenhuma iteração ou retorno a uma etapa anterior, o processo ainda seria capaz de corrigir um requisito mal levantado na elicitação, caso ele só seja percebido como problemático durante a validação.
□ A sequência de quatro etapas do processo clássico de Engenharia de Requisitos poderia, em princípio, ser aplicada à elaboração de uma nova política pública, substituindo “requisitos de software” por “demandas da população” em cada etapa.
□ Como o processo de Engenharia de Requisitos tem uma etapa chamada “análise e negociação”, isso garante que qualquer conflito de interesse entre stakeholders será resolvido de forma justa entre as partes envolvidas.

Teste 9 — Value Sensitive Design (Steen, Cap. 18)

□ Se a investigação empírica de valores (entrevistas, workshops com stakeholders) do Value Sensitive Design fosse pulada, e o processo começasse direto pela investigação técnica/tecnológica (de que forma o sistema pode ser construído), os requisitos resultantes ainda emergiriam da mesma forma descrita no Cap. 18 de Steen, como resultado das investigações empíricas.
□ No limite em que apenas um único stakeholder (ex.: o cliente pagante) tem seus valores investigados no processo de Value Sensitive Design, a expressão “permitir que diversos stakeholders expressem seus valores e os combinem produtivamente” deixaria de descrever o que está ocorrendo nesse processo.
□ A lógica de Value Sensitive Design — investigar empiricamente os valores em jogo antes de especificar requisitos — se aplicaria ao design de um sistema de triagem hospitalar, no sentido de entrevistar enfermeiros e pacientes sobre o que consideram justo antes de programar a lógica de priorização.
□ Como o Value Sensitive Design combina investigações empíricas, conceituais e tecnológicas, isso significa que, uma vez completado o processo uma única vez no início do projeto, os requisitos de valores resultantes permanecem válidos e não precisam ser revisitados, mesmo com mudanças de contexto.

Teste 10 — A cadeia NFR → ADR → gate de CI

□ Se um compromisso ético fosse traduzido diretamente em uma Decisão de Arquitetura (ADR), sem antes passar por um Requisito Não-Funcional (NFR) testável, ainda seria possível, a partir só da ADR, construir automaticamente um gate de CI que impeça regressão desse compromisso.
□ No limite em que um gate de CI testa uma condição tão frouxa que praticamente qualquer código passa por ele sem alteração de comportamento, esse gate ainda cumpriria, na prática, a função de “impedir regressão” descrita nesta aula.
□ A cadeia de tradução (compromisso → NFR testável → decisão de arquitetura → porta de processo) se aplicaria a um compromisso corporativo de reduzir vieses discriminatórios em um sistema de contratação, na forma de um NFR sobre taxas de erro por subgrupo, uma ADR sobre qual métrica de justiça adotar, e um gate de CI que bloqueia deploys que piorem essa métrica.
□ Como um Requisito Não-Funcional testável é, por definição, mensurável, isso significa que qualquer compromisso ético que não possa ser perfeitamente quantificado deve ser descartado como requisito de engenharia.

Teste 11 — Conway e requisito sem dono: a mesma “queda no buraco”

□ Se todo requisito de um sistema tivesse, desde sua criação, uma equipe explicitamente designada como responsável por sua fronteira (mesmo que essa fronteira cruze múltiplos módulos), o mecanismo de “requisito cai no buraco entre equipes” discutido nesta aula deixaria de se aplicar a esse requisito específico.
□ No limite em que um requisito de acessibilidade afeta igualmente todos os módulos de um sistema (nenhum módulo é mais responsável por ele do que outro), a analogia com uma “interface técnica sem dono” feita nesta aula se tornaria menos aplicável, e não mais, a esse requisito.
□ A mesma lógica de “responsabilidade sem dono claro leva a negligência estrutural” se aplicaria à manutenção de um código legado compartilhado por várias equipes, nenhuma das quais o considera “seu” módulo principal.
□ Como a Lei de Conway trata de módulos técnicos e o Bloco 6 trata de requisitos éticos, a analogia entre os dois é apenas estética/retórica, sem nenhum mecanismo causal real em comum entre as duas situações.

Teste 12 — Síntese da aula e a ponte para a Aula 6

□ Se a Engenharia de Software fosse, de fato, uma sequência neutra de passos puramente técnicos (como a aula argumenta que não é), a existência da Lei de Conway como fenômeno replicável ao longo de décadas seria mais difícil de explicar.
□ No limite em que uma equipe de desenvolvimento segue rigorosamente todo o processo de tradução ético descrito no Bloco 6 (NFR, ADR, gate de CI) para todo compromisso social identificado, essa equipe ainda poderia produzir um sistema com uma arquitetura que espelha disfuncionalmente seu organograma, pelo mecanismo do Bloco 3.
□ A tese central desta aula — de que decisões de processo têm consequência técnica — se conecta com a Aula 6 no sentido de que decisões de arquitetura (quantos serviços, onde e como rodam) também têm consequência material e ambiental, mesmo quando tomadas por razões puramente organizacionais, como a estrutura de equipes.
□ Como a aula conecta processo organizacional a resultado técnico, conclui-se que a solução para qualquer problema de qualidade de software é sempre reorganizar equipes, nunca revisar o código ou a arquitetura diretamente.