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

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

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

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

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

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

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

Новые методы определения требований

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

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

Для всех методологий характерно следующее:

— Разбиение на уровни абстракции. (Особенно важно для анализа сложных систем.)

— Ограниченное число элементов, приходящихся на один уровень абстракции — очень существенно для успеха, — обычно 7 или меньше.

— Ограниченный контекст: в него включается лишь то, что входит в процесс, все, что в процесс не входит, исключается.

— Включаться должны как данные, так и действия над ними.

Новые методы улучшения процесса определения требований многообещающи и сложны. Обычно они представляют собой комбинации методов документирования и правил ведения работ.

Вот некоторые из этих методов:

SADT	Технология структурного анализа и проектирования
IA	Информационный анализ
HIPO	Иерархические схемы ввода, обработки, вывода
PSL/PSA	Язык постановки задачи/анализатор постановки задачи
RSL/REVS	Язык формулировок требований/системы вычислений и оценок требований
CARA	Анализ требований с помощью вычислительных машин

Большинство методов основано на строгих формальных правилах записи и последовательном приближении к конечному результату.

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

Личный опыт

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

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

Резюме: требования к большим системам программного обеспечения