Este artigo é direcionado ao desenvolvedor de software ou gerente de projeto que está curioso para saber o que é entropia de software, os efeitos práticos em seu trabalho e os fatores subjacentes que contribuem para seu crescimento.

O objetivo principal é criar um consciência da entropia de software porque é um fator em todas as formas de desenvolvimento de software. Além disso, exploramos um meio pelo qual a entropia de software pode receber um valor concreto. Somente quantificando a entropia do software e observando seu crescimento ao longo de lançamentos sucessivos podemos entender verdadeiramente o risco que isso representa para nossos objetivos atuais e planos futuros.

O que é entropia de software?

Entropia de software ganha seu nome a partir da principal característica da entropia no mundo real: É uma medida de caos que permanece igual ou aumenta com o tempo . Dito de outra forma, é uma medida da instabilidade inerente construída em um sistema de software com relação a alterá-lo.

Infelizmente, a entropia de software raramente recebe a importância que merece.

Isso não é levado em consideração ao retirar alguém de uma equipe de desenvolvimento, ao iniciar prematuramente um ciclo de desenvolvimento ou implementar 'soluções rápidas' - momentos em que, na verdade, é mais provável que cresça.

Desenvolvimento de software é uma arte e um ofício cujos principais blocos de construção estão mal definidos. Enquanto os construtores trabalham com cimento e pregos, o desenvolvedor de software trabalha com afirmações lógicas e um conjunto de suposições. Elas não podem ser seguradas na mão e examinadas, nem podem ser encomendadas por um oitavo de polegada. Embora o observador casual possa ficar tentado a comparar o desenvolvimento de software com a construção, além de algumas semelhanças superficiais, é contraproducente fazer isso.

Apesar dessas dificuldades, podemos traçar as diretrizes que nos permitirão entender as fontes de entropia de software, medir a extensão do risco que ela representa para nossos objetivos e (se necessário) que medidas podem ser tomadas para limitar seu crescimento.

A definição proposta de entropia de software é a seguinte:

E = I´C / S

onde I´ é derivado do número de problemas inesperados introduzidos durante a última iteração de desenvolvimento, C é a probabilidade percebida de que a implementação de mudanças no sistema agora resulta em um novo I´> 0 e S é o escopo da próxima iteração de desenvolvimento. Em geral, valores de E abaixo de 0,1 são considerados bons. Um E de 0,5 é considerado alto e valores acima de 1,0 são esmagadores.

O conceito de iteração de desenvolvimento é parte integrante da nossa compreensão da entropia do software. São ciclos de atividade que conduzem de um comportamento do sistema a outro. Os objetivos que estabelecemos para nós mesmos durante a iteração do software são chamados de escopo . No desenvolvimento de software, tais ciclos envolvem modificar ou expandir o código subjacente do software.

Todas as modificações no código ocorrem em uma iteração de desenvolvimento, mesmo que aqueles que as realizam não pensem nelas dessa forma. Ou seja, organizações menores que se orgulham de construir seus sistemas usando uma metodologia “rápida e suja” - com pouca ou nenhuma coleta de requisitos ou análise - ainda usam iterações de desenvolvimento para atingir seus objetivos. Eles simplesmente não os planejam. Da mesma forma, mesmo se o comportamento de um sistema modificado divergir de alguma forma de nossas intenções, ele ainda foi alcançado por meio de uma iteração de desenvolvimento.

Na verdade, o risco de que isso aconteça é exatamente o que nossa consciência da entropia do software pretende explicar e nosso desejo de medi-la pretende limitar. Em termos práticos, então, podemos definir a entropia de software como segue.

Qualquer sistema tem um conjunto finito de questões abertas conhecidas I₀. No final da próxima iteração de desenvolvimento, haverá um conjunto finito de problemas abertos conhecidos.₁. A entropia inerente do sistema especifica o quanto nossa expectativa de I₁provavelmente difere de seu valor real e de quanto a diferença provavelmente aumentará nas iterações subsequentes.

Efeitos da entropia de software

Nossa experiência prática dos efeitos da entropia do software depende de como interagimos com o sistema em questão.

Os usuários têm uma visão estática do software; eles estão preocupados com como ele se comporta agora e não se importam com os componentes internos de um sistema. Ao executar uma ação predefinida, os usuários presumem que o software responderá com um comportamento predefinido correspondente. No entanto, os usuários são os menos preparados para deduzir o nível de entropia do software que estão usando.

A entropia do software está ligada à noção de mudança e não tem significado em um sistema estático. Se não houver intenção de alterar o sistema, não podemos falar de sua entropia. Da mesma forma, um sistema que ainda não existe (ou seja, a próxima iteração é realmente a primeira de sua existência) não tem entropia.

O software pode ser percebido como “bugado” do ponto de vista do usuário, mas se durante as iterações subsequentes os desenvolvedores e gerentes de software estiverem atingindo seus objetivos conforme planejado, devemos concluir que a entropia no sistema é realmente muito baixa! A experiência dos usuários, portanto, nos diz muito pouco ou nada sobre a entropia do software:

• Os desenvolvedores de software têm uma visão fluida do software. Eles estão preocupados em como um sistema atualmente funciona apenas na medida em que deve ser alterado, e estão preocupados com os detalhes de como ele funciona para planejar uma estratégia apropriada.

• Os gerentes têm talvez a visão mais complicada de software, tanto estática quanto fluida. Eles devem equilibrar as exigências de curto prazo com as demandas de um plano de negócios que se estende ainda mais no futuro.

As pessoas em ambas as funções têm expectativas. A entropia do software se manifesta sempre que essas expectativas são prejudicadas. Ou seja, desenvolvedores e gerentes de software fazem o melhor para avaliar os riscos e planejá-los, mas - excluindo interrupções externas - se suas expectativas ainda assim forem frustradas, só então podemos falar de entropia de software. É a mão invisível que interrompe as interações de componentes que não estavam no escopo, faz com que os servidores de produção falhem inexplicavelmente e retém um hotfix oportuno e econômico.

Muitos sistemas com altos níveis de entropia dependem de indivíduos específicos, principalmente se houver membros juniores da equipe de desenvolvimento. Esta pessoa possui conhecimento de tal forma que os outros não podem realizar suas tarefas sem sua contribuição “valiosa”. Não pode ser capturado em diagramas UML padrão ou especificações técnicas, pois consiste em um amálgama de exceções, palpites e dicas. Esse conhecimento não depende de uma estrutura logicamente consistente e, portanto, é difícil - senão impossível - transferi-lo para qualquer outra pessoa.

Suponhamos que, com grande determinação e esforço, tal organização seja capaz de se virar e estabilizar seu departamento de TI. A situação parece ter melhorado porque, quando o desenvolvimento de software é interrompido, qualquer progresso é encorajador. No entanto, na realidade, as expectativas sendo atendidas são baixas e as conquistas desinteressantes em comparação com as metas elevadas que estavam ao alcance enquanto a entropia ainda era baixa.

Quando a entropia do software sobrecarrega um projeto, o projeto congela.

Não pode haver mais iterações de desenvolvimento. Felizmente, essa situação não surge instantaneamente. A marcha lenta mas abrupta em direção à beira de um penhasco é algo que todos os sistemas sofrem. Não importa o quão bem organizada e eficiente a primeira versão possa ser, ao longo de sucessivas iterações de desenvolvimento sua entropia - e, portanto, o risco de que as coisas dêem errado inesperadamente - aumentará a menos que etapas específicas sejam tomadas para evitá-lo.

A entropia do software não pode ser reduzida. Assim como a entropia no mundo real, ela apenas cresce ou permanece a mesma. No início, seus efeitos são insignificantes. Quando começam a se manifestar, os sintomas são leves e podem ser mascarados ou ignorados. Mas se uma organização apenas tenta combater a entropia de software depois que ela se torna o risco dominante em um projeto, infelizmente descobrirá que seus esforços são em vão. A consciência da entropia do software é, portanto, mais útil quando sua extensão é baixa e os efeitos adversos mínimos.

Isso não significa que toda organização deva dedicar recursos para limitar o crescimento da entropia em seus produtos. Muito do software que está sendo desenvolvido hoje - software orientado ao consumidor em particular - tem uma vida útil esperada relativamente curta, talvez alguns anos. Nesse caso, seus stakeholders não precisam considerar os efeitos da entropia do software, já que raramente ela se tornará um obstáculo sério antes de todo o sistema ser descartado. Existem, entretanto, razões menos óbvias para considerar os efeitos da entropia do software.

Considere o software que executa a infraestrutura de roteamento da Internet ou transfere dinheiro de uma conta bancária para outra. A qualquer momento, há uma ou mais versões deste software em produção e seus comportamentos coletivos podem ser documentados com uma precisão razoavelmente alta.

o tolerância de risco de um sistema é uma medida de quanto e que tipo de comportamento inesperado podemos permitir confortavelmente de uma iteração de desenvolvimento para a próxima. Para os tipos de sistemas mencionados, a tolerância ao risco é muito menor do que, digamos, o software que roteia chamadas telefônicas. Esse software, por sua vez, tem menor tolerância ao risco do que o software que movimenta o carrinho de compras de muitos sites comerciais.

A tolerância ao risco e a entropia do software estão relacionadas em que a entropia do software deve ser mínima para ter certeza de que permaneceremos dentro da tolerância ao risco do sistema durante a próxima iteração de desenvolvimento.

Fontes de entropia de software

A entropia do software surge de uma falta de conhecimento . Resulta da divergência entre nossas suposições comuns e o comportamento real de um sistema existente. Esse fato explica por que a entropia de software só tem significado no contexto de modificação de um sistema existente; é a única ocasião em que nossa falta de compreensão terá algum efeito prático. A entropia de software encontra o terreno mais fértil em um sistema cujos detalhes não podem ser entendidos por uma única pessoa, mas sim espalhados por uma equipe de desenvolvimento. O tempo também é um poderoso apagador de conhecimento.

Código é a expressão de uma série de afirmações lógicas. Quando o comportamento do software (e, portanto, seu código) não corresponde à lógica que se destina a expressar, podemos falar de sua entropia inerente. Essa situação pode surgir de três maneiras: a lógica é bem conhecida e diverge de sua expressão, há múltiplos entendimentos da lógica que o código pretende expressar ou a lógica não é bem conhecida.

• A primeira situação - a lógica é bem conhecida e diverge de sua expressão atual - é a mais fácil de abordar, mas também a menos comum. Somente sistemas muito pequenos mantidos por talvez dois participantes, um desenvolvedor e alguém responsável pelo plano de negócios, se enquadrarão nesta categoria.

• A segunda situação - a lógica não é bem conhecida -é raro. Para todos os efeitos, a iteração de desenvolvimento nem pode ser iniciada. Se em algum ponto todas as partes interessadas concordarem, é provável que enfrentem a primeira situação.

A mente humana interpreta suas experiências, efetivamente filtrando e modificando-as na tentativa de encaixá-las em uma estrutura pessoal. Na ausência de hábitos de desenvolvimento eficazes - baseados na livre troca de idéias, respeito mútuo e expectativas claras - pode haver tantas interpretações de como um sistema atualmente funciona quanto há membros da equipe. As metas da equipe para a iteração de desenvolvimento atual podem estar em disputa.

Muitos desenvolvedores se protegem dessa situação, reforçando seus próprios entendimentos exclusivos do que é exigido deles e como o sistema “deve” ser organizado. Os gerentes e outras partes interessadas, por outro lado, podem involuntariamente tentar mudar as suposições de outros membros da equipe em uma tentativa equivocada de tornar suas próprias vidas mais fáceis.

Agora chegamos à fonte mais comum de entropia de software: Existem interpretações múltiplas e incompletas da lógica que o sistema pretende expressar. Uma vez que sempre existe uma única manifestação dessa lógica, a situação é, por definição, problemática.

Como surge essa falta de conhecimento? A incompetência é um caminho. E, como já vimos, a falta de acordo sobre os objetivos da próxima iteração de desenvolvimento é outra. Mas existem outros fatores a serem considerados. Uma organização pode pretender empregar uma metodologia de desenvolvimento, mas então abandonar aleatoriamente alguns ou todos os seus aspectos no chão de fábrica. Os desenvolvedores de software são então encarregados de completar tarefas vagas, geralmente abertas a interpretações. As organizações que implementam mudanças em sua metodologia de desenvolvimento são particularmente vulneráveis ​​a esse fenômeno, embora não sejam de forma alguma as únicas. Conflitos pessoais que a administração desconhece ou de outra forma incapaz de resolver também podem levar a uma perigosa divergência entre expectativas e resultados.

Há uma segunda maneira, mais importante, pela qual perdemos conhecimento técnico sobre um produto: na transferência. Capturar conhecimento técnico no papel é um desafio, mesmo para os escritores mais proficientes. A razão é que o que transcrever é tão importante quanto Como . Sem a disciplina adequada, um redator técnico pode registrar muitas informações. Alternativamente, eles podem fazer suposições que os levam a omitir pontos essenciais. Depois de produzida, a documentação técnica deve ser mantida meticulosamente atualizada, uma proposta difícil para muitas organizações que perdem o controle dos documentos assim que são redigidos. Por causa dessas dificuldades, o conhecimento técnico raramente é transferido apenas em documentos, mas também em pares ou outras formas de interação próxima entre humanos.

A entropia de software dá saltos e limites sempre que um participante ativo deixa uma equipe de desenvolvimento. Eles estão levando um pedaço valioso de know-how com eles. Replicar esse know-how é impossível e aproximar isso requer um esforço considerável. Com atenção e recursos suficientes, no entanto, conhecimento suficiente pode ser preservado para que o crescimento da entropia do sistema possa ser minimizado.

Existem outras fontes de entropia, mas são relativamente menores. Por exemplo, podridão de software é o processo pelo qual um sistema é inesperadamente afetado por mudanças em seu ambiente. Podemos pensar em software de terceiros no qual ele se baseia (como bibliotecas), mas existem outras causas mais insidiosas de apodrecimento de software, geralmente resultantes de mudanças nas suposições nas quais o sistema foi baseado. Por exemplo, se um sistema foi projetado com certas suposições sobre a disponibilidade de memória, ele pode começar a funcionar mal em momentos inesperados se a memória disponível para ele for reduzida.

Como Caclular Entropia: Atribuindo Valores a C, S e I

I é o número de problemas comportamentais não resolvidos em um sistema de software, incluindo a ausência de recursos prometidos. Esta é uma quantidade conhecida que geralmente é rastreada em um sistema como JIRA . O valor de I 'é derivado diretamente dele. I´ é o número de “unidades de trabalho” que foram abandonadas ou deixadas incompletas durante a última iteração de desenvolvimento, além do número de unidades de trabalho resultantes de problemas comportamentais recém-introduzidos e inesperados. Como I´ é contado como um número de unidades de trabalho, podemos relacioná-lo ao valor de S, que é o escopo da próxima iteração de desenvolvimento nas mesmas unidades de trabalho. O que exatamente compreende uma “unidade de trabalho” depende da metodologia de desenvolvimento.

C é a probabilidade percebida de que, quando as unidades de trabalho no escopo foram implementadas, o número de questões abertas reais I1 na próxima iteração será maior do que sua estimativa agora. Este valor reside no domínio 0<= C <= 1.

Pode-se argumentar que a probabilidade C é precisamente o que a entropia do software pretende medir. No entanto, existem diferenças fundamentais entre esse valor e nossa medida de entropia de software. o percebido probabilidade de que algo dê errado é exatamente isso: Não é um valor real. No entanto, é útil porque os sentimentos das pessoas que estão participando de um projeto são uma fonte valiosa de informações sobre como ele é estável.

O escopo S leva em consideração a magnitude das mudanças propostas e deve ser expresso nas mesmas unidades que I´. Um valor maior de S diminui a entropia porque estamos aumentando o escopo das mudanças propostas. Embora isso possa parecer contra-intuitivo, devemos ter em mente que a entropia é uma medida de como o desenvolvimento do sistema pode não atender às nossas expectativas. Não é suficiente dizer que a entropia é uma medida da chance de introdução de problemas. Naturalmente tentamos antecipar os riscos e levá-los em consideração em nosso planejamento (e, portanto, em nossa estimativa de I1, que pode muito bem aumentar₀) Claramente, quanto mais confiantes estivermos em assumir um grande escopo de mudança, menos entropia pode ser considerada no sistema - a menos que aqueles que planejam as mudanças e / ou executam-nas sejam incompetentes. Essa possibilidade, no entanto, provavelmente se reflete no valor atual de I´.

Observe que não precisamos tentar especificar a magnitude da diferença entre o valor real de I₁e seu valor esperado. Se presumirmos que nossos planos estão corretos quando os fazemos, também não é razoável presumir que podemos prever o grau em que o resultado não atenderá às nossas expectativas; só podemos especificar uma chance percebida C de que não. No entanto, o grau em que o valor real I₁difere de seu valor esperado é uma entrada importante no cálculo da entropia na próxima iteração na forma do valor derivado I´.

Teoricamente, é possível que I´ tenha um valor negativo. Na prática, entretanto, essa situação nunca ocorrerá; geralmente não resolvemos problemas acidentalmente. Valores negativos para I´ não são um sinal reconfortante. Eles implicam que o meio pelo qual a entropia está sendo calculada é falho. O crescimento da entropia do software pode, é claro, ser reduzido tomando medidas específicas, conforme descrito abaixo. Porém, nesses casos, não devo assumir valores negativos, pois sempre incorporamos nossas expectativas em nossos projetos.

C é um valor subjetivo. Ele existe nas mentes dos participantes de uma iteração de desenvolvimento e pode ser deduzido pesquisando-os e calculando a média dos resultados. A pergunta deve ser feita de maneira positiva. Por exemplo: “Em uma escala de 0 a 10 com 10 mais provável, como você estimaria as chances da equipe de atingir todos os seus objetivos nesta iteração de desenvolvimento?”

Observe que a questão está sendo colocada sobre os objetivos da equipe como um todo, não um subconjunto. Uma resposta de 10 indicaria um valor de 0 para C, enquanto uma resposta de 7 indicaria um valor de 0,3. Em equipes maiores, cada resposta pode ser ponderada dependendo de fatores relevantes, como há quanto tempo um indivíduo está envolvido no projeto e quanto do seu tempo é realmente gasto nele. A competência, entretanto, não deve ser um fator na ponderação das respostas. Em pouco tempo, até mesmo um membro júnior da equipe terá uma noção de quão eficaz é para atingir seus objetivos. Equipes suficientemente grandes podem desejar descartar os valores mais altos e mais baixos relatados antes de calcular a média do restante.

Perguntar aos profissionais a probabilidade de sua equipe falhar é uma proposta sensível e provocativa. No entanto, esta é exatamente a pergunta que qualquer organização que deseja quantificar a entropia precisa fazer. Para garantir respostas honestas, os participantes devem dar sua estimativa de C anonimamente e sem medo de repercussão, mesmo que relatem um valor extremamente alto.

Deve ser atribuído um valor a S nas mesmas “unidades de trabalho” que I´ e, portanto, é altamente dependente da metodologia de desenvolvimento. Para equipes que empregam aspectos de um Metodologia ágil , as histórias parecem a “unidade de trabalho” mais óbvia para S e para mim. Nesse caso, a extensão de uma iteração de desenvolvimento abrange cada liberação programada regularmente para a produção, seja secundária ou principal. I´ deve ser quantificado como a soma do número de histórias que não foram concluídas com sucesso durante cada sprint que levou ao lançamento e o número de histórias geradas para inclusão em sprints futuros como resultado de problemas inesperados que se manifestam após o lançamento.

Observe que não consideramos hotfixes ou outras versões não programadas para produção como definindo a extensão de uma iteração de desenvolvimento, nem devemos subtrair quaisquer histórias associadas de I´.

A dificuldade com essa abordagem é que um período de descoberta e análise deve ocorrer antes que os bugs possam ser subdivididos em histórias. O verdadeiro valor de I´, portanto, só pode ser definido após um atraso. Além disso, a votação para C ocorre naturalmente no início de cada sprint. Os resultados obtidos devem, portanto, ser mais uma vez calculados a média ao longo de todo o lançamento. Apesar dessas dificuldades, qualquer equipe que empregue aspectos de uma metodologia ágil provavelmente descobrirá que as histórias são a unidade mais precisa para quantificar S (e, portanto, I ').

Existem outras metodologias de desenvolvimento em uso hoje. Qualquer que seja a metodologia empregada, os princípios para medir a entropia do software permanecem os mesmos: a entropia do software deve ser medida entre os lançamentos para a produção, S e I´ devem ser medidos nas mesmas 'unidades de trabalho' e as estimativas de C devem ser obtidas dos participantes diretos de uma forma não ameaçadora e de preferência anônima.

Reduzindo o crescimento de E

Uma vez que o conhecimento sobre um sistema é perdido, ele nunca pode ser recuperado. Por esta razão, a entropia do software não pode ser reduzida. Tudo o que podemos esperar é restringir seu crescimento.

O crescimento da entropia pode ser limitado pela adoção de medidas apropriadas durante o desenvolvimento do software. O aspecto de programação em pares do desenvolvimento ágil é particularmente útil a esse respeito. Como mais de um desenvolvedor está envolvido no momento em que o código é escrito, o conhecimento dos detalhes essenciais é distribuído e os efeitos da saída dos membros da equipe são mitigados.

Outra prática útil é a produção de documentação bem estruturada e de fácil consumo, especialmente em organizações que empregam uma metodologia em cascata. Essa documentação deve ser amparada por princípios rígidos e bem definidos, compreendidos por todos. Organizações que confiam na documentação como principal meio de comunicação e salvaguarda do conhecimento técnico são bem adequadas para essa abordagem. É só quando há não diretrizes ou treinamento sobre como escrever e consumir documentos escritos internamente - como costuma ser o caso em organizações mais jovens que empregam RAD ou metodologias Agile - que seu valor se torne suspeito.

Existem duas maneiras de reduzir o crescimento da entropia em um sistema: Executar alterações destinadas a reduzir I´ ou executar alterações destinadas a reduzir C.

O primeiro envolve refatoração. As ações destinadas a reduzir I´ tendem a ser de natureza técnica e provavelmente já são familiares ao leitor. Uma iteração de desenvolvimento deve ocorrer. A parte desta iteração que se destina a reduzir o crescimento da entropia não trará nenhum benefício comercial tangível enquanto consumirá tempo e recursos. Esse fato geralmente torna a redução do crescimento da entropia uma venda difícil em qualquer organização.

Reduzir o valor de C é uma estratégia mais poderosa porque o efeito é de longo prazo. Além disso, C atua como um importante controle do crescimento da razão de I´ para S. As ações para reduzir C tendem a se concentrar no comportamento e no pensamento humanos. Embora essas ações possam não exigir uma iteração de desenvolvimento per se, elas irão retardar as iterações subsequentes à medida que os participantes aceitam e se ajustam aos novos procedimentos. O ato aparentemente simples de concordar sobre quais melhorias devem ser feitas é um caminho repleto de perigos próprios, conforme os objetivos díspares dos participantes do projeto e das partes interessadas repentinamente vêm à luz.

Empacotando

A entropia de software é o risco de que a alteração do software existente resulte em problemas inesperados, objetivos não atendidos ou ambos.

Embora desprezível quando o software é criado pela primeira vez, a entropia do software aumenta com cada iteração de desenvolvimento. Se for permitido continuar sem verificação, a entropia do software acabará por interromper o desenvolvimento posterior.

No entanto, nem todo projeto deve levar em conta os efeitos da entropia do software. Muitos sistemas serão retirados de produção antes que a entropia possa exercer efeitos perceptíveis e deletérios. Para aqueles cujas vidas são longas o suficiente para que a entropia represente um risco crível, criar uma consciência para ela e medir sua extensão, embora ainda baixa, fornece um meio de garantir que o desenvolvimento não seja interrompido prematuramente.

Uma vez que um sistema tenha sido completamente sobrecarregado pelos efeitos da entropia do software, nenhuma outra mudança pode ser feita e o desenvolvimento está essencialmente encerrado.

Compreender o básico

Qual é a definição de entropia?

Uma medida de caos nos sistemas de informação que permanece igual ou aumenta com o tempo.

O que é entropia de software?

A entropia de software é o risco de que a alteração do software existente resulte em problemas inesperados, objetivos não atendidos ou ambos. Embora desprezível quando o software é criado pela primeira vez, a entropia do software aumenta com cada iteração de desenvolvimento.

Como faço para calcular a entropia?

E = I'C / S onde I´ é derivado do número de problemas inesperados introduzidos durante a última iteração de desenvolvimento, C é a probabilidade percebida de que a implementação de mudanças no sistema agora resulta em um novo I´> 0, e S é o escopo da próxima iteração de desenvolvimento.