Ограничения проектирования

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

· Некое требование, которое допускает несколько вариантов проектирования; проект является осознанным выбором среди этих вариантов. Если это возможно, хотелось бы не указывать конкретный вариант в требованиях, а оставить выбор за разработчиками, так как они смогут лучше оценить технические и экономические характеристики каждого варианта. Если мы не оставляем возможности выбора ("Использовать СУБД Оrасlе"), возможности проектирования сужаются, утрачивается гибкость и свобода разработки.

· Требование, налагаемое на процесс создания программы ("Программировать на VB" или "Использовать ХYZ-библиотеку классов").

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

Рассмотрим определение.

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

Можно указать следующие источники ограничений проектирования.

• Операционные среды: Программы пишутся на Visual Basic.

• Совместимость с существующими системами: Приложение должно выполняться как на новой, так и на прежней нашей платформе.

• Прикладные стандарты: Использовать библиотеку классов из Developer’s Library 99-724 на корпоративном, сервере IT.

• Корпоративные практические наработки и стандарты: Должна обеспечиваться совместимость с существующей базой данных. Использовать стандарты программирования С++.

Еще одним важным источником ограничений проектирования являются разнообразные инструкции и стандарты, которым подчиняется разработка проекта. Например, разработка медицинских продуктов в США регулируется множеством инструкций и стандартов FDА (Управление по санитарному надзору за продуктами и медикаментами) которые касаются не только продукта, но и процесса его разработки и документирования. Среди организаций, инструкциям и стандартам которых должно отвечать проектирование, можно указать следующие.

• Управление по санитарному надзору за продуктами и медикаментами (FDА)

• Федеральная правительственная комиссия США по средствам связи (FСС)

• Министерство обороны (DОD)

• Международная организация по стандартизации (ISO)

• Лаборатории по технике безопасности (UL)

Как правило, сформулированные в виде разнообразных инструкций проектные ограничения этого типа слишком длинные, чтобы их можно было непосредственно включить в требования. В большинстве случаев достаточно внести их в список ограничений проектирования в форме ссылок. Таким образом, требование может иметь вид: Программа будет полностью соответствовать стандарту ТuV Software Standart, разделы 3.1-3.4.

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

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

· Следует отличать их от других требований. Например, если программные требования обозначены ярлыком "SR" (software requirement), для ограничении проектирования можно использовать ярлык "DC" (design constraint). Можно также пытаться различать истинные ограничения проектирования и регулирующие ограничения, но мы пришли к выводу, что это редко бывает полезно и может привести к непомерным затратам на поддержку.

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

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

· Следует документировать объяснения для каждого ограничения проектирован! Записывайте одно - два предложения, объясняющие, почему то или иное ограничение проектирования налагается на проект. Это поможет вам позднее вспомнить, что послужило мотивом для наложения конкретного ограничения. Как следует из нашего опыта, практически всегда возникает вопрос: "Почему мы наложили здесь, это ограничение?". Документирование пояснений позволяет более эффективно работать с ограничениями проектирования на более поздних фазах проекта, когда о них (неизбежно) зайдет речь.