Концепции повышения надежности в процессе разработки сложных программных средств

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

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

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

Вторая концепция – иерархическая структура. Каждый уровень представляет собой совокупность структурных отношений между элементами нижних уровней. Концепция уровня позволяет понять систему, скрывая несущественные уровни детализации. Например, система, которую мы называем «человек», представляется иерархией. Социолог может интересоваться взаимоотношениями людей, не заботясь об их внутреннем устройстве. Психолог работает на более низком уровне иерархии. Он может исследовать различные логические и физические процессы в мозге, не рассматривая внутреннего строения областей мозга. Еще ниже в этой иерархии находится нейролог – он имеет дело со структурой основных компонентов мозга. Однако он может изучать мозг на этом уровне, не заботясь о молекулярной структуре отдельных белков в нейроне. Химик–органик интересуется построением сложных аминокислот из таких компонентов, как атомы углерода, водорода, кислорода и хлора. Физик–ядерщик изучает систему на уровне элементарных частиц в атоме и взаимодействия между ними.

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

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

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

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

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

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

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

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