Разработка программ: Гибкое моделирование

Agile Modeling – гибкое моделирование

Agile Modeling (АМ) – это набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения (ПО).

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

АМ должен рассматриваться как дополнение к существующим методам, а не самостоятельная технология. Этот метод должен использоваться для повышения эффективности труда разработчиков, использующих процессы eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), или RUP.

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

АМ декларирует максимальное участие заинтересованных лиц, создание моделей и документов, доступных для понимания заинтересованными лицами. Документация должна быть предельно простой и краткой. Она должна соответствовать основному назначению – описанию проектируемой системы и быть понятной заинтересованным лицам. Допускается использование любых инструментальных средств, упрощающих и ускоряющих проектирование.

Цели Agile Modeling

1. Показать, как применять на практике набор понятий, принципов и приемов, позволяющих легко и просто выполнять моделирование. АМ сосредоточен не на технике построения конкретных диаграмм, а на том, как их использовать.
2. Показать, как использовать известные методики моделирования (XP, DSDM, RUP и др.) в гибком подходе к разработке проектов.
3. Повысить эффективность моделирования в проектах на разных стадиях (бизнес-анализ, формирование требований, анализ и дизайн).

Основные принципы Agile Modeling

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

• Предпочитайте простоту. Считайте простое решение наилучшим. Не вводите дополнительные свойства, не требующиеся сегодня. Стремитесь, чтобы модель была максимально простой. Нужно моделировать, основываясь на существующих требованиях, и пересматривать модель, если требования будут изменяться в будущем.
• Учитывайте изменения. Требования к системе эволюционируют, изменяются взгляды заинтересованных лиц и критерии их оценки ваших результатов. Это должно обязательно учитываться в проекте.
• Обеспечивайте будущую работу. Важно обеспечить возможность поддержки и выпуска следующих релизов ПО. Для этого требуется создать необходимую документацию по программному продукту и его поддержке. Надо определить, будет ли команда разработчиков ПО участвовать в следующем релизе, суть следующей работы, важность следующего релиза для вашей организации. То есть, не следует закрывать глаза на будущее.
• Вносите изменения последовательно. Не следует стремиться к абсолютной правильности модели сразу с самого начала. Маловероятно, что удастся достигнуть этого даже ценой сверхусилий. Вместо этого следует сначала строить небольшую модель высокого уровня и далее развивать ее инкрементным образом (либо удалить ее, если в ней не будет необходимости).
• Привлекайте больше заинтересованных лиц. Наиболее эффективно включить в команду представителей заинтересованных лиц (заказчика пользователей).
• Определяйте цели моделирования. Моделирование должно помочь лучшему пониманию системы. Возможно, модель понадобится для того, чтобы обосновать проект перед руководством, возможно, потребуется ее включение в документацию для пользователей или тех, кто будет выполнять поддержку. Если вы не можете определить, для кого и зачем создается модель, зачем это делать вообще? Первым шагом должно быть определение точного назначения модели и для кого она предназначена. Затем, исходя из этого, строится модель с той степенью детализации, которая требуется для поставленной цели. После этого построение этой модели заканчивается и можно перейти к другой работе, например, написанию кода, который показывает, как модель работает. Этот принцип применяется и при внесении изменений в существующую модель. Должна быть существенная причина для внесения изменений (например, введение нового требования или необходимость уточнения). Нужно четко знать для кого предназначена модель и что нужно этому потребителю (например, программисту).
• Используйте много моделей. Для разработки ПО необходимо построить много моделей, каждая из которых описывает некоторый аспект проблемы. Нужно иметь комплекс методик проектирования на базе выбранного инструментального средства. Важно отметить, что не требуется всегда строить весь набор моделей для любой системы. В зависимости от природы ПО создаются то или иное подмножество возможного набора моделей.
• Обеспечивайте качество. Не должно быть неряшливо сделанных работ. Результаты такой работы трудно понимаемы, не говоря уже об их обновлении. В некачественном коде тяжело разбираться и его трудно сопровождать.
• Обеспечьте быструю обратную связь. Обычно вы работаете над моделью совместно с другими людьми, то есть осуществляется процесс разделенного моделирования. Здесь важна быстрая обратная связь. Используя техники совместного моделирования, вы получаете мгновенный ответ на свои идеи. Если речь идет о заказчике, то здесь важно обеспечить быстрое и правильное понимание им требований, и анализ пользовательского интерфейса.
• ПО – главная цель. Главная задача – создать ПО, эффективно отвечающее нуждам заказчика и других заинтересованных лиц. Избегайте создания излишней документации или моделей. Ни одна деятельность, напрямую не связанная с главной задачей, не должна выполняться.
• Минимизируйте количество создаваемых документов. Каждый создаваемый артефакт должен поддерживаться в дальнейшем. Если вы используете несколько моделей, то при внесении изменений необходимо оценить их влияние на все эти модели и выполнить их изменение. Чем больше поддерживаемых артефактов, тем сложнее внесение изменений. Точно также сложнее поддерживать более детальные модели. Решив поддерживать определенную модель, вы теряете в скорости, но получаете возможность предоставления дополнительной информации для разработчиков. Не следует недооценивать серьезность потерь времени. Поддерживая много моделей, вы можете заметить, что большой объем времени требуется на обновление этих документов, а не на написание кодов.

Дополнительные принципы

• Содержание более важно, чем репрезентативность. Каждую модель можно представить многими способами. Модель не обязана быть выходным документом. Сложный набор диаграмм, построенных с помощью инструментальных средств, может рассматриваться как исходные данные для других артефактов, например, исходного кода и не являться официальной документацией. Таким образом, можно использовать преимущества моделирования без потерь времени и ресурсов на документирование.
• Учиться друг у друга. Технологии программирования меняются быстро, например, Java. Технология моделирования меняется медленнее, но тоже изменяется. Работа в команде дает возможность обмениваться знаниями, приемами навыками.
• Знайте ваши модели. Для эффективного использования моделей важно знать их сильные и слабые стороны.
• Знайте инструментальные средства. Вы должны хорошо знать средства моделирования, их свойства и как применять на практике.
• Адаптация к особенностям. Подход к разработке ПО должен учитывать особенности организации разработчика, лиц, заинтересованных в проекте и типа самого проекта. Следует иметь методики моделирования, использования инструментальных средств, описание процесса (технологию).
• Открытое взаимодействие. Все должны иметь возможность высказывать свое мнение и предложения по моделированию, требованиям, срокам и т. д. Это позволяет выбирать наилучшие решения, основываясь на более точной, качественной информации.
• Используйте интуицию. Если кто-то чувствует, что некоторые вещи в проекте не согласованы, то в большинстве случаев это так и есть. Если вам кажется, что требование не имеет смысла, следует это тщательно исследовать совместно с пользователем. Аналогично следует поступать при выборе архитектурных решений. Из двух равноценных вариантов выбирайте тот, который вам подсказывает интуиция.

Приемы гибкого моделирования (практики)

АМ предлагает набор приемов работы (называемых практиками), отвечающих сформулированным принципам.

• Активное участие заинтересованных лиц. Необходимо иметь прямую связь с пользователями, которые имеют право и возможность предоставлять информацию, имеющую отношение к системе, и принимать решения относительно требований и их приоритетов. В число таких людей входят непосредственные пользователи, руководство, операторы, служба поддержки.
• Используйте подходящие артефакты. Каждый артефакт имеет собственное применение. Например, диаграммы деятельностей UML полезны для описания бизнес-процессов, в то время как статическая структура БД лучше представляет физические данные. Нужно знать достоинства и недостатки каждого вида представления, чтобы определить, когда какое нужно или не нужно.
• Коллективная собственность. Каждый участник проекта должен иметь возможность работать с любой моделью или другим артефактом.
• Учитывайте тестируемость. При моделировании целесообразно периодически задаваться вопросом «Как это тестировать?», поскольку нельзя создавать нетестируемые приложения. Процессы тестирования и обеспечения качества должны охватывать весь жизненный цикл.
• Параллельное моделирование. Поскольку каждый тип модели имеет свои достоинства и недостатки, одной модели недостаточно. Например, при выявлении требований можно создавать варианты использования или пользовательские описания, прототип UI и бизнес правила. Одновременная работа с несколькими моделями дает больший эффект за счет влияния на другие артефакты (см. следующее правило).
• Переход к другому артефакту. Если вы, работая над некоторым артефактом (вариант использования, CRC-карта, диаграмма последовательности и т. д.), застряли, переключитесь на время на другой. В этом случае можно продвинуться дальше, работая над другим артефактом. Более того, меняя взгляд на систему, можно понять то, что не удалось в первом случае.
• Простота. Смысловое содержание моделей модели – требований, архитектурных, аналитических и др. – должно быть как можно более простым и понятным для всех заинтересованных лиц. Не добавляйте излишних аспектов в модели, если это не оправдано. Если, например, у вас нет требования реализовать в системе функции контроля, не добавляйте их в модель.
• Используйте простую нотацию. Простая модель показывает ключевые свойства, например ответственности классов и их отношения, поэтому обычно используется небольшое подмножество выразительных средств для каждого вида диаграмм. Не следует тратить время на модели, которые не потребуются для дальнейшей работы. Вряд ли понадобится создание модели для всего кода.
• Общедоступность модели. Все модели должны быть доступны всем заинтересованным лицам. Организуйте простой доступ ко всем моделям. Их можно разместить на доске, создать сайт для представления в электронном виде и т. д.
• Инкрементное развитие моделей. Последовательное развитие моделей позволяет быстрее передать ПО заказчику (от 2 недель до одного-двух месяцев).
• Групповое моделирование. Моделирование служит для понимания чего-то, для распространения идей для всех, для выработки единой точки зрения, единого видения проекта. Модель позволяет путем обсуждения согласовать точки зрения членов команды разработчиков, объединить их идеи самым простым способом.
• Проверка модели кодом. Модель – это абстракция, она должна точно отражать аспекты того, что вы создаете. Необходимо проверять модель кодом. Эскизы страниц пользовательского интерфейса следует показать заинтересованным лицам. Построив модель фрагмента бизнеса, напишите тесты и код программы и прогоните тесты, чтобы убедиться, что все правильно. Не забывайте, что для большинства проектов моделирование – только один из видов выполняемых работ.
• Используйте самые простые средства. Большинство моделей могут быть построены на бумаге или доске, поскольку впоследствии они все равно становятся ненужными. Построение модели служит для понимания. Инструментальные средства используются только, если модель должна быть презентирована заинтересованным лицам или в ней есть необходимость при программировании (автоматическая генерация кода).

Дополнительные правила

• Используйте стандарт моделирования. Применяется UML и стандарты кодирования для названий атрибутов, методов, отношений.
• Используйте проектные шаблоны с осторожностью. Если вы считаете, что проектный шаблон (паттерн) можно использовать так, чтобы реализовать при моделировании минимальный объем, отражающий состояние на сегодняшний день, а потом сделать улучшения, то это лучший путь. Другими словами, не перегружайте модель излишними деталями.
• Избавляйтесь от временных моделей. Большинство моделей в проекте имеют временный характер. Они сделали свое дело и не вносят далее ничего нового. Многие из них быстро перестают соответствовать коду. Их либо надо обновить, либо просто удалить, особенно в случае, когда потери времени на обновление модели не окупаются значением ее для проекта.
• Формализуйте контрактные модели. Контрактные модели требуются, когда информационные ресурсы, требуемые системой, предоставляются извне (БД, наследуемое приложение, информационный сервис). Контрактная модель должна быть согласована с обеими сторонами и при необходимости изменяться совместно. Эти модели практически всегда создаются и поддерживаются с помощью инструментальных средств. Как и в случае обычного контракта для разработки и поддержки контрактной модели должны быть выделены ресурсы. Число таких моделей должно быть минимизировано.
• Модель служит для коммуникации. Модель используется для коммуникации с людьми, внешними по отношению к команде разработчиков. Поскольку эти люди обычно территориально разделены, для этого используются инструментальные средства.
• Модель служит для понимания. Важное применение модели – объяснение проблемной области, анализ требований к системе, сравнение возможных альтернатив с целью выбора самого простого решения.
• Повторное использование. Здесь имеется в виду возможность использования уже существующих моделей, если таковые есть.
• Обновление только при необходимости. Нужно обновлять модель только при острой необходимости, когда потери времени на обновление менее болезненны, чем применение устаревшей модели. Используя это правило, вы обнаружите, что вам придется обновлять гораздо меньше моделей, чем реально создано.