Программное обеспечение и его разработка

Не влияют на системы	Влияют на системы
Число пользователей	Спутник
Стратегия	Радиолокатор
Тактика	Датчики
Структура организации пользователей	Дисплеи
	Навигационное оборудование
Режим работы пользователя	Стартовая площадка
Приоритеты	Ракета
Сети связи	Интеллектуальные терминалы
Стратегия принятия решения
Угроза

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

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

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

Кто формулирует требования к программному обеспечению?

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

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

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

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

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

	Формулирование требований
	Может сделать	Пропустит
Пользователь	Ясно выразить важные потребности	Требования к технологии
	Правильно расставить приоритеты	Потребности инфраструктуры
Проектировщик	Определить состояние дел в технологии	Сортировку интересов пользователя
	Определить полноту сформулированных требований	Тонкости прикладной области

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

Язык документирования требований

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

Особая важность требований

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

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

В августе 1977 г. министерство обороны США провело изучение основных автоматизированных систем. Большинство из них были системами связи. Это были системы:

1) TRI — ТАС;

2) LDMX/NAVCOMPARS и AMMC/SRT;

3) SATIN IV;

4) WMMCCS NORAD/COC;

5) WWMCCS ADP — LANTCOM;

6) Телекоммуникационный центр Пентагона;

7) WWMCCS ADP — CCTC;

8) Автоматизированный технологический контроль;

9) CUDIX/NAVMASC.

Изучение показало:

— Во всех системах требования были неустойчивыми и подвергались пересмотру; чем больше была система, тем большие изменения вносились в них.

— В большинстве систем отсутствовал формальный механизм отслеживания и управления процессом выработки требований.

— Некоторые разработчики даже не смогли осознать необходимость обоснования требований.

— В большинстве систем не было отбоя от «списков пожеланий».

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

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

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

1) формулируйте требования с максимально возможной строгостью;

2) заранее планируйте изменчивость системы.

Кто является действительным пользователем в любом проекте?

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

Когда в начале 1970-х гг. мы успешно завершили первую рабочую версию новой системы управления воздушными перевозками, мы испытали чувство огромного удовлетворения. Группа определения требований FAA подписала свидетельство о завершении работ. Это была настоящая волокита.

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

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

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

Такая методика обходится значительно дороже! Последовательное введение функций в действие занимает больше времени. Но у нас нет выбора.

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

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

Чем более крупную систему создают разработчики, тем больше она подвержена опасности стать излишне сложной в использовании. Может получиться и так, что система будет решать давно решенную проблему.

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

Противоречивые требования разных пользователей

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

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

Через несколько лет после описанного случая мы понесли убыток еще на 10 млн. долларов. В это время мы были заняты автоматизацией двух новых нефтеочистительных заводов фирмы «Эксон» — в Эдмонтоне, Канада, и в Антверпене, Бельгия. И опять возникли те же проблемы, сначала мы пытались понять, какие функции нужно вносить в систему, а затем пытались удовлетворить сразу двух разных пользователей. То, что оба этих завода входили в одну компанию «Эксон», еще не означало, что среди них имелось согласие по поводу способов управления процессом очистки. Но опять-таки система работала! И работала хорошо. Просто заранее оказалось сложным оценить весь объем работ с достаточной точностью.

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

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

Требования к товарным программам и программному обеспечению проектов

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

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

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

Изменения, вносимые пользователем

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

Адаптируемость способствует непрекращающимся изменениям

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

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

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

Определение требований — это длительный процесс

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

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

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

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

Спецификация требований

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

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

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

Определение требований к окружающей обстановке в фазе использования

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

Главными факторами фазы использования являются:

1) требования надежности;

2) требования скорости реакции системы;

3) требования реального времени;

4) требования диалогового режима.

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

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

У разработчика часто возникает возможность навязать пользователю некоторый режим работы! Но эту возможность надо еще заметить и уметь ею воспользоваться! Однажды на моих глазах одна большая система типа III перерастала в систему типа V, потому что никто не сказал пользователям — руководству системы — о том, что систему можно выключать на несколько часов. Это было бы приемлемым условием. Пользователь не простаивал бы без дела, данных для него было вполне достаточно. Система могла не быть безотказной! Но кто-то, опережая требования пользователя — и весьма опрометчиво, — потребовал, чтобы система не имела отказов.

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

Управление процессом выработки требований

Требования нельзя просто «собрать» и документировать. Ими нужно управлять! Особенно это необходимо при создании товарных программ. Очень многие товарные программы пропадали — а в них были вложены десятки миллионов долларов — только потому, что руководитель разработки согласился на слишком широкий набор требований. Некоторые называют избыток требований «потерей элегантности». Лучшее — враг хорошего. Обычно оно бывает пагубным. Торговцы всегда будут настаивать на включении n-й функции; руководитель разработки должен отказываться от внесения добавлений к требованиям.

Это же относится и к проектам типов III, IV и V. Все пожелания пользователя даже просто перечислить невозможно (мы предполагаем, что нам удалось найти подлинного пользователя). Это слишком перегрузило бы систему. К тому же пользователь часто и не знает, что необходимо и сколько стоит то, что желательно.

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