■ Использовать метрики и показатели для измерения прогресса и качества архитектуры по мере того, как она развивается от прототипа высокого уровня до полностью готового продукта.
■ В течение всего жизненного цикла обеспечивать среду, поддерживающую раннее и постоянное управление конфигурацией и изменениями, строгие методы разработки, автоматизацию документирования и автоматизацию регрессионного тестирования.
■ Использовать визуальное моделирование и языки высокого уровня, которые поддерживают управление архитектурой, абстракцию, надежное программирование, повторное использование и самодокументирование.
■ Рано и постоянно вникать в проблемы производительности с помощью оценок, основанных на демонстрациях. .
Таблица 3.5.
Общее повышение качества в современном процессе
Фактор, влияющий на качество | Традиционный процесс | Современный итерационный процесс |
Недостаточное понимание требований | Поздно обнаруживается | Рано выявляется |
Риски разработки | Неизвестны до последнего момента | Оказываются понятными и разрешаются на ранних этапах |
Коммерческие компоненты | Большей частью недоступны | Непосредственно влияют на качество, однако решения по их использованию должны приниматься на ранних стадиях жизненного цикла |
Управление изменениями | На поздних этапах жизненного цикла, хаотичное и приносящее вред | На ранних этапах жизненного цикла, непосредственное и в простой форме |
Ошибки разработки | Вскрываются поздно | Разрешаются рано |
Автоматизация | Преимущественно чреватые ошибками процедуры, выполняемые вручную | Преимущественно автоматизированное преобразование продуктов с минимальными ошибками |
Достаточность ресурсов | Непредсказуемая | Предсказуемая |
Сроки | Чрезмерно ограниченные | Определяются качеством, производительностью и технологией |
Результирующая. производительность | «Бумажный» анализ или раздельная имитация | Выполняемые прототипы, ранняя обратная связь, количественные оценки |
Строгость процесса создания ПО | Основан на документации | Управляемый, измеряемый и поддерживаемый инструментами |
Дополнительные возможности вникать в проблемы производительности работающей системы становятся все более важными, поскольку проекты включают в себя как коммерческие компоненты, так и компоненты, произведенные на заказ. В традиционном процессе разработки ПО особое внимание уделяется раннему получению оценок размера и времени, используемых компьютерной программой. Однако типичной хронологической последовательностью при оценке производительности является следующая:.
■ Начало проекта. Предложенный проект утверждается как малорискованный с адекватными границами производительности.
■ Начальный обзор разработки. Оптимистические оценки адекватных границ при разработке базируются преимущественно на «бумажном» анализе и грубых моделях критичных вариантов. В большинстве случаев к этому моменту становится абсолютно ясно, какие.
на самом деле будут использоваться алгоритмы и каковы будут размеры баз данных. Однако полная инфраструктура, включая затраты на операционную систему, систему управления базой данных и на межпроцессное и сетевое взаимодействие, а также все вторичные процессы обычно еще неясны.
■ Рассмотрение разработки в середине жизненного цикла. Границы оценок постепенно сужаются по мере того, как первые контрольные цифры и начальные тесты начинают подтверждать тот оптимизм, который был присущ более ранним оценкам.
■ Интеграция и тестирование. Обнаруживаются серьезные проблемы с производительностью, возникает необходимость внесения фундаментальных изменений в архитектуру. Обычно во всем винят лежащую в основе инфраструктуру, хотя настоящими виновниками являются неправильное использование инфраструктуры, несовершенные архитектурные решения либо плохо понятые ранние договоренности по разработке.
Такая последовательность имеет место, поскольку первые представления о производительности базировались исключительно на наивных оценках, сделанных разработчиками на основе бесчисленного множества критериев. В распределенных системах, состоящих из множества взаимодействующих между собой компонентов, подход, основанный на демонстрациях, позволяет значительно точнее оценить проблемы производительности. Ранние демонстрации могут осуществляться на платформе, на которой выполняется разработка, или на платформе, на которой будет производиться эксплуатация, либо на частично сконфигурированных сетях. Как бы то ни было, они могут быть спланированы и направлены на то, чтобы стать плодотворным инженерным экспериментом. Проблемы с производительностью на начальных стадиях типичны. Более того, они могут оказаться полезными, поскольку позволяют выявлять недостатки в архитектуре и слабость коммерческих компонентов на ранних стадиях жизненного цикла, когда еще можно внести необходимые поправки.