Правила и инструменты планирования и управления эволюции программных систем

Ниже приводится изложение статьи авторов Meir M. Lehman и Juan F. Ramil, которая доступна по следующей ссылке:

Meir M. Lehman and Juan F. Ramil. 2001. Rules and Tools for Software Evolution Planning and Management. Ann. Softw. Eng. 11, 1 (November 2001), 15-44. DOI=http://dx.doi.org/10.1023/A:1012535017876

1. (1974) Непрерывное изменение: Е-программа должна быть непрерывно адаптируемой, иначе она будет становиться всё менее удовлетворительной
2. (1974) Увеличение сложности: По мере того, как программа эволюционирует, её сложность растёт, если не производится работ по стабилизации и уменьшению сложности
3. (1974) Саморегулирование: Процесс эволюции программы является саморегулируемым
4. (1978) Сохранение организационной стабильности: Cредний эффективный глобальный уровень активности в эволюционирующей системе инвариантен к времени жизни продукта
5. (1978) Сохранение осведомлённости: В течение активной жизни эволюционирующей программы основное содержание последующих релизов статистически неизменно
6. (1991) Непрерывное развитие: Функциональное содержание программы должно постоянно расширяться на протяжении жизненного цикла, чтобы поддерживать удовлетворённость пользователей
7. (1996) Ухудшение качества: Качество программ Е-типа будет восприниматься как ухудшающееся, если они не сопровождаются должным образом и не адаптируются к операционной среде
8. (1996) Система обратной связи: Процессы программирования Е-типа вместе составляют многоконтурные, многоуровневые системы обратной связи и должны рассматриваться как таковые, чтобы успешно изменяться и улучшаться

Большими в данном случае называют программы, в разработке и управлении которыми принимает участие две или больше команд. Для больших программ предлагается следующая классификация:

Программы S-типа – это те программы, пригодность которых по завершении разработки определяется только соответсвием спецификации. Заметим, что после того, как спецификация определена, никакие допущения не определяют премлимость программы.

Программы E-типа – это программы, которые функционируют или решают проблему в реальном мире. Было показано, что для того, чтобы оставаться приемлимыми, должны непрерывно меняться и обновляться.

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

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

• Е-программа должна быть непрерывно адаптируемой, иначе она будет становиться всё менее удовлетворительной

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

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

Ниже следует частичный перечень практических последствий этой бесконечной потребности поддержания кода систем E-типа:

1. Проверки изменений должны проверять сами изменения, фактическое и потенциальное взаимодействие с остальной частью системы, а также воздействия на остальной части системы.
2. Полная документация должна поддерживаться обновленной с учетом накапливающихся изменений.
3. Множество предположений должно пересмотриваться в качестве неотъемлемой части планирования релиза и периодически после этого для обнаружения любых несоответствий.

• По мере того, как программа эволюционирует, её сложность растёт, если не производится работ по стабилизации и уменьшению сложности.

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

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

1. Различные аспекты сложности системы необходимо учитывать при разработке технологического процесса, его совершенствования и планирования. Oни включают в себя, но не ограничиваются ими:
   • функциональная сложность
   • спецификации и требования к сложности
   • архитектурная сложность
   • дизайн и сложность реализации
   • структурная сложность на многих уровнях (подсистем, модулей, объектов, документации и т.д.)
2. Необходимо сознательное усилие, чтобы контролировать, а также уменьшать сложность и ее рост
3. Разумной является стратегия чередовать релизы с акцентом в первую очередь на снижение сложности и реструктуризацию и те, что добавляют новые функции или существенное функциональное расширение

• Процесс эволюции программы E-типа является саморегулируемым.

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

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

• Cредний эффективный глобальный уровень активности в эволюционирующей системе инвариантен к времени жизни продукта.

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

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

• В течение активной жизни эволюционирующей программы основное содержание последующих релизов статистически неизменно

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

1. Собирать и моделировать рост и изменение данных в зависимости от реального времени или от порядкового номера релиза для определения тенденций развития системы. Элементы, которые могут быть подсчитаны, включают в себя объекты, строки кода, модули входа и выхода, межсоединения, подсистемы, требования и т.д.
2. Разработать автоматические инструменты для облегчения сбора, моделирования и интерпретации

Данных, по мере их накопления, чтобы вывести, например, шаблоны динамических тенденций.

• Функциональное содержание программы должно постоянно расширяться на протяжении жизненного цикла, чтобы поддерживать удовлетворённость пользователей.

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

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

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

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

1. Определить аспекты качества, важные для бизнеса и решаемой задачи (Б) Выразить в числах аспекты, выявленные на стадии (а) с тем, чтобы их можно было адекватно контролировать.
2. Посвятить некоторую часть рабочих ресурсов для уменьшения сложности всех видов, реструктуризации и удаления мертвых элементов системы, ненужных повторений, и т.п.
3. Обучить персонал стремиться замечать и записывать предположения, будь то явные или неявные, на всех этаяпах процесса в стандартной форме и в структуре, которая будет способствовать их пересмотру.

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

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

Эти наблюдения приводят к следующим рекомендациям:

1. Моделировать глобальные структуры, калибровать их и применять анализ чувствительности, чтобы определить влияние и относительная важность путей и средств управления.
2. В планировании и управлении дальнейшей работы, использовать модели в качестве тренажеров, чтобы определить последствия влияний, которые вытекают из анализа.

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

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

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

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

1. При разработке компьютерных приложений и связанных с ними систем, необходима оценка и документирование вероятности изменений в различных областях прикладных, чтобы упростить последующее обнаружение предположений, которые, возможно, станут недействительными в результате изменений;
2. Хранить соответствующую информацию в структурированной форме, связанной с вероятностью изменения.

Система всегда будет неопределенной. Однако соблюдение рекомендаций поможет уменьшить случаи неожиданного поведения и сбои.

Эволюция программного обеспечения проявляется в общей потребности продолжения технического обслуживания и периодических модернизаций программного обеспечения, используемого в реальных приложениях. Статья излагает восемь законов эволюции программного обеспечения, дополненные принципом неопределенности программного обеспечения и FEAST-гипотезой (Feedback, Evolution and Software Technology). Также в статье предлагаются правила планирования и управления системой программного обеспечения. Выбор и применение индивидуальных рекомендаций и их сочетаний остается на руководстве с точки зрения их относительной эффективности, оценки затрат и результатов достижения бизнес-целей. Теория эволюции программного обеспечеения может быть расширена и обобщена для решения более широкого группа бизнес-процессов.