Программное обеспечение и его разработка
Шрифт:
Самое первое требование к проектированию больших систем программного обеспечения — предусмотреть возможность будущих изменений!
О том, как этого добиться, мы поговорим в разделе книги, посвященном проектированию программ.
Каким же образом мы приходим к первой формулировке требований? Я говорю «первой», поскольку мы знаем, что этот процесс будет повторен несколько раз по мере перехода от разработки требований к проектированию и обратно к выработке новых требований.
Кому пристало
Пользователь знаком с приложениями и большинством нюансов любого сложного проекта. Пользователь должен быть абсолютно уверен, что требования точно и полно отражают стоящую перед ним проблему.
Пользователь не знаком с состоянием технологии и не понимает, что сделать легко, а что сложно. Когда пользователь один формулирует требования, часто оказывается, что возникают технологически наивные формулировки требований, запрашивающие либо слишком много, либо очень мало.
Таблица 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 подписала свидетельство о завершении работ. Это была настоящая волокита.
Система была отправлена в Джексонвилл, шт. Флорида, для испытаний в рабочих условиях в ночную смену в Центре управления авиаперевозками. Однако диспетчеры из Джексонвилла отказались пользоваться ею — они заявили, что она «ненадежна».