Внешнее проектирование

Внешнее проектирование – это этап описания ожидаемого поведения разрабатываемого программного продукта с точки зрения внешнего по от­ношению к нему наблюдателя [3]. Цель этого этапа – «конструирование» внешних взаимодействий будущего продукта (обычно с пользователем) без конкретизации его внутреннего устройства. Внешний проект выража­ется в форме внешних спецификаций, предназначенных для широкой ау­дитории, включающей пользователя (для проверки и одобрения), авторов документации для пользователя, всех участвующих в проекте программи­стов, а также всех тех, кто будет заниматься тестированием продукта.

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

Хотя методологии внешнего проектирования не существует, важно соблюдать принцип концептуальной целостности. Концептуальная цело­стность – это гармония (или стремление к ней) между внешними функ­циями системы; в соответствии с этой концепцией лучше иметь относи­тельно небольшой набор хорошо согласованных функций, чем, возможно, больший набор независимых и нескоординированных функций. Особенно­сти, которые кажутся привлекательными, но не согласуются с остальными, вероятно, следует отклонить, чтобы не усложнять взаимодействия с поль­зователем.

Концептуальная целостность представляет собой меру единообразия способа взаимодействия с пользователем. Система, лишенная концепту­альной целостности, – это система, в основе которой нет единообразия; в результате такая система характеризуется слишком сложным взаимодейст­вием с пользователем и излишне сложной структурой. Поскольку концеп­туальная целостность – всего лишь идея, ее трудно описать в деталях, так как она изменяется в зависимости от применения. Например, система с разделением времени, обладающая концептуальной целостностью, будет иметь, по крайней мере, следующие характеристики. Все возможности, доступные пользователю переднего плана, доступны также пользователю заднего плана (фоновый режим), и наоборот. Все запросы обладают внут­ренней симметрией по отношению к синтаксису, именам, операндам, со­глашениям и правилам умолчания. Семантика всех запросов согласована. Например, блоки вводимых данных для аналитической и имитационной модели должны совпадать, насколько это возможно, т.е. одинаковые пере­менные должны называться одинаково и располагаться в том же порядке. Характеристики терминала и сообщения об ошибках – общие для всех за­просов.

Простейший способ добиться отсутствия концептуальной целост­ности – попытаться разрабатывать внешний проект слишком большой группой. В зависимости от масштабов проекта ответственность за внешнее проектирование должны нести один-два человека.

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

Внешнее проектирование мало чем связано с программированием; более непосредственно оно касается обстановки, проблем и нужд пользо­вателя, психологии общения человека с машиной. Более того, эта сторона внешнего проектирования становится все более значимой по мере того, как применение ЭВМ все больше начинает затрагивать пользовате­лей, не зна­комых с программированием. Из-за сложностей внешнего про­ектирования и его возрастающей важности для разработки ПО оно требует специали­стов особого рода. В качестве возможных кандидатов можно на­звать сис­темных аналитиков, психологов, занимающихся вопросами пове­дения, инженеров, а возможно, и опытных специалистов по теории про­граммиро­вания (если их подготовка включает упомянутые области).