Ковтун Дарья Владимировна

НТУУ «КПИ»

Факультет менеджмента и маркетинга

Кафедра математического моделирования экономических систем

«Изменения к лучшему в век программного обеспечения»

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

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

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

Имеется масса противоречий между людьми и организациями, быстро приспосабливающимися к изменениям, и теми, кто предпочитает не делать этого. Хорошим современным примером являются затруднения разработчиков программного обеспечения, пытающихся приспосабливаться к изменениям при соблюдении фиксированной структуры спецификационного контракта на разработку программного обеспечения. Такого рода контракты определяются администраторами, придерживающимися принципа THWADI (That’s How We’ve Always Done It – «мы всегда так делаем»). В коммерческом мире разрабатываются более совершенные структуры контрактов, основанные, например, на модели «общей участи» («shared destiny»). Применение усовершенствованных и общепринятых видов контрактов будет способствовать успешной разработке программного обеспечения при наличии частых изменений.

Многие источники изменений являются относительно непредсказуемыми, например, те, которые связаны с возникновением новых технологий. Часто, когда пользователей просят заранее специфицировать желательный для них способ взаимодействия с новым приложением, они отвечают «IKIWISI» (I’ll Know It When I See It, «это будет понятно, когда мы его увидим»). В таких случаях использование последовательной каскадной модели, в которой сначала специфицируются все требования, скорее всего, приведет к созданию неповоротливой системы, требующей большого объема работ для внесения изменений.

Для сокращения объема неопределенности лучше всего использовать стратегию BITAR (Buy Information To Avoid Risk, «чтобы избежать риска, покупайте информацию»). Эта стратегия предполагает расходование дополнительных средств на прототипирование, имитационное моделирование, эталонное тестирование, анализ тенденций рынка и т.д. для сокращения уровня неопределенности и рисков. Кроме того, важно организовывать будущие проекты таким образом, чтобы оставалась возможность приспособиться к появлению новых источников непредвиденных изменений. Это предполагает наличие способности к быстрым изменениям в коллективе разработчиков, в их организации, в архитектуре программного продукта и процессе его разработки.

Наряду с развитием возможности быстрых изменений в будущих проектах потребуется добиваться более высокого уровня функциональной надежности (dependability), поскольку программное обеспечение становится доминирующим фактором в конкурентных отличиях продуктов и сервисов, производимых компаниями. Одновременное достижение способности к быстрым изменениям и функциональной надежности является одной из наиболее крупных проблем XXI века для специалистов в области инженерии программного обеспечения.

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

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

«Безразмерное» (one-size-uniformly-fits-all, OSUFA) определение функциональной надежности в терминах времени безотказной работы систем часто устраивает не все заинтересованные стороны. Заключение о непригодности подхода OSUFA становится еще более явным при наличии тенденции к глобализации, охватывающей разные культуры. Например, из-за различий в культуре страны только 17 из 380 софтверных компаний Таиланда решилось использовать разработанную в США модель CMM.

Подход OSUFA и стандартизация процессов разработки особенно плохо соответствуют еще одной тенденции XXI века – появлению крупных, преимущественно программных систем, строящихся из существующих систем (software-intensive systems of systems, SISOS). Эта тенденция означает наличие требования масштабирования при решении проблемы одновременного обеспечения возможности быстрых изменений и функциональной надежности.

Литература:

1. Статья Барри Боем (Barry Boehm, University of Southern California) «Изменения к лучшему в век программного обеспечения» («Making a Difference in the Software Century»).