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

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

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

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

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

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

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

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

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

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

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

При обычном ходе событий создается документ, который подписывают представители всех заинтересованных сторон. На него приклеивается этикетка «Требования», а затем он быстро забывается и выходит из употребления. Это архивный хлам, годный только на то, чтобы выискивать в нем ошибки. В одной системе министерства обороны США, состоявшей из программ в 1 млн. строк, в подобный документ в течение 8 лет не вносили изменений. А ведь программы изменялись! Документы с требованиями абсолютно необходимы для правильной организации работ по разработке, в них должны постоянно учитываться происходящие изменения. Для этого нужны деньги, и в течение всего времени жизни проекта им должны заниматься квалифицированные люди.

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

Если спросить их, то они конфиденциально ответят, что «знают все требования». В девяти случаях из десяти они не знают ни одного!

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

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

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

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