Объяснение энтропии программного обеспечения: причины, следствия и средства правовой защиты

Эта статья предназначена для разработчиков программного обеспечения или менеджеров проектов, которым интересно, что такое энтропия программного обеспечения, ее практическое влияние на их работу и основные факторы, способствующие ее росту.

Основная цель состоит в том, чтобы создать понимание энтропии программного обеспечения , потому что это фактор во всех формах разработки программного обеспечения. Кроме того, мы изучаем средства, с помощью которых энтропии программного обеспечения можно присвоить конкретное значение. Только путем количественной оценки энтропии программного обеспечения и наблюдения за ее ростом в последующих выпусках мы можем по-настоящему понять риск, который она представляет для наших текущих целей и планов на будущее.

Что такое программная энтропия?

Программная энтропия получила свое название от главной характеристики энтропии в реальном мире: это мера хаоса, которая либо остается неизменной, либо увеличивается со временем . Другими словами, это мера присущей программной системе нестабильности по отношению к ее изменению.

К сожалению, программной энтропии редко придается то значение, которого она заслуживает.

Он не принимается во внимание при отстранении кого-либо из команды разработчиков, преждевременном запуске цикла разработки или внедрении «быстрых исправлений» — моментах, когда на самом деле вероятность его роста наиболее высока.

Разработка программного обеспечения — это искусство и ремесло, основные строительные блоки которого плохо определены. В то время как строители работают с цементом и гвоздями, разработчик программного обеспечения работает с логическими утверждениями и набором предположений. Их нельзя держать в руке и рассматривать, и их нельзя упорядочить с точностью до восьмой дюйма. Хотя у случайного наблюдателя может возникнуть соблазн сравнить разработку программного обеспечения с конструированием, за исключением нескольких поверхностных сходств, это контрпродуктивно.

Несмотря на эти трудности, мы тем не менее можем изложить принципы, которые позволят нам понять источники энтропии программного обеспечения, измерить степень риска, который она представляет для наших целей, и (при необходимости) какие шаги можно предпринять, чтобы ограничить ее рост.

Предлагаемое определение энтропии программного обеспечения выглядит следующим образом:

где I получено из числа неожиданных проблем, возникших во время последней итерации разработки, C — воспринимаемая вероятность того, что внедрение изменений в систему теперь приведет к новому I > 0, а S — объем следующей итерации разработки. В целом значения E ниже 0,1 считаются хорошими. E 0,5 считается высоким, а значения выше 1,0 подавляющими.

Концепция итерации разработки является неотъемлемой частью нашего понимания энтропии программного обеспечения. Это циклы активности, ведущие от одного поведения системы к другому. Цели, которые мы ставим перед собой во время итерации программного обеспечения, называются его масштабом . В разработке программного обеспечения такие циклы включают изменение или расширение базового кода программного обеспечения.

Все модификации кода происходят в ходе итерации разработки, даже если те, кто их выполняет, так о них не думают. То есть небольшие организации, которые гордятся тем, что создают свои системы с использованием «быстрой и грязной» методологии — практически без сбора требований или анализа — по-прежнему используют итерации разработки для достижения своих целей. Они их просто не планируют. Точно так же, даже если поведение измененной системы каким-то образом отличается от наших намерений, оно все равно было достигнуто посредством итерации разработки.

На самом деле риск того, что это произойдет, и есть то, что призвано объяснить наше знание энтропии программного обеспечения и наше желание измерить ее, чтобы ограничить. Таким образом, с практической точки зрения мы можем определить энтропию программного обеспечения следующим образом.

Любая данная система имеет конечный набор известных открытых проблем I ₀ . В конце следующей итерации разработки останется конечное множество известных открытых проблем I ₁ . Присущая системе энтропия определяет, насколько наше ожидание I ₁ может отличаться от его фактического значения и насколько эта разница может возрасти в последующих итерациях.

Эффекты программной энтропии

Наш практический опыт воздействия энтропии программного обеспечения зависит от того, как мы взаимодействуем с рассматриваемой системой.

Пользователи имеют статическое представление о программном обеспечении; они озабочены тем, как она ведет себя сейчас, и не заботятся о внутренностях системы. Выполняя предопределенное действие, пользователи предполагают, что программное обеспечение ответит соответствующим предопределенным поведением. Тем не менее, пользователи менее всего готовы определить уровень энтропии в используемом ими программном обеспечении.

Энтропия программного обеспечения связана с понятием изменения и не имеет значения в статической системе. Если нет намерения изменить систему, мы не можем говорить о ее энтропии. Точно так же система, которая еще не существует (т. е. следующая итерация фактически является первой в ее существовании), не имеет энтропии.

Программное обеспечение может восприниматься как «глючное» с точки зрения пользователя, но если в последующих итерациях разработчики и менеджеры программного обеспечения достигают своих целей, как и планировалось, мы должны сделать вывод, что энтропия в системе на самом деле довольно низкая! Таким образом, опыт пользователей почти ничего не говорит нам об энтропии программного обеспечения:

• Разработчики программного обеспечения имеют гибкий взгляд на программное обеспечение. Их интересует, как система функционирует в настоящее время, только в той мере, в какой она должна быть изменена, и их интересуют детали того, как она работает, чтобы разработать соответствующую стратегию.

• У менеджеров, пожалуй, самое сложное представление о программном обеспечении, как статичном, так и изменчивом. Они должны сбалансировать краткосрочные потребности с требованиями бизнес-плана, рассчитанного на будущее.

У людей в обеих этих ролях есть ожидания. Программная энтропия проявляется всякий раз, когда эти ожидания не оправдываются. То есть разработчики и менеджеры программного обеспечения делают все возможное, чтобы оценить риски и спланировать их, но — исключая внешние сбои — если их ожидания все же не оправдались, только тогда можно говорить об энтропии программного обеспечения. Это невидимая рука, которая прерывает взаимодействие компонентов, не входящих в область действия, вызывает необъяснимый сбой рабочих серверов и удерживает своевременное и экономичное исправление.

Многие системы с высоким уровнем энтропии полагаются на конкретных людей, особенно если в команде разработчиков есть младшие члены. Этот человек обладает такими знаниями, что другие не могут выполнять свои задачи без его «ценного» вклада. Его нельзя отразить в стандартных диаграммах UML или технических спецификациях, потому что он состоит из смеси исключений, догадок и советов. Это знание не зависит от логически непротиворечивой структуры, и поэтому его трудно — если не невозможно — передать кому-либо еще.

Давайте предположим, что с большой решимостью и усилиями такая организация способна измениться и стабилизировать свой ИТ-отдел. Ситуация, кажется, улучшилась, потому что, когда разработка программного обеспечения остановилась, любой прогресс воодушевляет. Однако в действительности оправдываемые ожидания низки, а достижения неинтересны по сравнению с высокими целями, которые были в пределах досягаемости при еще низкой энтропии.

Когда программная энтропия переполняет проект, проект зависает.

Больше итераций разработки быть не может. К счастью, такая ситуация не возникает мгновенно. Медленное, но стремительное движение к краю обрыва свойственно каждой системе. Независимо от того, насколько хорошо организована и эффективна первая версия, в ходе последующих итераций разработки ее энтропия — а, следовательно, и риск того, что что-то неожиданно пойдет не так, — будут расти, если не будут предприняты конкретные шаги для предотвращения этого.

Программная энтропия не может быть уменьшена. Как и энтропия в реальном мире, она только растет или остается неизменной. Поначалу его последствия незначительны. Когда они начинают проявляться, симптомы слабо выражены и могут быть замаскированы или проигнорированы. Но если организация попытается бороться с энтропией программного обеспечения только после того, как она станет доминирующим риском в проекте, она, к сожалению, обнаружит, что ее усилия напрасны. Таким образом, понимание энтропии программного обеспечения наиболее полезно, когда ее степень невелика, а неблагоприятные последствия минимальны.

Из этого не следует, что каждая организация должна выделять ресурсы на ограничение роста энтропии в своих продуктах. Большая часть программного обеспечения, разрабатываемого сегодня, — в частности, программное обеспечение, ориентированное на потребителя, — имеет относительно короткий ожидаемый срок службы, возможно, несколько лет. В этом случае его заинтересованным сторонам не нужно учитывать последствия энтропии программного обеспечения, поскольку она редко становится серьезным препятствием до того, как вся система будет отброшена. Однако есть и менее очевидные причины учитывать влияние энтропии программного обеспечения.

Рассмотрим программное обеспечение, которое запускает инфраструктуру маршрутизации в Интернете или переводит деньги с одного банковского счета на другой. В любой момент времени в производстве находится одна или несколько версий этого программного обеспечения, и их коллективное поведение может быть задокументировано с достаточно высокой точностью.

Толерантность к риску системы — это мера того, сколько и какого типа неожиданного поведения мы можем с комфортом допустить от одной итерации разработки к другой. Для только что упомянутых типов систем устойчивость к риску намного ниже, чем, скажем, для программного обеспечения, которое маршрутизирует телефонные звонки. Это программное обеспечение, в свою очередь, имеет более низкую устойчивость к риску, чем программное обеспечение, которое управляет корзиной покупок на многих коммерческих веб-сайтах.

Устойчивость к риску и энтропия программного обеспечения связаны тем, что энтропия программного обеспечения должна быть минимальной, чтобы быть уверенным, что мы останемся в пределах допустимого риска системы во время следующей итерации разработки.

Источники программной энтропии

Энтропия программного обеспечения возникает из -за недостатка знаний . Это результат расхождения между нашими общими предположениями и реальным поведением существующей системы. Этот факт объясняет, почему энтропия программного обеспечения имеет значение только в контексте модификации существующей системы; это единственный раз, когда наше непонимание будет иметь какое-либо практическое значение. Энтропия программного обеспечения находит наиболее благодатную почву в системе, детали которой не могут быть поняты одним человеком, а вместо этого разбросаны по команде разработчиков. Время также является мощным стиранием знаний.

Код — это выражение серии логических утверждений. Когда поведение программного обеспечения (и, следовательно, его код) не соответствует логике, для выражения которой оно предназначено, мы можем говорить о присущей ему энтропии. Эта ситуация может возникнуть по трем причинам: логика хорошо известна и расходится с ее выражением, существует множество понятий логики, для выражения которой предназначен код, или логика недостаточно известна.

• Первая ситуация — логика хорошо известна и расходится с текущим выражением — проще всего решить, но и наименее распространена. В эту категорию попадают только очень небольшие системы, поддерживаемые, возможно, двумя участниками: разработчиком и лицом, ответственным за бизнес-план.

• Вторая ситуация — логика неизвестна — встречается редко. Во всех смыслах итерация разработки не может даже начаться. Если в какой-то момент все заинтересованные стороны могут прийти к согласию, они, вероятно, столкнутся с первой ситуацией.

Человеческий разум интерпретирует свой опыт, эффективно фильтруя и модифицируя его, пытаясь вписать его в личные рамки. В отсутствие эффективных привычек разработки, основанных на свободном обмене идеями, взаимном уважении и четких ожиданиях, может быть столько интерпретаций того, как в настоящее время функционирует система, сколько членов команды. Цели команды на текущую итерацию разработки сами по себе могут вызывать споры.

Многие разработчики защищают себя от этой ситуации, укрепляя собственное уникальное понимание того, что от них требуется и как «должна» быть организована система. Менеджеры и другие заинтересованные стороны, с другой стороны, могут невольно пытаться изменить предположения других членов команды в ошибочной попытке облегчить себе жизнь.

Теперь мы подошли к наиболее распространенному источнику энтропии программного обеспечения: существует множество неполных интерпретаций логики, для выражения которой предназначена система. Поскольку существует только одно проявление этой логики, ситуация по определению проблематична.

Как возникает это незнание? Некомпетентность — это один из способов. И, как мы уже видели, отсутствие согласия в отношении целей следующей итерации разработки — еще одна проблема. Но есть и другие факторы, которые следует учитывать. Организация может претендовать на использование методологии разработки, но затем случайно отказаться от некоторых или всех ее аспектов. Затем разработчикам программного обеспечения поручают выполнять расплывчатые задания, часто открытые для интерпретации. Организации, внедряющие изменения в свою методологию разработки, особенно уязвимы перед этим явлением, хотя они далеко не единственные. Личные конфликты, о которых руководство не знает или иным образом не может разрешить, также могут привести к опасному расхождению между ожиданиями и результатами.

Есть и второй, более важный способ, которым мы теряем технические знания о продукте: передача. Зафиксировать технические знания на бумаге непросто даже для самых опытных писателей. Причина в том, что то, что расшифровывать, так же важно, как и то, как . Без надлежащей дисциплины технический писатель может записать слишком много информации. В качестве альтернативы они могут делать предположения, из-за которых они опускают важные моменты. После создания техническая документация должна тщательно обновляться, что является сложной задачей для многих организаций, которые теряют следы документов почти сразу после их написания. Из-за этих трудностей технические знания редко передаются только в документах, а также в паре или других формах тесного взаимодействия между людьми.

Энтропия программного обеспечения стремительно растет всякий раз, когда активный участник покидает команду разработчиков. Они уносят с собой ценный кусок ноу-хау. Воспроизвести это ноу-хау невозможно, а его приближение требует значительных усилий. Однако при достаточном внимании и ресурсах можно сохранить достаточно знаний, чтобы свести к минимуму рост энтропии системы.

Есть и другие источники энтропии, но они относительно незначительны. Например, гниение программного обеспечения — это процесс, при котором на систему неожиданно воздействуют изменения в ее среде. Мы можем думать о стороннем программном обеспечении, от которого оно зависит (например, о библиотеках), но есть и другие, более коварные причины гниения программного обеспечения, обычно возникающие в результате изменений в предположениях, на которых была основана система. Например, если система была разработана с определенными предположениями о доступности памяти, она может начать работать со сбоями в неожиданные моменты, если доступная ей память уменьшится.

Как рассчитать энтропию: присвоение значений C, S и I

I — количество нерешенных поведенческих проблем в программной системе, включая отсутствие обещанных функций. Это известное количество, которое часто отслеживается в таких системах, как JIRA. Значение I выводится непосредственно из него. I — это количество «единиц работы», которые были заброшены или остались незавершенными во время последней итерации разработки, в дополнение к количеству единиц работы, возникших в результате новых и неожиданных поведенческих проблем. Поскольку I считается числом единиц работы, мы можем связать его со значением S, которое является объемом следующей итерации разработки в тех же единицах работы. Что именно включает в себя «рабочая единица», зависит от методологии разработки.

C — предполагаемая вероятность того, что после реализации рабочих единиц в области действия количество фактических открытых вопросов I1 в следующей итерации будет больше, чем его оценка в настоящее время. Это значение находится в домене 0 <= C <= 1.

Можно возразить, что вероятность C — это именно то, что должна измерять программная энтропия. Однако существуют фундаментальные различия между этим значением и нашей мерой энтропии программного обеспечения. Воспринимаемая вероятность того, что что-то пойдет не так, именно такова: это не реальная ценность. Однако он полезен тем, что чувства людей, участвующих в проекте, являются ценным источником информации о том, насколько он стабилен.

Объем S учитывает величину предлагаемых изменений и должен быть выражен в тех же единицах, что и I. Чем больше значение S, тем меньше энтропия, поскольку мы увеличиваем объем предлагаемых изменений. Хотя это может показаться нелогичным, мы должны помнить, что энтропия — это мера того, насколько развитие системы может не соответствовать нашим ожиданиям. Недостаточно сказать, что энтропия — это мера вероятности появления проблем. Естественно, мы пытаемся предвидеть риски и учитывать их в нашем планировании (и, следовательно, в нашей оценке I1, которая вполне может превысить ₀ ). Ясно, что чем больше мы уверены в том, что беремся за масштабные изменения, тем меньше энтропии можно сказать в системе — если только те, кто планирует изменения и/или их осуществляет, некомпетентны. Эта возможность, однако, вероятно, отражена в текущем значении I .

Обратите внимание, что нам не нужно пытаться определить величину разницы между фактическим значением I ₁ и его ожидаемым значением. Если мы предполагаем, что наши планы верны, когда мы их составляем, то также неразумно предполагать, что мы можем предсказать, в какой степени результат не будет соответствовать нашим ожиданиям; мы можем только указать воспринимаемый шанс C, что этого не произойдет. Однако степень, в которой фактическое значение I ₁ отличается от ожидаемого, является важным входным параметром для расчета энтропии на следующей итерации в виде полученного значения I .

Теоретически I может иметь отрицательное значение. Однако на практике такая ситуация никогда не возникнет; мы обычно не решаем проблемы случайно. Отрицательные значения I не являются утешительным признаком. Они подразумевают, что средства, с помощью которых рассчитывается энтропия, ошибочны. Рост энтропии программного обеспечения, конечно, можно уменьшить, приняв определенные меры, как описано ниже. Однако в таких случаях я не должен принимать отрицательные значения, поскольку мы всегда учитываем наши ожидания в наших проектах.

С - субъективная величина. Он существует в сознании участников итерации разработки и может быть выведен путем их опроса и усреднения результатов. Вопрос следует задавать в положительном ключе. Например: «По шкале от 0 до 10, где 10 наиболее вероятны, как бы вы оценили шансы команды на достижение всех своих целей на этой итерации разработки?»

Обратите внимание, что вопрос задается о целях команды в целом, а не о ее подмножестве. Ответ 10 будет означать значение 0 для C, тогда как ответ 7 будет означать значение 0,3. В больших командах каждый ответ может быть взвешен в зависимости от соответствующих факторов, таких как то, как долго человек участвует в проекте и сколько времени он фактически тратит на него. Однако компетентность не должна быть фактором при взвешивании ответов. Вскоре даже младший член команды почувствует, насколько она эффективна в достижении своих целей. Достаточно большие команды могут отбросить самые высокие и самые низкие зарегистрированные значения перед усреднением остатка.

Спрашивать у профессионалов, насколько велика вероятность того, что их команда потерпит неудачу, — деликатное и провокационное предложение. Однако это именно тот вопрос, который должна задать любая организация, желающая количественно определить энтропию. Чтобы гарантировать честные ответы, участники должны дать свою оценку C анонимно и не опасаясь последствий, даже если они сообщают об ужасно высоком значении.

S должно быть присвоено значение в тех же «единицах работы», что и I , и поэтому оно сильно зависит от методологии разработки. Для команд, использующих аспекты методологии Agile, истории кажутся наиболее очевидным «рабочим элементом» как для S, так и для I. В этом случае объем итерации разработки охватывает каждый регулярно запланированный выпуск в производство, как второстепенный, так и основной. I следует количественно определять как сумму количества историй, которые не были успешно завершены в течение каждого спринта, предшествующего релизу, и количества историй, созданных для включения в будущие спринты в результате неожиданных проблем, проявившихся после релиза.

Обратите внимание, что мы не рассматриваем исправления или другие незапланированные выпуски в производство как определяющие степень итерации разработки, а также мы не должны вычитать какие-либо связанные истории из I.

Сложность этого подхода заключается в том, что должен пройти период обнаружения и анализа, прежде чем ошибки можно будет впоследствии разбить на истории. Следовательно, истинное значение I может быть определено только после задержки. Кроме того, опрос для C естественным образом происходит в начале каждого спринта. Поэтому полученные результаты необходимо еще раз усреднить по всему выпуску. Несмотря на эти трудности, любая команда, использующая аспекты методологии Agile, скорее всего, обнаружит, что истории являются наиболее точной единицей для количественной оценки S (и, следовательно , I ).

Сегодня используются и другие методологии разработки. Какая бы методология ни использовалась, принципы измерения энтропии программного обеспечения остаются теми же: энтропия программного обеспечения должна измеряться между выпусками в производство, S и I должны измеряться в одних и тех же «единицах работы», а оценки C должны браться у непосредственных участников процесса. не угрожающим и желательно анонимным образом.

Уменьшение роста E

Если знание о системе утрачено, восстановить его уже невозможно. По этой причине энтропия программного обеспечения не может быть уменьшена. Все, на что мы можем надеяться, это сдерживать его рост.

Рост энтропии можно ограничить, приняв соответствующие меры во время разработки программного обеспечения. В этом отношении особенно полезен аспект парного программирования в Agile-разработке. Поскольку во время написания кода участвует более одного разработчика, знания о важных деталях распределяются, а последствия ухода членов команды смягчаются.

Другой полезной практикой является создание хорошо структурированной и легко воспринимаемой документации, особенно в организациях, использующих методологию водопада. Такая документация должна основываться на строгих и четко определенных принципах, понятных всем. Организации, полагающиеся на документацию в качестве основного средства коммуникации и защиты технических знаний, хорошо подходят для такого подхода. Только когда нет руководств или обучения тому, как писать и использовать внутренние письменные документы — как это часто бывает в молодых организациях, использующих методологии RAD или Agile, — их ценность становится сомнительной.

Есть два способа уменьшить рост энтропии в системе: выполнить изменения, направленные на уменьшение I, или выполнить изменения, направленные на уменьшение C.

Первый включает рефакторинг. Действия, направленные на снижение I, как правило, носят технический характер и, вероятно, уже знакомы читателю. Должна произойти итерация разработки. Часть этой итерации, предназначенная для снижения роста энтропии , не принесет ощутимых преимуществ для бизнеса, хотя потребует времени и ресурсов. Этот факт часто затрудняет снижение роста энтропии в любой организации.

Снижение значения C — более мощная стратегия, потому что эффект более долгосрочный. Кроме того, C выступает в качестве важного сдерживающего фактора роста отношения I к S. Действия по уменьшению C, как правило, сосредоточены на человеческом поведении и мышлении. Хотя эти действия могут не требовать итерации разработки сами по себе, они замедлят последующие итерации, поскольку участники примут новые процедуры и приспособятся к ним. Казалось бы, простое действие по соглашению о том, какие улучшения должны быть сделаны, само по себе чревато опасностями, поскольку внезапно выявляются несопоставимые цели участников проекта и заинтересованных сторон.

Подведение итогов

Энтропия программного обеспечения — это риск того, что изменение существующего программного обеспечения приведет к неожиданным проблемам, невыполненным задачам или тому и другому вместе.

Хотя она незначительна при первом создании программного обеспечения, энтропия программного обеспечения растет с каждой итерацией разработки. Если позволить продолжать беспрепятственно, программная энтропия в конечном итоге остановит дальнейшее развитие.

Однако не каждый проект должен учитывать влияние энтропии программного обеспечения. Многие системы будут сняты с производства до того, как энтропия сможет оказать заметное и вредное воздействие. Для тех, чья жизнь достаточно длинна, чтобы энтропия представляла реальную опасность, создание осведомленности о ней и измерение ее степени, хотя она еще и мала, обеспечивает средства, гарантирующие, что развитие не прервется преждевременно.

Как только система полностью перегружена эффектами программной энтропии, больше нельзя вносить никаких изменений, и разработка, по сути, подошла к концу.