ManageExpert.ru

Успешный менеджмент

Re: Архитектура

Возможно, для этого надо заново пересмотреть место архитектуры программного обеспечения в процессе разработки. Обычно под архитектурой мы понимаем нечто, предшествующее построению. Однако так же, как можно переписать код, можно перестроить и архитектуру (в мире экстремального программирования такая процедура называется рефакторин-гом). Например, одному большому банку в Австралии пришлось вернуться к своим традиционным системам после того, как был прекращен один претенциозный и чрезмерно крупный проект построения новой общебанковской информационной системы. Прежняя система объединяла многие поколения клуджей[Клудж (от англ. kludge) — устройство, программа или ее часть, которые теоретически не должны работать, но почему-то работают. — Примеч. ред.

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

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

Такой процесс является разновидностью концентрической разработки — рационализованной моделью быстрого создания прототипов с итеративной доработкой. Такая доработка начинается с базовых функций, обеспечивающих основной набор возможностей для пользователя. Эти функции определяются на основе отобранного подмножества пользовательских ситуаций или абстрактных сценариев, которые готовая система должна поддерживать (см. главу 22). Создание ядра законченных пользовательских ситуаций обеспечивает поддержку всех задач, а не только отдельных фрагментов функциональности. Далее в систему концентрическими слоями добавляются дополнительные возможности и украшения. С каж-дым новым слоем обзор архитектуры позволяет определить, какие доработки и изменения необходимо провести для того, чтобы повысить устойчивость системы к последующим улучшениям. Такие архитектурные изменения включаются в общий план работ на текущий цикл концентрической разработки,

Перейти на страницу: 1 2 3