Человеческий фактор в программировании.

Альтернативы и альтернативные точки зрения.

Все проектирование основано на компромиссах. Исследование, проведенное более тридцати лет назад, показало, что эффективные инженеры-про-ектировщики обычно сравнивают два или более альтернативных подхода к каждой существенной задаче. В разработке программного обеспечения эта стратегия может применяться так же успешно, как и в сферах деятельности с более богатой историей. (Моя диссертация в Массачусетском технологическом институте была как раз посвящена этому вопросу.) Сравнение альтернативных подходов может происходить быстро и главным образом в уме, или же оно может включать в себя составление сложных описаний и моделирование каждого варианта с тщательным анализом и оценкой всех результатов. В итоге может появиться ясная выигрышная стратегия, но иногда предпочтение отдается творческому синтезу на основе более чем одной альтернативы или компромиссу. Важнейшей частью процесса является взвешивание альтернативных вариантов с помощью прямого сопоставления двух схем или интерпретаций. Большинство современных САSЕ-инструментов не позволяют оставлять активными и доступными две версии одной системы, диаграммы или модели и уж точно не дают возможности их непосредственного сравнения.

Я видел несколько довольно хитрых способов, предназначенных для преодоления этого ограничения. В одной фирме у системного аналитика были в распоряжении две рабочие станции. На одной из них он вносил изменения и таким образом мог анализировать преимущества и недостатки сразу двух полных версий одной системы. Однако чаще всего альтернативный вариант содержится на бумаге, а другой — в хранилище САSЕ-инструмента.

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

Даже так называемые «интегрированные» наборы САSЕ-инструментов обычно не дают возможности просто и быстро переходить от одной модели системы к другой. Такие переходы должны осуществляться одним нажатием клавиши. Еще лучше, если будет предусмотрена возможность наглядного сопоставления. Окна не очень подходят для этого. К тому времени, как вы откроете два окна в САSЕ-инструменте, работающем в оконном режиме или среде, на экране уже не останется места, чтобы хорошо рассмотреть что-либо. Или будет виден только небольшой кусочек каждой схемы, или на экране будут отображены маленькие, нечитаемые символы и текст. Вряд ли компьютер может помочь[24] в разработке программного обеспечения!