Джозеф Фокс - Программное обеспечение и его разработка

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

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

Лос-Анжелесская группа из 500 разработчиков под моим руководством делала систему управления искусственным спутником. Спутник вышел на неправильную, нерегулярную траекторию. Некоторые приборы выполняли не те функции, для которых они были спроектированы, другие же не работали совсем. Ценой огромных усилий мои сотрудники сумели модифицировать программное обеспечение таким образом, чтобы задание все же было выполнено.

И вдруг мы обнаруживаем, что наш заказчик крайне расстроен тем обстоятельством, что нам пришлось выйти из бюджета! Мы терпеливо объясняли ему, что наш перерасход в 3 млн. долларов сэкономил ему несколько лет труда. Кроме того, мы спасли его от необходимости запускать новый спутник, что обошлось бы ему в 50 млн. Нас оправдали, но неохотно!

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

Определение требований для систем типов I и II — достаточно простой процесс, практически всегда он бывает сделан достаточно хорошо. Этого нельзя сказать о больших системах типов III, IV и V. Новизна вычислительной техники комбинируется с трудностью определения требований для больших систем, которые прежде никогда не строились. Люди никогда раньше не применяли автоматизированные системы в этих областях, поэтому они не сразу могут понять все возможности этих новых для них систем.

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

Таблица 5.3. Изменения в системах реального времени

В действительности лучше было бы задать такой вопрос: «Что же не будет меняться?». Ответ поможет нам определить самое первое требование для больших систем программного обеспечения, которое мы уже проводили на с.103.

Самое первое требование к проектированию больших систем программного обеспечения — предусмотреть возможность будущих изменений!

О том, как этого добиться, мы поговорим в разделе книги, посвященном проектированию программ.

Каким же образом мы приходим к первой формулировке требований? Я говорю «первой», поскольку мы знаем, что этот процесс будет повторен несколько раз по мере перехода от разработки требований к проектированию и обратно к выработке новых требований.

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

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

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

Таблица 5.4. Определение требований пользователем и проектировщиком

Проектировщик обычно не знаком со всеми тонкостями приложений. Если проектировщику позволить формулировать требования самостоятельно, он, вероятнее всего, пропустит некоторые тонкие, но весьма важные функции. Получив такую систему, пользователь может подумать, что ее проектировщики живут в башне из слоновой кости. Разработчик должен сформулировать требования к инфраструктуре, которые обычно непонятны пользователю. Чтобы адекватно отразить все потребности проекта, проектировщик и пользователь должны вырабатывать требования совместно. (См. табл. 5.4.)

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

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