Критерии качества архитектурного проекта
Архитектурный проект должен быть понятным, простым для модификации и обеспечивать высокую эффективность программного изделия. Эффективность определяется минимальным использованием имеющихся ресурсов, а простота модификации — незначительными затратами на сопровождение. Для достижения этих целей обычно стремятся упростить форму и функции каждой части архитектурного проекта. Для измерения сложности имеется ряд метрик, которые целесообразно использовать при проектировании. Функциональная простота характеризуется "связностью" отдельных компонент, т.е. внутренней структурой компоненты. При проектировании стремятся максимизировать связность каждой компоненты.
Простота формы достигается в результате:
• минимизации "сцепления" между компонентами;
• обеспечения соответствия функции, выполняемой компонентой, уровню иерархии;
• согласования программного обеспечения со структурами данных;
• максимизации числа компонент, использующих данную компоненту;
• ограничения числа подчиненных компонент;
• удаления дублирования между компонентами путем создания новых компонент.
Архитектурный проект должен быть модульным, с минимальным сцеплением между компонентами и с максимальной связностью внутри каждой из них. Компоненты модульной схемы должны описываться как "черные ящики", скрывая информацию о их внутренней структуре от других компонент. Важно знать, что они делают, а не как они работают.
Для упрощения понимания при описании проектов используются стандарты и соответствующая терминология; для решения одинаковых проблем — одинаковые решения. Для достижения единообразия и сопоставимости описаний разных частей проекта необходимо использовать стандарты на проектирование, CASE-средства и систематические обзоры проектных решений.
Выбор альтернативных решений может явиться хорошим и эффективным средством повышения качества проекта. Для выбора лучшего варианта необходимы соответствующие критерии, которые зависят от типа системы.
Например, для системы реального времени важным является время ответа или время реакции системы, а для административной системы — стабильность базы данных. Для оценки альтернативных вариантов или для проверки сделанных допущений может использоваться прототип изделия. Например, для достижения высокой оперативности системы могут быть запрограммированы разные методы доступа к файлам базы данных, а разные методы могут привести к разным подходам в проектировании. Поэтому создание прототипов может оказаться частью процесса проектирования.
В документе Архитектурный проект программного изделия должен быть отражен один выбранный подход к решению поставленной проблемы, но в документе История проекта обычно описываются такие моменты, как необходимость создания прототипа, перечень разработанных программ, критерии выбора альтернатив и причины, определившие выбор варианта.
Документ Архитектурный проект программного изделия — ключевой документ, суммирующий все принятые решения. Он является основой для детального проектирования. Кроме описания всех компонент изделия, он должен содержать ссылки на все внешние интерфейсы. Одно из основных требований к документу — требование полноты охвата всех требований к программному изделию, представленных в предыдущем документе. Для демонстрации полноты в документ должна быть включена таблица перекрестных ссылок между требованиями к программному изделию и компонентами архитектурного проекта. Документ не может быть противоречивым, для чего прибегают к методам и средствам программотехники. Документ Архитектурный проект должен быть достаточно детальным, позволяющим управленцу составить план следующей фазы проектирования. Степень детализации на уровне архитектурного проекта должна также обеспечивать возможность более точной оценки стоимости работ последующих фаз разработки программного изделия.
