Scrum Framework

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Цель Руководства по Скраму

Скрам (Scrum) – это подход для разработки и поддержки функционально сложных продуктов. Данное руководство содержит определение Скрама. Определение включает в себя описание ролей, мероприятий и артефактов Скрама, а также правил, обеспечивающих связь между ними. Кен Швабер и Джефф Сазерленд разработали Скрам; руководство по Скраму написано и представлено ими. Они являются основателями данного руководства по Скраму.

Общее Описание Скрама

Скрам (Scrum – потасовка, драка за мяч в регби) – это подход, в рамках которого возможно решить сложные адаптивные проблемы, и в то же время продуктивно и с применением творческого подхода разработать продукт наивысшего качества. Скрам является:

  • Легким
  • Простым в понимании
  • Чрезвычайно сложным в овладении

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

Скрам Подход (Scrum Framework)

Скрам состоит из Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles), а также мероприятий (events), артефактов (artifacts) и правил (rules). Каждый компонент Скрама имеет свое предназначение и является ключевым для успеха и использования Скрама.
Различные стратегии использования Скрама изменяются, и их описание выходит за пределы данного руководства.
Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Скрама прописаны в данном документе.

Scrum FrameworkТеория Скрама

Скрам основывается на теории управления эмпирическими процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит с опытом и принятием решений на основании того, что является известным. Скрам использует итеративный, инкрементальный подход для оптимизации прогнозируемости и управления рисками.
В основе управления эмпирическими процессами лежат три главных принципа: прозрачность (transparency), проверка (inspection) и адаптация (adaptation).

Прозрачность

Значительные аспекты процесса должны быть видимыми ответственным за результат. Прозрачность требует, чтобы эти аспекты определялись общими стандартами, позволяя всем наблюдателям разделять единое понимание видимого.
Например:

  • Все участники процесса должны пользоваться общей терминологией, относящейся к процессу;
  • Исполняющие работу и оценивающие ее результат в виде продукта должны иметь единое определение “Готовности”1.

Проверка

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

Адаптация

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

Согласно подразделу данного документа Мероприятия Скрама, Скрам предписывает четыре формальные возможности для проверки и адаптации.

  • Планирование Спринта (Sprint Planning Meeting)
  • Ежедневный Скрам (Daily Scrum)
  • Обзор Спринта (Sprint Review Meeting)
  • Ретроспектива Спринта (Sprint Retrospective)

Скрам

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

Скрам Команда

Скрам Команда состоит из

  • Владельца Продукта (Product Owner),
  • Команды Разработчиков (Development Team) и
  • Скрам Мастера (Scrum Master).

Команда Scrum

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

Владелец Продукта

Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.
Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту (Product Backlog). Управление Журналом Продукта включает в себя:

  • Четкое определение элементов Журнала Продукта;
  • Упорядочение элементов Журнала Продукта для оптимизации достижения целей и поставленных задач;
  • Ответственность за ценность работы, исполняемой Командой Разработчиков;
  • Обеспечение доступности, прозрачности и понятности Журнала Продукта, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время.
  • Ответственность за понимание Командой Разработчиков требований Журнала Продукта на надлежащем уровне.

Владелец Продукта может либо сам выполнять вышеперечисленные функции, либо предоставить их выполнение членам Команды Разработчиков. Однако подотчетным считается именно Владелец Продукта.

Владелец Продукта это только один человек, а не группа. Владелец Продукта может представлять интересы группы в Журнале Продукта, но желающие изменить приоритетность требований в Журнале Продукта должны в первую очередь убедить в этом Владельца Продукта.
Для успешного выполнения Владельцем Продукта своих обязанностей все члены организации должны уважать его решение. Все решения Владельца Продукта видны через содержимое и упорядочение Журнала Продукта. Никто другой не может заставить Команду Разработчиков работать согласно иным требованиям, да и самой Команде Разработчиков запрещается слушать кого-либо с иным мнением.

Команда Разработчиков

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

Командам Разработчиков присущи следующие характеристики:

  • Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности;
  • Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта;
  • Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений;
  • Отдельные члены Команды Разработчиков могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым.
  • У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа.

Размер Команды Разработчиков

Оптимальный размер Команды Разработчиков должен быть довольно небольшим, чтобы Команда оставалась простой в управлении и в то же время довольно большим, чтобы выполнить значимый объем работы. Если в Команде Разработчиков менее трех человек, взаимодействие уменьшается, что приводит к снижению продуктивности. Кроме того, на определенном этапе Спринта у небольшой Команды может почувствоваться недостаток необходимых знаний, вследствие чего она будет не в состоянии завершить работу над потенциально готовым к выпуску Инкрементом продукта. Если же в Команде более девяти человек, нужно прилагать больше усилий для координации их работы. Большие Команды Разработчиков создают слишком много сложностей для управления эмпирическим процессом. Роли Владельца Продукта и Скрам Мастера не учитываются при подсчете размера Команды Разработчиков за исключением случаев, когда они выполняют работу из Журнала Спринта.

Скрам Мастер

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

Обязанности Скрам Мастера по отношению к Владельцу Продукта

Скрам Мастер во многом помогает Владельцу Продукта, в частности:

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

Обязанности Скрам Мастера по отношению к Команде Разработчиков

Скрам Мастер во многом помогает Команде Разработчиков, в частности:

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

Обязанности Скрам Мастера по отношению к Организации

Скрам Мастер во многом помогает организации, в частности:

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

Мероприятия Скрама

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

Мероприятия scrum (скрама)

Спринт

Сердцем Скрама является Спринт, с временными рамками (time-boxes) в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта. Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Спринт состоит из Планирования Спринта, Ежедневных Скрамов, работы по разработке, встрече по Обзору Спринта, а также Ретроспективы Спринта.

Во время Спринта:

  • Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal);
  • Состав Команды Разработчиков и цели по качеству продукта остаются неизменными;
  • Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

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

Отмена Спринта

Спринт можно остановить перед окончанием его временных рамок. Только у Владельца Продукта есть право на то, чтобы остановить Спринт, хотя он может сделать это и под влиянием заинтересованных лиц, Команды Разработчиков или же Скрам Мастера.
Спринт отменяют в том случае, если его цели перестают быть актуальными. Это может произойти вследствие изменения направления работы компании, изменения технологий или рыночных условий. В общем, Спринт нужно отменить, если в силу некоторых обстоятельств в нем уже нет необходимости. Однако, принимая во внимание его короткую продолжительность, отмена редко имеет смысл.
При отмене Спринта все выполненные и “готовые” элементы из Журнала Продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску Инкремент функциональности. Все остальные требования переоцениваются и возвращаются в Журнал Продукта. Работа, проделанная над ними, обесценивается быстро, и поэтому требует пересмотра.
Отмена Спринта требует дополнительных ресурсов, так как все члены Команды должны перегруппироваться при Планировании Спринта и приступить к новому Спринту. Отмена Спринта является для Команды неприятным процессом, однако на деле это происходит довольно редко.

Планирование Спринта

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

  • Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
  • Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

Цель Спринта придает работе Команды Разработчиков некоторую гибкость в отношении разработки функциональности во время Спринта.
Пока Команда работает, эта цель служит для нее ориентиром. Для ее достижения Команда Разработчиков реализовывает функциональность и технологию. Если же работа оказывается сложнее, чем ожидалось, тогда Команда Разработчиков договаривается с Владельцем Продукта об изменении объема Журнала Спринта в текущем Спринте.
Цель Спринта может быть важным этапом на пути к более высокой цели в разработке конечного продукта.

Ежедневные Скрамы

Ежедневные Скрамы – это 15-минутные совещания для Команды Разработчиков с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Это делается для того, чтобы проверить, что нового было сделано со времени проведения прошлого Ежедневного Скрама и спланировать работу, которую можно успеть сделать за следующие 24 часа.
Эти совещания происходят в обусловленном месте в одно и то же время во избежание путаницы. Во время таких совещаний каждый участник Команды Разработчиков рассказывает коллегам о следующем:

  • Что было сделано со времени прошлой встречи?
  • Что планируется сделать до следующей встречи?
  • Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.
Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

Ежедневные Скрамы улучшают процесс общения внутри Команды, сводя к минимуму другие совещания, помогают определять и устранять препятствия на пути к успешной работе, способствуют быстрому принятию решений, а также повышают знания по проекту Команды Разработчиков. Эти совещания являются ключевыми для проверки и адаптации.

Обзор Спринта

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

Обзор Спринта включает в себя следующие элементы:

  • Владелец Продукта определяет, что является “готовым”, а что нет;
  • Команда Разработчиков вспоминает, что прошло гладко во время Спринта и с чем возникли трудности, а также то, как она с ними справилась;
  • Команда Разработчиков проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;
  • Владелец Продукта обсуждает состояние Журнала Продукта. Он делает предположения касательно возможной даты окончания проекта, принимая во внимание скорость продвижения работы над ним;
  • Вся Команда принимается за обсуждение того, что делать в дальнейшем, для того чтобы данный Обзор Спринта предоставлял важную входную информацию для последующей встречи по планирования Спринта.

Результатом Обзора Спринта является пересмотренный и исправленный Журнал Продукта, определяющий вероятные элементы Журнала Продукта для следующего Спринта. Журнал Продукта может также быть пересмотрен для того, чтобы соответствовать новым обстоятельствам.

Ретроспектива Спринта

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

Целью Ретроспективы Спринта является:

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

Скрам Мастер поощряет Скрам Команду пересмотреть свои процессы разработки в рамках процессов и практик Скрама, чтобы сделать её более эффективной в следующем Спринте. Во время каждой Ретроспективы Спринта Скрам Команда ищет пути улучшения качества разрабатываемого продукта, при необходимости уточняя определение “Готовности”.
До окончания Ретроспективы Скрам Команда должна определить практичные и действенные факторы улучшения процесса работы, которые она реализует в следующем Спринте. Внедрение этих изменений в следующем Спринте как раз и является адаптацией к проверке самой Скрам Команды. Хотя изменения могут быть внесены в любое время, Ретроспектива Спринта является специализированным совещанием, посвященным исключительно проверке и адаптации.

Артефакты Скрама

Артефакты Скрама предоставляются в качестве работы или ценности того, насколько они полезны в обеспечении прозрачности и возможностей для инспекции и адаптации. Определенные Скрамом Артефакты специально спроектированы таким образом, чтобы обеспечить максимальную ясность ключевой информации, необходимой для того, чтобы Скрам Команда достигла успеха в поставке “готового” Инкремента.

Журнал Продукта

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

Элементы Журнала Продукта с высоким уровнем приоритетности должны быть более понятными и содержать больше деталей, чем менее приоритетные. Более точно можно рассчитать время работы над теми требованиями, которые являются более понятными и содержат больше дополнительной информации. Чем ниже приоритетность, тем меньше деталей. Те требования Журнала Продукта, над которыми Команда Разработчиков будет работать во время текущего Спринта, являются детализированными и разбитыми на части таким образом, что любое из этих требований может быть выполнено и “готово” в рамках одного Спринта. Требования Журнала Продукта, которые можно выполнить и “завершить” в течение одного Спринта считаются “готовыми” и “выполняемыми” для того, чтобы их внесли в план во время следующего Планирования Спринта.
Как только продукт начинает использоваться, его значение возрастает и вызывает ответную реакцию рынка, его Журнал становится более полным и всеобъемлющим. Требования к продукту постоянно изменяются, и поэтому Журнал Продукта – это живой артефакт. Изменения в сфере требований, рыночных условий, технологий и ресурсов приводят также и к изменению Журнала Продукта.

Довольно часто случается так, что над одним продуктом работают несколько Команд. Но всё равно используется только один Журнал Продукта, чтобы определить работу на ближайший период. При этом к элементам Журнала Продукта вводится дополнительный атрибут, позволяющий сгруппировать запросы по Скрам Командам.
Поддержание Журнала Продукта – это деятельность по добавлению деталей, оценок предполагаемых затрат времени, и упорядочивания элементов. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработчиков детализируют требования Журнала Продукта. Во время обработки требования проверяются и пересматриваются. Однако Владелец Продукта в любое время может изменить статус этих требований.

Поддержание Журнала Продукта – это часть деятельности во время Спринта, исполняемой Владельцем Продукта и Командой Разработчиков. Часто Команды Разработчиков владеют знаниями в нужной области и сами могут осуществить обработку требований. Как и когда сделать обработку требований решает только Скрам Команда. Обработка требований обычно занимает не более 10% времени Скрам Команды.
Команда Разработчиков несет всю ответственность за оценку объемов работы. Владелец Продукта может помочь Команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от Команды.

Отслеживание прогресса на пути к Цели

В любое время можно подытожить количество работы, которую осталось проделать для достижения Цели. Владелец Продукта отслеживает оставшееся количество работы, как минимум, для каждого Обзора Спринта. Владелец Продукта сравнивает текущее количество работы с тем, которое оставалось во время предыдущего Обзора Спринта, чтобы оценить прогресс в работе и то, успевает ли Команда достичь Цели в рамках запланированного времени. Эта информация является доступной и открытой для всех заинтересованных лиц.
Скрам не принимает во внимание время, потраченное на работу над требованиями Журнала Продукта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Различные графики типа “сколько осталось ”(burndown) и “сколько сделано ”(burnup), отображающие реальное продвижение, отклонение, и ожидаемое движение, а также другие наглядные практики используются для предсказания прогресса. Эффективность этих практик проверена. Однако их использование не заменяет важности использования принципов эмпиризма. В сложной среде очень трудно предсказать, как будут развиваться события. Единственное на что можно положиться при принятии решений о будущей работе, это опыт прошлого.

Журнал Спринта

Журнал Спринта – это набор элементов из Журнала Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Журнал Спринта – это прогноз Команды Разработчиков о функциональности, которая будет частью следующего Инкремента, а также работы, которую необходимо для этого выполнить.

Журнал Спринта определяет объем работы, которую Команда Разработчиков должна выполнить, чтобы превратить Журнал Продукта в “готовый” Инкремент. Журнал Спринта визуализирует ту работу, которую Команда Разработчиков считает необходимой для достижения Цели Спринта.
Журнал Спринта это достаточно детализированный план, чтобы прогресс в его воплощении можно было увидеть на каждом Ежедневном Скраме. Команда Разработчиков вносит изменения в Журнал Спринта на протяжении всего Спринта, и, соответственно, Журнал Спринта постоянно изменяется. Такие изменения происходят потому, что в процессе работы Команда Разработчиков узнает все новые и новые детали о работе, которую нужно выполнить для достижения Цели Спринта.

Если возникает необходимость в дополнительном объеме работы, Команда Разработчиков добавляет ее в Журнал Спринта. Когда же работы выполнены, оценки оставшегося объема работы обновляются. Если некоторые пункты плана считаются уже неактуальными, то их попросту удаляют. Только Команда Разработчиков может изменять свой Журнал Спринта во время Спринта. Журнал Спринта является наиболее наглядным документом, показывающим реальную картину работы, которую Команда Разработчиков планирует завершить до окончания Спринта, и он принадлежит исключительно Команде Разработчиков.

Отслеживание прогресса Спринта

В любое время во время Спринта можно подытожить количество работы, оставшейся в Журнале Спринта. Команда Разработчиков отслеживает оставшееся количество работы, как минимум, во время каждого Ежедневного Скрама. Команда Разработчиков ежедневно отслеживает количество оставшейся работы и вероятность достижения Цели Спринта. Благодаря отслеживанию количества оставшейся работы во время Спринта Команда Разработчиков может управлять прогрессом.
Скрам не принимает во внимание время, потраченное на работу над элементами Журнала Спринта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Инкремент

Инкремент – это сумма всех выполненных требований Журнала Продукта реализованных во время текущего Спринта и всех предыдущих Спринтов. По окончанию Спринта новый Инкремент должен быть «Готовым», то есть он должен быть пригодным к эксплуатации и отвечать определению Скрам Команды понятия “Готовности”. Несмотря на решение Владельца Продукта выпускать ли эту версию Инкремента, он должен быть готовым к использованию.

Scrum доска/Agile Board

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

скрам доска (scrum board)

Пример доски из жизни:

agile доска

Определение «Готовности»

Когда элемент Журнала Продукта или же Инкремент назван “готовым”, все должны понимать, что означает “Готово”. Хотя это определение разные Скрам Команды интерпретируют по-разному, чтобы гарантировать прозрачность, члены Команды должны иметь общее совместное понимание, что означает, когда работа сделана. Именно такое единое определение понятия “Готовности” используется Скрам Командой для оценки окончания работ над Инкрементом Продукта.
Одно и то же определение помогает Команде Разработчиков в понимании того, сколько требований выбрать из Журнала Продукта во время Планирования Спринта. Целью каждого Спринта является разработка Инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению “Готовности” Скрам Команды.
По окончанию каждого Спринта Команда Разработчиков представляет Инкремент функциональности продукта. Такой Инкремент является пригодным к эксплуатации, и поэтому Владелец продукта может решить сразу же его выпустить. Каждый последующий Инкремент должен дополнять все предыдущие Инкременты, а также быть тщательно протестирован для обеспечения стабильной работы всех Инкрементов продукта.
По мере увеличения профессионализма Скрам Команды, определение понятия “Готовности” может расширяться более строгими критериями для достижения лучшего качества продукта.

Заключение

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


??????????????????????

Cтандартизация в области информационных технологий

Cтандартизация в области информационных технологий

В области ИТ наиболее значимые с точки зрения практики стандарты публикуются следующими организациями:

  • Институт инженеров по электротехнике и радиоэлектронике (IEEE, www.ieee.org) в течение многих лет остается лидирующей научно-технической организацией, в том числе, в создании стандартов документации программного обеспечения. Большинство стандартов разработаны различными комитетами, состоящими из опытных и ответственных инженеров-профессионалов. Некоторые из стандартов IEEE стали также стандартами ANSI (American National Standards Institute). Преимущественно стандарты IEEE легли в основу при составлении МУ по КП. Schmidt M. Implementing the IEEE Software Engineering Standards.
  • Международная организация по стандартизации (ISO) имеет огромное влияние во всем мире, особенно среди организаций производителей, имеющих дело с Евросоюзом (ЕС). В настоящее время фактически все современные стандарты в области ИТ, переведенные и принятые в РФ – это стандарты, подготовленные ISO совместно с международной электротехнической комиссией – МЭК (IEC). Вы знаете, что особое внимание уделяется вопросам обеспечения качества продукции на международном уровне, поэтому, согласно постановления правительства РФ №113 от 02.02.1998 соблюдение требований ISO 9000 (серия стандартов, регламентирующих управление качеством (менеджмент качества) на предприятиях) – обязательное условие для получения госзаказа.
  • Институт технологий разработки программного обеспечения (Software Engineering Institute – SEI, sei.cmu.edu – более 1000 статей) был учрежден Министерством обороны США в университете Карнеги-Меллон для поднятия уровня технологии программного обеспечения у подрядчиков Министерства обороны. Работа SEI также была принята многими коммерческими компаниями, которые считают улучшение процесса разработки программного обеспечения своей стратегической корпоративной задачей. Мы обратимся к одному из стандартов, разработанному SEI, который называется Моделью зрелости возможностей (СММ).
  • Консорциум по технологии манипулирования объектами (Object Management Group, www.omg.org) является некоммерческой организацией, в которую в качестве членов входят около 700 компаний. OMG устанавливает стандарты для распределенных объектно-ориентированных вычислений. Нужно заметить, что OMG использует унифицированный язык моделирования UML в качестве своего стандарта для описания проектов. UML мы будем изучать детально, т.к. использование этого языка совместно с унифицированным процессом фирмы Rational является основой при проработке ядра курсового проекта.

Понятие жизненного цикла системы

Необходимость стандартизации разработки программного обеспечения наиболее удачно описана во введении стандарта ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств»: «Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые. Имеется множество разнообразных стандартов, процедур, методов, инструментальных средств и типов операционной среды для разработки и управления программным обеспечением. Это разнообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении программных продуктов и сервисных программ. Стратегия разработки программного обеспечения требует перехода от этого множества к общему порядку, который позволит специалистам, практикующимся в программном обеспечении, «говорить на одном языке» при разработке и управлении программным обеспечением. Этот международный стандарт обеспечивает такой общий порядок».

Стандарт ГОСТ Р ИСО/МЭК 12207-99 определяет базовое понятие программной системы – «жизненный цикл» (ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207»).

ГОСТ Р ИСО/МЭК 12207-99 вводит понятие модели жизненного цикла как структуры, состоящей из процессов, и охватывающей жизнь системы от установления требований к ней до прекращения ее использования. Предлагается это определение подкорректировать и разделить на два определения:

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

Процессы ЖЦ разделены на три группы: основные, вспомогательные и организационные.

Группа основных процессов включает в себя: приобретение, поставку, разработку, эксплуатацию и сопровождение. Основные процессы жизненного цикла реализуются под управлением основных сторон, вовлеченных в жизненный цикл программных средств. Под основной стороной понимают одну из тех организаций, которые инициируют или выполняют разработку, эксплуатацию или сопровождение программных продуктов. Основными сторонами являются заказчик, поставщик, разработчик, оператор и персонал сопровождения программных продуктов.

Рисунок – Основные процессы ЖЦ ИС

Основные процессы ЖЦ ИС

Группа вспомогательных процессов включает в себя процессы, обеспечивающие выполнение основных процессов:

  • документирование;
  • управление конфигурацией;
  • обеспечение качества;
  • верификация;
  • аттестация;
  • оценка;
  • аудит;
  • решение проблем.

Группа организационных процессов включает в себя процессы:

  • управление проектами;
  • создание инфраструктуры проекта;
  • определение, оценка и улучшение самого ЖЦ;
  • обучение.

В тексте ГОСТ 12207-99 работы, входящие в состав основных, вспомогательных и организационных процессов охарактеризованы очень общо, фактически намечены только их направления, поэтому для того, что бы приступить к проектированию понадобятся стандарты и дополнительная литература, раскрывающая содержание каждого отдельного процесса или, что еще лучше, отдельной работы.
Из группы основных процессов наибольший интерес представляет процесс разработки.
Следует отметить, что ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» процесс создания автоматизированной системы разделяет на следующие стадии:

  • формирование требований к АС,
  • разработка концепции АС,
  • техническое задание,
  • эскизный проект,
  • технический проект,
  • рабочая документация,
  • ввод в действие,
  • сопровождение.

Стадии разделены на этапы, содержание которых перекликается с содержанием рядя задач, описанных в ГОСТ 12207-99.

Процесс разработки

Процесс разработки (development process) предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д.

Рисунок – Структура процесса разработки

Структура процесса разработки

Подготовительная работа

начинается с выбора модели ЖЦ ПС, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.

Анализ требований

Анализ требований к ПС предполагает определение следующих характеристик для каждого компонента ПС:

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

Проектирование архитектуры

системы на высоком уровне заключается в определении компонентов ее оборудования, ПС и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам.
Проектирование архитектуры ПС включает следующие задачи (для каждого компонента ПС):

  • трансформацию требований к ПС в архитектуру, определяющую на высоком уровне структуру ПС и состав его компонентов;
  • разработку и документирование программных интерфейсов ПС и баз данных;
  • разработку предварительной версии пользовательской документации;
  • разработку и документирование предварительных требований к тестам и плана интеграции ПС.

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

ПС включает следующие задачи:

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

Кодирование и тестирование

ПС охватывают следующие задачи:

  • разработку (кодирование) и документирование каждого компонента ПС и базы данных, а также совокупности тестовых процедур и данных для их тестирования;
  • тестирование каждого компонента ПС и базы данных на соответствие предъявляемым к ним требованиям. Результаты тестирования компонентов должны быть документированы;
  • обновление (при необходимости) пользовательской документации;
  • обновление плана интеграции ПС.

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

ГОСТ Р ИСО/МЭК 12119-2000 «Информационная технология. Пакеты программ. Требования к качеству и тестирование» содержит указания, которые определяют порядок тестирования продукта на соответствие его требованиям к качеству. Тестирование является трудоемким процессом. Согласно оценкам некоторых специалистов процентное
распределение времени между процессами проектирование – разработка – тестирование находится в отношении 40-20-40. В этой связи широкое распространение получают системы автоматизации тестирования. В стандарте IEEE 1209-1992 «Recommended Practice for the Evaluation and Selection of CASE Tools» сформулированы общие требования к функциям средств автоматизации тестирования.

Интеграция системы

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

Установка системы

осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПС и баз данных.

Приемка системы

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

Модели жизненного цикла программного средства

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

К настоящему времени наибольшее распространение получили две основные модели жизненного цикла:

  • каскадная (водопадная) модель;
  • спиральная модель.

Каскадная модель

Каскадная модель демонстрирует классический подход к разработке различных систем в различных прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Именно каскадная модель положена в основу ГОСТ серии 34.xxx и стандарта Министерства обороны США DOD-STD-2167A. Процессы ГОСТ 12207-99 в ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» названы стадиями и немного различаются по составу.
Каскадная модель предусматривает последовательную организацию процессов. Причем переход к следующему процессу происходит только после того, как полностью завершены все работы на предыдущем. Каждый процесс завершается выпуском полного комплекта документации, достаточной для того, чтобы работа могла быть продолжена другой командой разработчиков.

Главный недостаток каскадной модели заключается в том, что ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад. По сведениям консалтинговой компании The Standish Group в 1998 г. в США более 28 % проектов корпоративных информационных систем (IT-проектов) заканчивались неудачей; почти 46% IT-проектов завершались с перерасходом бюджета (в среднем на 189%); и только 26% проектов укладывается и в выделенный срок, и бюджет.

Кроме того, к недостаткам каскадной модели следует отнести:

  • сложность распараллеливания работ;
  • сложность управления проектом;
  • высокий уровень риска и ненадежность инвестиций (возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика во время разработки. Причем возврат проекта на доработку вследствие этих причин не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится» и система никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться).

Спиральная модель

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

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

Быстрая разработка приложений

В 90-е годы XX века на основе спиральной модели была основана практическая технология, получившая название «быстрая разработка приложения» — RAD (Rapid Application Development). При этом ЖЦ состоял из четырех стадий:

  • анализ и планирование требований,
  • проектирование,
  • реализация,
  • внедрение.

Основные принципы RAD:

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

В начале 2001 г. ряд ведущих специалистов в области программной инженерии (Мартин Фаулер, Кент Бек и др.) сформировали группу под названием Agile Alliance для поддержания и развития нового подхода к проектированию – «быстрая разработка ПО» (Agile Software Development). Одной из реализаций этого подхода является «Экстремальное программирование» (Extreme Programming — XP).

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

  1. В команде работает от трех до десяти программистов. Один или несколько заказчиков должны иметь возможность непрерывного обеспечения текущей экспертизы.
  2. Программы разрабатываются трехнедельными итерациями. На каждой итерации производится работающий, протестированный код, который может сразу использоваться заказчиками. Собранная система переправляется к конечным пользователям в конце каждого периода выпуска версий, который может занимать от двух до пяти итераций.
  3. Единицей собираемых требований к ПО является «пользовательская история» (user story), записанная на индексной карточке, и, описывающая с точки зрения пользователя функциональность, которая может быть разработана за одну итерацию. Заказчики и программисты планируют работы на следующей итерации таким образом:
    • программисты оценивают время для завершения работы с каждой карточкой;
    • заказчики расставляют приоритеты, изменяют и пересматривают их при необходимости. Разработка истории начинается с ее обсуждения программистами и экспертом-заказчиком.
  4. Программисты работают парами и следуют строгим стандартам кодирования, установленным ими в начале проекта. Они создают модульные тесты для всего, что они пишут, и добиваются, чтобы эти тесты выполнялись каждый раз при сдаче кода на обязательный контроль версий и в систему управления конфигурацией.
  5. В то время как программисты работают, заказчики посещают программистов, чтобы прояснять идеи, пишут приемочные тесты системы для прогона во время итерации и в ее конце выбирают истории для реализации в следующей итерации.
  6. Каждый день команда проводит оперативные совещания, на которых программисты рассказывают, над чем они работают, что продвигается хорошо и в чем требуется помощь. В конце каждой итерации проводится другое совещание, на котором они оценивают, что было сделано хорошо, и над чем нужно работать в следующий раз. Этот перечень вывешивается, чтобы все могли его видеть, работая во время следующей итерации.
  7. Один человек в команде назначается «наставником». Вместе с участниками команды он оценивает использование ими основных приемов: парного программирования и тестирования, ротации пар, поддержания простоты проектных решений, коммуникации и т.д. с целью постоянного совершенствования процесса разработки.

Подход быстрой разработки ПО не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра — критичность и масштаб.
Критичность определяется последствиями, вызываемыми дефектами в ПО, и может иметь один из четырех уровней:

  • С – дефекты вызывают потерю удобства;
  • D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
  • Е – дефекты вызывают потерю невозместимых средств;
  • L – дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

  • от 1 до 6 человек – малый масштаб;
  • от 6 до 20 человек – средний масштаб;
  • свыше 20 человек – большой масштаб.

По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (С или D). Это означает, что технологии RAD и XP наиболее хорошо подходят для относительно небольших проектов, разрабатываемых для конкретного заказчика, и не применимы для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, а также систем, от которых зависит безопасность людей.

Унифицированный процесс разработки ПО

В настоящее время продолжаются работы по созданию некоторого универсального процесса разработки ИС. В 1999г. сотрудниками компании Rational Айваром Джекобсоном, Гради Бучем и Джеймсом Рамбо была издана книга Unified Software Development Process (Унифицированный процесс разработки ПО), которая была переведена на русский язык и издана издательством «Питер» в 2002. Унифицированный процесс представляет собой попытку объединения водопадной и итеративной моделей ЖЦ.

При этом, ЖЦ разделен на 4 фазы:

  1. Начало (inception): осуществляется первичная оценка проекта.
    • создается упрощенная модель вариантов использования, содержащая наиболее критичные с точки зрения реализации прецеденты;
    • создается пробный вариант архитектуры, содержащей наиболее важные подсистемы;
    • проводится идентификация и определение приоритетов рисков;
    • планируется фаза проектирования;
    • грубо оценивается весь проект в целом;
  2. уточнение (elaboration): детально описываются большинство вариантов использования и разрабатывается архитектура системы. В конце фазы проектирования менеджер проекта выполняет подсчет ресурсов, необходимых для завершения проекта. Необходимо ответить на вопрос: достаточно ли проработаны варианты использования, архитектура и план, чтобы можно было бы давать контрактные обязательства на выполнение работы и переходить к подготовке и подписанию «Технического задания»?;
  3. построение (construction) – создание продукта. В конце этой фазы продукт включает в себя все варианты использования, которые разработчики и заказчик решили включить в текущий выпуск;
  4. внедрение (transition) – выпуск продукта. Проводится тестирование бета-версии продукта отделом тестирования компании и одновременно организуется пробная эксплуатация системы пользователями. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения.

Каждая фаза USDP может включать в свой состав одну или несколько итераций в зависимости от размера проекта. На протяжении каждой итерации может выполняться 5 основных и некоторое количество дополнительных рабочих потоков.
К основным рабочим потокам в USDP относятся:

  • определение требований (ОТ);
  • анализ (А);
  • проектирование (П);
  • реализация (Р);
  • тестирование (Т).

К дополнительным рабочим потокам могут относиться:

  • работы по обеспечению качества (К),
  • документирование (Д),
  • управление проектом (У),
  • управление конфигурацией (УК),
  • создание и управление инфраструктурой (И)
  • и другие.

Рисунок — Модель ЖЦ согласно унифицированного процесса разработки ПО
Модель ЖЦ согласно унифицированного процесса разработки ПО

Выбор модели ЖЦ во многом зависит от типа и масштаба разрабатываемой системы. Для разработки большинства АСОИУ со свободным временем применима итерационная модель ЖЦ, в то время как для систем реального времени больше подходит водопадная модель. На лекциях при проработке вопросов проектирования ИС особое внимание мы уделим использованию Унифицированного языка моделирования (UML), а поскольку его создателями являются Гради Буч и Джеймс Рамбо, то мы будем обращаться и к идеологии Унифицированный процесс разработки.

Рисунок – Нормативные документы, сопровождающие процесс разработки
Нормативные документы, сопровождающие процесс разработки

Вспомогательные процессы жизненного цикла

Процесс обеспечения качества

Процесс обеспечения качества (quality assurance process) обеспечивает соответствующие гарантии того, что ПС и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПС понимается совокупность свойств, которые характеризуют способность ПС удовлетворять заданным требованиям.

Рисунок – Структура вспомогательных процессов ЖЦ
Структура вспомогательных процессов ЖЦ

В контексте ГОСТ Р ИСО/МЭК 9126-93. «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается».

Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС:

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

ГОСТ 28195-89 «Оценка качества программных средств. Общие положения» на верхнем, первом, уровне выделяет 6 показателей – факторов качества: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость. Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла ПС.

В стандарте ГОСТ 28806-90 «Качество программных средств. Термины и определения» формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в ГОСТ 28195-89.
Вопрос обеспечения качества ПС требует особого внимания, поскольку согласно постановления правительства РФ №113 от 02.02.1998 соблюдение требований международного стандарта обеспечения и управления качеством ISO 9000 – обязательное условие для получения госзаказа.
На современном этапе недостаточно иметь только методы оценки качества произведенного и используемого программного средства (выходной контроль), необходимо иметь возможность планировать качество, измерять его на всех этапах жизненного цикла программного средства и корректировать процесс производства программного обеспечения для улучшения качества.

Стандарты серии ISO 9000 являются слишком общими. Каждая компания, производящая программное обеспечение и желающая внедрить у себя действенную систему управления качеством на основе стандартов ISO 9000-й серии, должна учесть специфику своей отрасли и разработать систему показателей качества, которая бы отражала реальное влияние факторов качества на программный продукт. С этой целью многие организации определили процесс раздельной систематической и полной проверки – контроль качества (Quality Assurance), который начинается вместе с запуском проекта, предусматривает инспектирование и тестирование и проводится в идеале некоторой независимой организацией. В действительности, чаще всего, контроль качества проводится группой коллег автора работы.
Цель инспектирования состоит в проверке частей проекта на наличие дефектов:

  • документации,
  • требований,
  • результатов анализа,
  • проектирования,
  • листингов и т.д.

Актуальность инспектирования показывает сравнение стоимости и обнаружения и исправления дефекта во время инспектирования и во время интеграции по данным Fagin, M., «Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal. Некоторые авторы считают эти данные весьма заниженными.

Дефект, найденный в процессе инспектирования Дефект, найденный в процессе интеграции
Количество часов на отыскание 0,7 – 2 0,2 – 10
Количество часов на исправление 0,3 – 1,2 > 9
Всего 1,0 – 3,2 9,2 – 19 и больше

К вопросам отыскания дефектов стали относится намного серьезнее после того как американский спутник стоимостью несколько миллиардов долларов, посланный на Венеру, потерял управление из-за опечатки в подпрограмме коррекции траектории – вместо запятой была поставлена точка с запятой.
Оценка и улучшение качества выполняется посредством использования метрик – количественных характеристик некоторых показателей процесса.

Для проведения инспектирования требуется выполнение следующих шагов:

  1. Процесс инспектирования начинается с планирования. Разрабатывается классификация дефектов по описанию, степени серьезности и типу. Выполняется выбор метрик, по которым будет проводиться инспектирование, выбор инструментов для сбора и анализа полученных данных, а также распределение ролей между проверяющими:
    • Ведущий ответственен за правильное проведение инспектирования.
    • Корректор отвечает за деятельность команды и направляет ее в нужное русло. Корректор принимает участие в инспектировании.
    • Регистратор отвечает за учет описания и классификацию дефектов, как это принято в команде. Регистратор также участвует в инспектировании.
    • Специализированный инспектирующий – специалист в некоторой узкой области, к которой принадлежит инспектируемый фрагмент.
  2. При необходимости может быть организован обзорный семинар для лучшего понимания объекта инспектирования.
  3. Проведение инспектирования. Инспектирующие проверяют работу в полном объеме на своих рабочих местах (например, проверяют, соответствует ли инспектируемый программный код детальному проекту). Инспектирующие обычно заносят все дефекты в базу данных (например, доступную через сеть) вместе с описаниями и классификацией. Инспектируемые части системы должны быть логически завершенными.
  4. Проводится инспекционное собрание, в ходе которого участники представляют свои результаты.
  5. Автор исправляет дефекты (фаза доработки).
  6. На окончательном собрании по завершению работы корректор и автор убеждаются в том, что все дефекты исправлены. Однако это не предполагает детальной ревизии всей работы корректором. Все исправления остаются на совести автора, ответственного за свою работу.
  7. Как и после других процессов, группа встречается для обсуждения самого процесса инспектирования и решает, как он может быть улучшен.

В компании ведется учет времени, потраченного на инспектирование и объема проверенной работы с целью их дальнейшего использования при оценке инспектирования в будущем. В условиях жесткого временного ограничения используется т.н. система «опеки», при которой каждый член команды опекается своим коллегой.
Для учета всех факторов контроля качества удобно пользоваться списками контрольных вопросов. Такие списки содержат пункты, которые необходимо последовательно проверить.
Например, план контроля качества программного обеспечения (Software Quality Assurance Plan – SQAP) в соответствии со стандартом IEEE 739-1989 определяет:

  • кто будет нести ответственность за качество – физическое лицо, менеджер, группа, организация и т.п.;
  • какая документация требуется;
  • какие методы будут использоваться для гарантии качества – инспектирование, тестирование и т.д.;
  • какие мероприятия должны быть проведены в ходе управления процессом – собрания, аудиты, обзоры и т. п.

Содержание стандарта и пример его отработки приведен в книге Э. Брауде. Вопросы использования метрик рассматриваются в разделе «Организационные процессы. Процесс усовершенствования».

Надежность и безопасность

Одной из наиболее значимых характеристик, входящих в понятие качество, является свойство надежности.
По определению, установленному в ГОСТ 13377-75 «Надежность в технике. Термины и определения», надежность – свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования. Таким образом, надежность является внутренним свойством системы, заложенным при ее создании и проявляющимся во времени при функционировании и эксплуатации.
Надежность функционирования ПС наиболее широко характеризуется устойчивостью, или способностью к безотказному функционированию, и восстанавливаемостью работоспособного состояния после произошедших сбоев или отказов.
Контроль надежности и безопасности создаваемых и модифицируемых программ должен сопровождать весь жизненный цикл ПС посредством специально организованной эффективной технологической системы обеспечения их качества. Проверка и подтверждение качества сложных и критических ПС должна обеспечиваться сертификацией аттестованными проблемно-ориентированными сертифицированными лабораториями.

Стандарты в области информационной безопасность делят на две группы:

  • оценочные стандарты, предназначенные для оценки и классификации ИС и средств защиты по требованиям безопасности – стандарт Министерства обороны США «Критерии оценки доверенных компьютерных систем», «Гармонизированные критерии Европейских стран», международный стандарт «Критерии оценки безопасности информационных технологий», Руководящие документы Гостехкомиссии России;
  • спецификации, регламентирующие различные аспекты реализации и использования средств и методов защиты, публикуемые «Тематической группой по технологии Internet» (Internet Engineering Task Force, IETF) и ее подразделений – рабочей группой по безопасности.

К наиболее значимым оценочным стандартам можно отнести:

  • Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. – Москва, 1997 – классифицирует межсетевые экраны в соответствие с уровнем фильтрации потока данных эталонной семиуровневой модели.
  • ИСО/МЭК 15408:1999 «Критерии оценки безопасности информационных технологий».

Ко второй группе можно отнести следующие документы:

  • Х.800 «Архитектура безопасности для взаимодействия открытых систем». Выделены основные сетевые сервисы безопасности: аутентификация, управление доступом, обеспечение конфиденциальности и/или целостности данных. Для реализации сервисов предусмотрены следующие сетевые механизмы безопасности и их комбинации: шифрование, электронная цифровая подпись, управление доступом, контроль целостности данных, аутентификация, дополнение трафика, управление маршрутизацией, нотаризация.
  • Спецификация Internet-сообщества RFC 1510 «Сетевой сервис аутентификации Kerberos (V5)» рассматривает проблему аутентификации в разнородной распределенной среде с поддержкой концепции единого входа в сеть;
  • Х.500 «Служба директорий: обзор концепций, моделей и сервисов», Х.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибутов».

Процессы верификации, аттестации и аудита

Верификация, аттестация и аудит являются составной частью плана контроля качества SQAP IEEE 739-1989.
Верификация отвечает на вопрос: «Делаем ли мы на данном этапе то, что запланировано?». Аттестация и аудит отвечает на вопрос: «Отвечает ли строящийся объект нуждам заказчика?».
Стандарт IEEE 1012-1986 Software Verification and Validation Plan (SVVP) объединяет процессы аттестации и аудита под названием валидация и определяет порядок их проведения.

В процессе верификации проверяются следующие условия:

  • непротиворечивость требований к системе и степень учета потребностей пользователей;
  • возможности поставщика выполнить заданные требования;
  • соответствие выбранных процессов ЖЦ ПС условиям договора;
  • адекватность стандартов, процедур и среды разработки процессам ЖЦ ПС;
  • соответствие проектных спецификаций ПС заданным требованиям;
  • корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
  • соответствие кода проектным спецификациям и требованиям;
  • тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
  • корректность интеграции компонентов ПС в систему;
  • адекватность, полнота и непротиворечивость документации.

Процесс совместной оценки (joint review process)

Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и сосредоточен, в основном, на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.
Оценка применяется как во время управления проектом, так и при технической реализации проекта и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую.

Процесс разрешения проблем

Процесс разрешения проблем (problem resolution process) предусматривает анализ и решение проблем (включая обнаруженные несоответствия) независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов. Процесс разрешения проблем тесно связан с управлением рисками. Факторы, приводящие проект к срыву, проявляются в виде рисков. Управление рисками состоит из идентификации, планирования устранения, выбора приоритетов, устранение (или уменьшение влияния).

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

    1. Нечеткая и/или неполная формулировка требований;
    2. Недостаточная вовлеченность в проект стейкхолдеров;
    3. Неудовлетворительное планирование — отсутствие грамотного управления проектом;
    4. Частое изменение требований, вызванное изменением области применения, целей проекта и другими причинами;
    5. Несовершенство используемой технологии проектирования;
    6. Нехватка знаний или навыков у исполнителей.

Имеется два способа предупреждения рисков:

  1. внесение изменений в требования проекта, устраняющих причину возникновения риска;
  2. разработка технологий, решающих проблему, связанную с появление риска.

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

Вероятность возникновения риска, 1-10 (1 — маловероятный) Ущерб, 1-10 (1 — наименьший) Стоимость устранения, 1-10 (1 — низкая) Итоговый приоритет
Высокоприоритетный риск 10 10 1 (11-10)*(11-10)*1=1
Низкоприоритетный риск 1 1 10 (11-1)*(11-1)*10=1000

Процесс документирования и управления конфигурациями

«Управление документацией программного проекта требует значительных организационных усилий, т.к. документация – это сложная система, подверженная постоянным изменениям, которые могут вноситься одновременно множеством людей» (Э. Брауде)

Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПС. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц (руководители, технические специалисты и пользователи системы).

ГОСТ Р ИСО/МЭК 9294-93. «Информационная технология. Руководство по управлению документированием программного обеспечения» устанавливает рекомендации по эффективному управлению документированием ПС. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

Управление документацией подразумевает поддержание ее полны и согласованности (некоторые авторы включают сюда управление конфигурацией).

Полнота документации характеризуется количеством стандартов и нормативных документов, которые легли в основу комплекта документации, сопровождающего тот или иной процесс жизненного цикла ПС.
Согласованность документации означает, что набор документов не одержит внутренних противоречий. Это достигается посредством размещения каждой спецификации только в одном месте – такую документацию называют целостной. Целостность документации обеспечивается за счет использования гиперссылок.

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

  • // требование 4.3
  • // автор
  • // версия
  • // аргументы
  • …листинг метода…

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

  • Во-первых, это приобретение новых частей,
  • Во-вторых, получение новых версий существующих частей. Для корректного отслеживание этих изменений используется специально организованная совокупность административных и технических процедур, которые относятся к процессу управления конфигурациями (configuration management process).

Для отслеживания частей проекта необходимо определить их границы и выделить элементы конфигурации (Configuration Items — CIs). Элементами конфигурации могут быть классы, реже функции, значимые наборы данных – глобальные таблицы, документация. Учет состояния конфигурации осуществляется посредством регистрации состояния компонентов ПС, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПС. Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций.
Существуют специальные программные средства для управления конфигурацией (например, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion и др.).

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

  • • возможность определения элементов конфигурации;
  • хранение в БД управления конфигурацией полных хронологий версий каждого объекта, созданного или измененного в процессе разработки системы (к ним относятся исходный программный код, библиотеки, исполняемые программы, модели, документация, тесты, web-страницы и каталоги);
  • поддержка географически удаленных групп разработчиков;
  • отказ в праве на модификацию для предотвращения одновременной работы более чем одного человека над элементом конфигурации;
  • контроль изменений, вносимых во все объекты системы;
  • сборка версий ПО из компонентов проекта.

IEEE разработал стандарт IEEE 828-1990 «План управления конфигурациями программного обеспечения (Software Configuration Management Plan – SCMP)». Заголовок стандарта и пример составление План управления конфигурациями приведен в книге Эрика Брауде.

Рисунок – Нормативные документы вспомогательных процессов ЖЦ
Структура вспомогательных процессов ЖЦ

Организационные процессы жизненного цикла

Организационные процессы ЖЦ включают в свой состав: процесс создания инфраструктуры, процесс усовершенствования, процесс обучения, процесс управления.

Рисунок – Структура организационных процессов ЖЦ
Нормативные документы вспомогательных процессов ЖЦ

Процесс создания инфраструктуры

является процессом установления и обеспечения (сопровождения) инфраструктуры, которая может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения. На 1-ом этапе создания инфраструктуры осуществляется выбор CASE-системы поддержки проектирования, выбор языка программирования, СУБД; организацию службы поддержки – системных администраторов, сетевых, администраторов БД, секретарей и т.д.
При решении задачи выбора с использованием литературных источников необходимо проанализировать возможности наиболее распространенных инструментальных систем для того, что построить классификацию, а затем в рамках определенной классификационной группы определить параметры, по которым будет проводиться выбор.
Собственно процедура выбора включает следующие шаги:

    1. Выявляются базовые показатели выбираемой системы, значимые при проектировании заданной АСОИУ с учетом ее особенностей, ограничений, ресурсов и т.д.
    2. Все показатели сводятся в таблицу (см. табл. 5), в которой на основании экспертных оценок каждому показателю назначается весовой коэффициент Vi (например, от 1 до 10), характеризующий значимость данного показателя по сравнению с остальными. Сумма значений всех весовых коэффициентов должна равняться верхней границе весового коэффициента (например, 10).
    3. С использованием данных, полученных из литературных источников и/или от экспертов, по каждому i-ому показателю для каждой j-ой системы определяется степень полезности Ui,j (от 1 – минимальная, до 10 — максимальная). Например, степень полезности система управления конфигурацией, стоимость которой является сравнительно высокой, может равняться 1, тогда как степень полезности свободно распространяемой системы будет равна 10.
    4. Для каждой j-ой сравниваемой системы вычисляется значение оценочной функции по формуле: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
    5. На основании значения оценочной функции делается вывод о целесообразности использования той или иной системы в данном проекте при учете выбранных критериев и заданных ограничений. Та система, для которой значение оценочной функции окажется больше, является лучшей с точки зрения выбора из числа сравниваемых альтернатив.
i Показатель Вес Vi (1-10) Преимущество системы №1, Ui,1 (от 1 — минимальное до 10 — максимальное) Преимущество системы №2, Ui,2 (от 1 — минимальное до 10 — максимальное) Преимущество системы №n, Ui,n
1 Трудоемкость
установки и
настройки
1 2 6 5
2 Удобство
сетевого
взаимодействия
4 6 4 8
3 Стоимость 4 10 (бесплатная) 1 (очень дорогая) 5
ИТОГ 10 F1=1×2+4×6+4×10+… F2=1×6+4×4+4×1+… F3=1×5+4×8+4×5+…

Процесс обучения

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

Процесс усовершенствования

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

Метрики, которыми приходится пользоваться чаще всего следующие:

  • объем выполненной работы, измеренный в физических единицах (например, число строк кода);
  • время, затраченное на выполнение работы;
  • степень дефектности (например, число дефектов на 1000 строк кода, число дефектов на страницу документации и т. д.).

Предварительные или желаемые значения метрик заранее прогнозируются, а затем сравниваются с полученными результатами.
Поскольку метрики, связанные с дефектностью, играют особую роль, перечислим некоторые из них:

    1. Количество дефектов на тысячу строк программного кода, выявленных в течение 12 недель после сдачи проекта.
    2. Отклонения в расписании на каждой фазе: (Фактическая длительность – Плановая длительность) / Плановая длительность.
    3. Отклонения в стоимости: (Фактическая стоимость – Плановая стоимость) / Плановая стоимость.
    4. Общее время проектирования / Общее время программирования (по некоторым оценкам должно составлять не менее 50 %).
    5. Степени появления и обнаружения дефектов на некоторой стадии является одной из простейших метрик.

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

Стадии, на которых были обнаружены дефекты (в данном проекте / норма) Стадии, содержащие дефекты
Формирование требований Техническое задание Эскизный проект
Формирование требований 2/5
Техническое задание 0,5/1,5 3/1
Эскизный проект 0,1/0,3 1/3 2/2

Анализ стадии «Формирование требований» показывает, что степень обнаружения дефектов меньше нормы на всех стадиях проекта. Обнаружено больше дефектов проектирования непосредственно на той фазе, когда они были произведены и на более поздних фазах было обнаружено меньше дефектов. Как правило, это достигается посредством проведения инспектирования.

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

  1. Выявить и определить метрики, которые будут использоваться командой на каждой фазе, включая:
    • время, затраченное на исследование, реализацию и анализ результатов;
    • размер (например, количество строк кода);
    • количество дефектов, обнаруженных в модуле (например, количество строк кода) и источник обнаружения дефекта;
    • оценка качества по шкале от 1 до 10.
  2. Задокументировать полученную информацию в SQAP.
  3. Собирать статистику на каждой фазе.
  4. Назначить разработчиков, ответственных за сбор данных на каждой фазе, например, «ответственный за качество».
  5. Спланировать обзоры полезных в дальнейшем метрических данных. Необходимо заранее определиться с тем, какими могут быть и какими должны быть значения метрик. Полученные данные станут основой для создания базы данных о проектах компании.

Модель зрелости возможностей организации

Процесс совершенствования технологии создания ПО отражается в стратегических планах организации, ее структуре, используемых технологиях, общей социальной культуре и системе управления.
В начале 1990-х годов американский Институт программной инженерии (Software Engineering Institute – SEI университета Карнеги-Меллона (г. Питтсбурге, шт. Пенсильвания, США)) сформировал модель технологической зрелости организаций СММ (Capability [кэпэбилити] Maturity [мэтшэрити] Model). В настоящее время на западе компания-разработчик испытывает значительные трудности в получении заказа, если она не аттестована по CMM.
СММ представляет собой методический материал, определяющий правила формирования системы управления созданием и сопровождением ПО и методы постепенного и непрерывного повышения культуры производства. Назначение СММ – предоставление организациям-разработчикам необходимых инструкций по выбору стратегии повышения качества процессов путем анализа степени их технологической зрелости и факторов, в наибольшей степени влияющих на качество выпускаемой продукции. На каждом уровне СММ устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов.

Процесс управления

Управление проектом – это достижение баланса между стоимостью, возможностями, качеством и сроками. С процессом управления проектом связано несколько аспектов: управление персоналом, составление плана-графика, оценка стоимости проекта.

Управление персоналом

Известны эмпирические данные по определению оптимального количества членов команды.

Рисунок – Зависимость эффективности команды разработчиков от ее состава

Зависимость эффективности команды разработчиков от ее состава

Такая зависимость приводит к необходимости использования иерархической структур управления

Рисунок – Иерархическая структура управления

Иерархическая структура управленияНесмотря на то, что количество связей каждого сотрудника является удовлетворительным они не участвуют в постановке задачи, что нарушает одно из главных требований системного анализа – в обсуждении проблемы должны принимать участие максимально возможное число стейкхолдеров.
Альтернативная схема организации коллектива сотрудников называется «команда равных». В этом случае все участники команды находятся на одном уровне иерархии и между ними распределяются роли. Причем распределение ролей может меняться по истечении определенного периода времени. Проблема увеличения числа связей в большом проекте в этом случае решается посредством выделения роли ответственного за внешние коммуникации.

Рисунок – Структура управления типа «команда равных»

Рисунок – Структура управления типа «команда равных»

В концепции экстремального программирования, предложенной Кентом Бэком. делается упор на непрерывную взаимосвязь между разработчиками и заказчиком (причем, заказчика делают одним из участников разработки), стремление к радикальному упрощению процесса разработки системы и парное программирование. Причем, при парном программировании разработчики работают только вдвоем за одним компьютером по очереди. Тем самым реализуется форма непрерывного инспектирования.

Подготовка плана-графика

Существует множество стандартов, описывающих создание и поддержание планов управления программным проектом. Рекомендуется использовать стандарт IEEE 1058.1-1987 план управления программным проектом (Software Project Management Plan – SPMP). В SPMP приводят расписание, определяющее, как и когда должны быть выполнены различные этапы проекта. По окончании выполнения каждого последующего этапа проектирования план-график нуждается в дополнении и корректировке. Наиболее распространенной формой представления плана-графика проекта является диаграмма Ганта.

Рисунок – Примерный вид диаграммы Ганта

Примерный вид диаграммы Ганта

Рекомендуется в плане предусматривать буферные периоды, когда не планируется выполнение никаких процессов. План-график в виде диаграммы Ганта, в большинстве случаев, строят с помощью Microsoft Office Project.
Процесс планирования работ по выполнению проекта в частности и управления проектом в целом связан с оценкой стоимости и длительности проекта. Эта информация приводится в разделе 5.4. «Выделение бюджета и ресурсов» SPMP и, кроме того, предварительная оценка стоимости проекта может повлиять на окончательную версию договора между заказчиком и исполнителем, а значит должна быть проведена до подписания ТЗ.

Оценка затрат на создание ПС

Процесс оценки трудоемкости, как правило, начинается одновременно со стартом проекта и продолжается даже на стадии написания программного кода.

Среди наиболее распространенных методов оценки трудоемкости выделяют следующие:

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

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

Процедура оценки трудоемкости разработки ПО состоит из следующих действий:

  1. оценка размера разрабатываемого продукта;
  2. оценка трудоемкости в человеко-месяцах или человеко-часах;
  3. оценка продолжительности проекта в календарных месяцах;
  4. оценка стоимости проекта.

Основными единицами измерения размера ПО являются:

  • количество строк кода (LOC – Lines of Code);
  • функциональные точки (FP – Function Points).

Методология оценивания функционального размера

Методология оценивания функционального размера (FP – Functional Points) заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Затем это число можно использовать для оценки числа строк кода, стоимости и сроков проекта.
Для вычисления функционального размера определяют ранг и сложность для каждой информационной характеристики системы. Международная группа пользователей функционального измерения (IFPUG – International Function Point Users Group, www.ifpug.org) опубликовала критерии, по которым следует выделять информационные характеристики, которые делят на пять групп:

  • Внутренний логический файл (Internal Logical File) – распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.

Внутренний логический файл (Internal Logical File)

  • Внешний интерфейсный файл (External Interface File) – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.

Внешний интерфейсный файл (External Interface File)

  • Внешний ввод (External Input) – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать по каналам связи, от пользователя с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов и могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл (Например, поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки).

Внешний ввод (External Input)

  • Внешний вывод (External Output) – элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле (например, поля данных в отчетах, вычисляемые значения, сообщения об ошибках).

Внешний вывод (External Output)

  • Внешний запрос (External Query) – элементарный процесс, работающий как с вводимыми, так и с выводимыми данными, состоящий из комбинации «запрос-ответ», но не связанный с вычислением производных данных или обновлением ILF. Его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная часть не несет данных, вычисляемых приложением (в этом состоит отличие запроса от вывода). Например: вводимые элементы – поле, используемое для поиска, щелчок мыши; выводимые элементы – отображаемые на экране поля.

Внешний запрос (External Query)


uml-certifications

Методология проектирования программных средств

Методология проектирования программных средств

Если кажется, что работу сделать
легко, это непременно будет трудно.
Если на вид она трудна, значит,
выполнить ее абсолютно невозможно.
Теорема Стакмайера

Технология проектирования АСОИУ – совокупность методологии, а также методов и средств организации процесса проектирования (управление процессом разработки и модернизации проекта).
Методология проектирования представляет собой концепцию / принципы проектирования, реализуемые набором методов проектирования, поддерживаемых средствами проектирования.
Метод (подход) проектирования – алгоритм / последовательность шагов по реализации той или иной стадии создания АСОИУ.
Главный принцип построения различных систем – принцип иерархической декомпозиции включает две группы методологий:

  1. Группа структурно-функциональной методологии, в основу положен принцип функциональной декомпозиции: структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами.
  2. Объектно-ориентированная методология использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

Структурно-функциональная методология

В структурном анализе и проектировании используются различные модели, описывающие:

  1. Функциональную структуру системы;
  2. Последовательность выполняемых действий;
  3. Передачу информации между функциональными процессами;
  4. Отношения между данными.

Наиболее распространенными реализациями этих моделей являются:

  1. Функциональная модель SADT (Structured Analysis and Design Technique);
  2. Модель IDEF3;
  3. DFD (Data Flow Diagrams) — диаграммы потоков данных.
  4. Диаграмма «сущность — связь» (ERD — Entity-Relationship Diagram).

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. и успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого семейства — IDEF0 последняя редакция которого была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 г. постановлением Госстандарта России был введен в действие руководящий документ РД IDEF0 – 2000, содержащий основные сведения о методологии функционального моделирования IDEF0, о ее графическом языке и методике построения и практического применения функциональных моделей организационно-экономических и производственно-технических систем. Кроме того, РД IDEF0 – 2000 устанавливает правила оформления комплекта иерархических диаграмм.

В основе методологии IDEF0 лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарии.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

  • верхняя сторона имеет значение «Управление» (Control);
  • левая сторона имеет значение «Вход» (Input);
  • правая сторона имеет значение «Выход» (Output);
  • нижняя сторона имеет значение «Механизм» (Mechanism).

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними.
Единицы работы — Unit of Work (UOW) (работы), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор).
Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными и имеют следующие типы:

  • временное предшествование,
  • объектный поток,
  • нечеткое отношение.

Перекрестки (Junction) — используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.

Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.

При создании диаграммы потоков данных используются четыре основных понятия:

  • потоки данных,
  • процессы (работы) преобразования входных потоков данных в выходные,
  • внешние сущности,
  • накопители данных (хранилища).

SADT создавалось как средство моделирования систем в целом, а DFD как средство проектирования ИС, поэтому DFD более перспективно для использования, тем более DFD согласовано с ERD, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), которая впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются: (сущности), их свойства (атрибуты) и отношения друг с другом (связи). Кроме того, ERD связываются с такими понятиями как: мощность и тип связи, первичный и внешние ключи, индексы, нормализация диаграммы и т.д.

Объектно-ориентированная методология

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

Объектно-ориентированный подход обладает следующими преимуществам:

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

К недостаткам объектно-ориентированного подхода относятся:

  • высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух-трех проектов и накопления повторно используемых компонентов.
  • Сложно осуществлять управление проектом. Менеджеры измеряют степень продвижения разработки, с помощью четко определенной декомпозиции работ, элементов комплекта поставки и ключевых этапов. При объектной разработке с помощью «детализации» не существует четких границ между этапами, а проектная документация непрерывно развивается. Приемлемое решение в такой ситуации лежит в делении проекта на небольшие модули и управлении ходом разработки за счет частого выпуска выполняемых версий этих модулей (некоторые из этих выпусков могут быть для внутреннего применения, а другие – поставляться заказчику).
  • Возрастающая сложностью решения, что, в свою очередь, сказывается на таких характеристиках ПО, как приспособленность к сопровождению и масштабируемость.

Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:

  • Абстрагирование – это выделение наиболее важных, существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы с точки зрения дальнейшего рассмотрения и анализа, и игнорирование менее важных или незначительных деталей.
  • Инкапсуляция – физическая локализация свойств и поведения в рамках единственной абстракции (рассматриваемой как «черный ящик»), скрывающая их реализацию за общедоступным интерфейсом.
  • Модульность – это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой подсистем (модулей).
  • Иерархия – это ранжированная или упорядоченная система абстракций, расположение их по уровням.

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

Введение в унифицированный язык моделирования (UML)

Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.

Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, ОМТ-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.
Все шло к созданию единого языка, который объединял бы сильные стороны известных методов и обеспечивал наилучшую поддержку моделирования. Таким языком оказался UML.

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов ОМТ и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

  • является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;
  • содержит механизмы расширения и специализации базовых концепций языка.

UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения.

Пользователям языка предоставлены возможности:

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

Синтаксис и семантика основных объектов UML

UML – это набор диаграмм, которые позволяют создавать модели сложных программных систем.
Диаграммы UML разделяются на две группы.
1. Структурные диаграммы:

  • Implementation Diagram (диаграммы реализации):
    • Deployment diagram (диаграммы топологии);
    • Component diagram (диаграммы компонент).
  • Class diagram (диаграммы классов);

2. Диаграммы поведения:

  • Use case diagram (диаграммы вариантов использования);
  • Statechart diagram (диаграммы состояний);
    • Activity diagram (диаграммы активности);
  • Interaction diagram (диаграммы взаимодействия);
    • Sequence diagram (диаграммы последовательности);
    • Collaboration diagram (диаграмма сотрудничества / кооперативная диаграмма);

Диаграмма прецедентов использования (Use Case Diagram)

Вариант использования определяется, прежде всего, своим именем и типом пользователя приложения, называемого действующим лицом.
Вариант использования состоит из типичного взаимодействия между действующим лицом и приложением. Например, команда «открыть файл» будет типичным вариантом использования текстового редактора с пользователем в качестве действующего лица. Один и тот же человек или внешняя система может использовать систему несколькими разными способами, принимая роли разных действующих лиц (актеров – actors). Актеры представляют именно роли, исполняемые людьми или внешними сущностями, а не конкретных людей или сущностей.
Прецедент описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или более актеров.
Для детализации прецедента составляют спецификацию.

Таблица «Примерный вид спецификации прецедента»

Имя прецедента – отглагольное существительное в стиле UpperCamelCase
Идентификатор (1.1 – прецедент.№альтернативного потока)
Краткое описание – цель прецедента
Актеры: главные актеры инициируют прецедент; второстепенные актеры – взаимодействуют с прецедентом после его инициации
Предусловия определяют условия, которые должны быть истинными для того, чтобы прецедент мог быть инициирован
Основной поток – этапы осуществления прецедента.
Этапы принято записывать в виде:
<номер> <кто-либо><действие>
1. Покупатель заполняет в форме свои имя и адресДля представления ответвления используется ключевое слово «Если»
2. Если покупатель выбирает «удалить позицию»
2.1. Система удаляет позицию из корзиныПовторения моделируют с помощью ключевых слов «Для» или «Пока»
3. Если система находит необходимые продукты, тогда
1.1 Для каждого найденного продукта
1.1.1 Система выводит на экран представление продукта
1.1.2 Система выводит на экран цену продукта
Постусловия определяю, какие условия будут истинными после выполнения прецедента
Альтернативные потоки – альтернативные пути в прецеденте, которые перехватывают ошибки, ответвления и прерывания основного потока (наиболее значимые с т.з. функционирования альтернативные потоки документируются отдельно).

Диаграммы вариантов использования позволяют показать специфические взаимоотношения между прецедентами:

  • обобщение,
  • включение и
  • расширение.

Обобщение прецедентов выносит поведение, общее для одного или более прецедентов, в родительский прецедент.

Рисунок «Обобщение прецедентов»
UML Обобщение прецедентов

При построении диаграмм вариантов использования необходимо:

  • Во-первых, избегать последовательного соединения двух вариантов использования, поскольку диаграмма предназначена для отражения существующих вариантов использования, а не порядка их выполнения (для этого используется диаграмма деятельности).
  • Во-вторых, каждый вариант использования должен быть инициирован действующим лицом.

Однако, на диаграммах встречается последовательное соединение прецедентов, но при этом используются специальные типы связей:
Отношение «include» устанавливаемое между прецедентами, позволяет включить поведение одного прецедента в поток другого прецедента. Это означает, что при выполнении прецедента «Просмотреть Индексную Карточку УММ» обязательно должен быть выполнен прецедент «Поиск УММ». Для обозначения отношения включения в UML используется пунктирная стрелка, направленная от исходного варианта использования (включающего) к целевому (включаемому).

Рисунок «Использование отношений «include» и «extend»»
UML Использование отношений include и extend

Таблица «Структура спецификации прецедента, включающей отношение «include»»

Прецедент: РедактироватьИндекснуюКарточку
ID: 4
Краткое описание: Менеджер меняет даные служащего. Администратор изменяет поля УММ, отраженные в индексной карточке
Главные актеры: Администратор
Второстепенные актеры: нет
Предусловия:
1. Администратор входит в систему
Основной поток:
1. include (ПоискУММ)
2. include (ПросмотретьИндекснуюКарточку)
3. Система выводит данные УММ
4. Администратор меняет данные УММ
Постусловия:
1. Данные УММ изменены
Альтернативные потоки: нет

Отношение «extend» — способ введения нового поведения в существующий прецедент. При использовании «extend» базовый прецедент выступает в роли модельного каркаса, к которому можно подключать расширения, например, для обработки исключений. Отношение «extend» в UML обозначается пунктирной стрелкой, направленной от расширяющего варианта использования к базовому. При этом базовый вариант использования должен быть самостоятельным, допускающим применение безо всяких расширений.

Дополнительные возможности «включения», «расширения» и обобщения необходимо использовать в обоснованных случаях, т.к. диаграмма прецедентов должна быть простой и понятной заказчику.
Выполняя анализ вариантов использования проектировщик:

  • идентифицирует классы, участвующие в реализации потоков событий варианта использования;
  • распределяет поведение, реализуемое вариантом использования, между классами (определение обязанностей классов);
  • проводит унификацию классов анализа.

Диаграммы прецедентов определяют зачем (или с какой целью) актеры взаимодействуют с системой. Прецеденты и их описание являются важнейшим артефактом этапа анализа требований.
Для того, что бы ответить не только на вопрос «Зачем происходит взаимодействие с системой? Но и как происходит взаимодействие?» необходимо будет обратиться к диаграммам взаимодействия (sequence и collaboration) и деятельности (activity).

Диаграммы взаимодействия (Interaction Diagram)

Взаимодействие актеров с системой в целом или взаимодействие отдельных модулей (классов) системы между собой происходит посредством обмена сообщениями (или запросами). Для моделирования такого взаимодействия UML включает в свой состав диаграммы взаимодействия: диаграмма последовательности действий (Sequence Diagram) и диаграмма сотрудничества (Collaboration Diagram), которые позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Как правило, диаграммы взаимодействия охватывает поведение объектов в рамках одного конкретного варианта использования.

Sequence Diagram (диаграммы последовательности)

Для построения диаграммы последовательности необходимо:

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

На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии, и не указываются возможные статические ассоциации с другими объектами.
Линия жизни объекта (object lifeline) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней.

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента используется специальный символ в форме латинской буквы «X».
Объекты на диаграмме последовательности могут находиться в двух состояниях, активном — непосредственно выполняя какие-либо действия, и пассивном, ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, применяется фокус управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

Рисунок – Диаграмма последовательностей для варианта использования «Добавление файла УММ для обработки»
Диаграмма последовательностей для варианта использования «Добавление файла УММ для обработки»

Каждое взаимодействие между объектами описывается совокупностью сообщений, которыми объекты обмениваются между собой или операций, которые объекты вызывают для выполнения определенных действий. Сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. Объект, принявший сообщение, должен отреагировать на него какой-либо последовательностью действий, направленных на решение поставленной задачи. Порядок сообщений указывается в вертикальном направлении. Тип сообщения отражается с помощью разнообразных стрелок:

  • Simple (1) — простая посылка сообщения;
  • Synchronous (2) — операция происходит только в том случае, когда клиент посылает сообщение, а сервер может принять сообщение клиента;
  • Самоделегирование (3) — распространенное явление в ООП, например, когда объект вызывает свой собственный (как правило, защищенный) метод;
  • Balking (4) — операция происходит только в том случае, когда сервер готов немедленно принять сообщение, если сервер не готов к приему, клиент не выдает сообщение;
  • Timeout (5) — клиент отказывается от выдачи сообщения, если сервер в течение определенного времени не может его принять;
  • Procedure Call (6) — клиент вызывает процедуру сервера и полностью передает ему управление;
  • Asynchronous (7) — клиент выдает сообщение, и, не ожидая ответа сервера, продолжает выполнение своего программного кода;
  • Return (8) — определяет, что происходит возврат из процедуры;

Частота посылки сообщений может иметь два варианта:

  • Periodic – сообщения поступают от клиента с заданной периодичностью;
  • Aperiodic – сообщения поступают от клиента нерегулярно.

Рисунок – Виды сообщений на диаграмме последовательностей
Виды сообщений на диаграмме последовательностей

Необходимо придерживаться следующего требования, предъявляемого к имени сообщения: для повышения информативности имя должно начинаться с глагола add (добавить), enter (ввести), end (завершить), load (загрузить) и т.д. Первоначально на этапе анализа системы как модели черного ящика на диаграмме последовательности система представляется одним объектом. Операции, которые в этом случае отображаются на диаграмме называются системными. Они составляют открытый интерфейс системы и предназначены для обработки всех входных системный событий, которые система выполняет как черный ящик. В последствии для уточнения описаний системных операций (их предусловий и постусловий) используются диаграммы активностей.

Как и все прочие диаграммы UML, диаграммы последовательностей проходят две стадии детализации:

  • (i) стадия сбора требований и анализа, когда создаются эскизные версии диаграмм, на которых отражаются лишь основные объекты и сообщения, предназначенные прежде всего для согласования с заказчиком понимания, процессов, протекающих в системе при реализации того или иного прецедента заказчиком процессов;
  • (ii) стадия проектирования, на которой все диаграммы снабжают максимальным количеством деталей для упрощения работы программиста и/или документирования итоговых результатов этапа реализации. При этом на диаграмме последовательностей операции снабжаются сигнатурой (имя и параметры), а в описании диаграммы приводится их спецификация, включающая в свой состав указание пред- и постусловий.

Рисунок – Диаграмма последовательностей для варианта использования «Добавить файл УММ для обработки»
Диаграмма последовательностей для варианта использования «Добавить файл УММ для обработки»

Диаграмма сотрудничества (Collaboration Diagram) отличается от диаграммы взаимодействия тем, что она не акцентирует внимание на последовательности передачи сообщений. Она имеет форму графа узлы (объекты) которого могут размещаться в произвольном месте диаграммы.
Так как временная шкала не участвует в демонстрации обмена сообщениями, то эта диаграмма получается компактней и лучше подходит для того, чтобы проанализировать взаимодействие всех объектов между собой.
Таким образом, диаграмма последовательностей точно описывает временной порядок сообщений, но занимает много места, а диаграмма сотрудничества экономит пространство, но ухудшает прослеживание последовательности передачи сообщений (выполнения операций).

Рисунок – Диаграмма сотрудничества
Диаграмма сотрудничества

На диаграмме сотрудничества порядок передачи сообщений иллюстрируется с помощью порядковых номеров. Возможно использование следующих типов связей:

  • Связь Link To Self (связь с самим собой) показывает, что объект имеет обратную связь с самим собой.
  • Link Message / Reverse Link Message (передача сообщения / обратная передача) позволяет отразить связь, которая подразумевает обязательную передачу сообщения в прямом (обратном) направлении.
  • Data Flow / Reverse Data Flow (поток данных) позволяет отразить связь показывающую, что происходит передача данных от одного объекта другому в прямом / обратном направлении.

Отличительной особенностью диаграммы сотрудничества по сравнению с диаграммой взаимодействия является возможность использовать более богатый набор синтаксических конструкций. На рис. смоделирована ситуация, которая предусматривает наличие у экземпляра класса «ConcreteStateA» метода «create». Метод «create» в цикле позволяет создать мультиобъект (коллекцию) «ConcreteStateB». Причем, поскольку метод «create» вызывается с аргументом, то это означает, что при создании используется конструктор с параметрами.

Рисунок – Циклы на диаграмме сотрудничества
Циклы на диаграмме сотрудничества

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

Диаграмма деятельности (Activity Diagram)

Диаграммы деятельности (Activity Diagram) позволяет изобразить поток операций в системном, производственном или технологическом процессе. Диаграммы деятельности используется для моделирования прецедента в виде последовательности действий (activity), описывающих взаимодействие актера с системой. Эта диаграмма концентрирует внимание на том, какие действия выполняются и кто несет ответственность за их выполнение. Деятельность изображается на диаграмме в виде

Деятельность может быть двух типов:

  • action – действие.
  • send event – посылка события.

В свою очередь действие (action) может имеет имя (name) и выполняться по входу (on Entry), по выходу (on Exit), во время (Do) и при возникновении события (on Event). Семантика деятельности «Подготовка диска» в состав которого входит действие «Форматирование», которое выполняется по входу имеет след. вид:

Рисунок – Изображение действия на диаграмме деятельности
Изображение действия на диаграмме деятельности

При инициализации действия по событию (on Event) можно указать имя события, передаваемые аргументы (arguments) и условие, которое должно выполниться для инициализации действия по данному событию. Семантика деятельности «Технологический процесс», включающее действие «Звонок», которое выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» имеет след. вид:

Рисунок – Изображение действия с событием
Изображение действия с событием

Если деятельность имеет тип «send event» — послать событие, то, кроме указания момента инициализации данной деятельности (on Entry, on Exit, Do, on Event) можно указать посылаемые аргументы (Send arguments) и целевую деятельность (Send target). Действие «Звонок» деятельности «Технологический процесс» выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» и заключается в посылке сообщения деятельности «Завершение процесса» с аргументами (статус и полное время). В этом случае семантика деятельности «Технологический процесс» имеет следующий вид:
Рисунок – Изображение действия с событием и условием осуществления
Изображение действия с событием и условием осуществления

Диаграмма деятельности кроме собственно деятельностей (activity) может включать в свой состав:

  • состояния (State),
  • синхронизации (Synchronizations),
  • узел решения (слияния) – decision и
  • разделы (swimlanes-плавательные дорожки).

Состояние (State) – это ситуация в жизни объекта на протяжении которой он удовлетворяет некоторому условию при этом объект осуществляет определенные действия или ожидает некоторого события. Так же как и Деятельность состояние может быть двух типов: action – состояние в котором выполняется заданное действие и send event – состояние, которое посылает событие с аналогичными настройками момента перехода в состояние или посылки сообщения.

Перемещение объекта от одной деятельности (состояния) к другой отражается с помощью стрелки (transition).
Спецификация перехода включает в себя:

  • событие (event) – это то, что вызывает переход от одной деятельности к другой. Имя события помещается над связью между состояниями. У события могут быть аргументы.
  • защитные условия (guard conditions) – условия, наложенные на осуществление перехода. Защитные условия указываются вдоль линии перехода после имени события и заключаются в квадратные скобки.
  • действие (action), которое должно быть выполнено в процессе перехода (указывается вдоль линии перехода после «/»).
  • событие, которое может быть послано (send event) целевой деятельности (send target) с аргументами (send arguments)

Рисунок – Семантика условного перехода
Семантика условного перехода

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

Узел синхронизации (Synchronizations) предназначен для разделения потока на несколько параллельных потоков или, напротив, объединяет несколько входящих потоков на один исходящий.
Узел решения – decision должен сопровождаться указанием условия перехода в виде комментария. При этом каждая ветвь потока должна снабжаться сторожевым условием (guard condition). Он становится узлом слияния, если объединяет несколько потоков.
Разделы (swimlanes-плавательные дорожки) предназначены для разделения деятельностей с помощью их группировки по прецедентам, классам, компонентам, ролям и т.д.
Историческое состояние (обозначается «Н») – это псевдосостояние, которое восстанавливает предыдущее активное состояние в композитном состоянии. Оно позволяет композитному состоянию OpenState запоминать, какое из вложенных состояний (StopState или StartState) было текущим в момент выхода из OpenState, для того, чтобы любой из переходов в OpenState возвращался именно в это вложенное состояние, а не в начальное.

Рисунок – Изображение «Исторического состояния»
Изображение «Исторического состояния»

Диаграмма состояний (Statechart Diagram) является частным случаем диаграммы деятельности и предназначена для описания состояний объекта и условий перехода между ними, которые в совокупности характеризуют поведение объекта в течение его жизненного цикла. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния. Дуги графа служат для обозначения переходов из состояния в состояние.

Рисунок – Пример построения диаграммы деятельности
Пример построения диаграммы деятельности

Диаграммы взаимодействия (sequence и collaboration), а также диаграмма деятельности (activity) широко используются и на этапе анализа и на этапе проектирования для документирования результатов. Однако основное назначение этих диаграмм состоит в анализе предметной области (технологического процесса) для которой разрабатывается система. Основой же будущей системы является модель предметной области. Поэтому основной задачей стадии анализа является идентификация понятий предметной области и представление результатов в виде модели предметной области. По окончании проектирования эта модель преобразуется в код. В этой связи вопросам построения модели предметной области требуется уделить особое внимание.

Диаграмма классов (Class Diagram)

Модель предметной области отображает основные (с точки зрения проектировщика) классы понятий (концептуальные классы) в терминах предметной области. На языке UML модель предметной области представляется в форме диаграммы классов, на которой изображаются классы понятий реального мира, а не программных компонент. Кроме концептуальных классов модель предметной области может отображать ассоциации между классами и атрибуты концептуальных классов. Однако операции на диаграмме классов модели предметной области не отображаются.

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

Например, на рис. представлена диаграмма классов основного сценария варианта использования П.1 «Добавление файла УММ для обработки», где Спецификация загрузок УММ моделирует таблицу БД, в которую будут сохраняться данные (логин пользователя, дата, имя файла) о загружаемых на сервер файлах УММ. В Спецификации УММ для каждой УММ сохраняется атрибутивная информация (название УММ, год издания, кол-во страниц и т.д.), состав которой перечислен в ТЗ.

Рисунок — Диаграмма классов варианта использования «Добавить файл УММ для обработки»
Диаграмма классов варианта использования «Добавить файл УММ для обработки»

На диаграмме класс изображается в виде прямоугольника, снабженного тремя внутренними зонами: имя класса, атрибуты, операции. Операция устанавливает форму функции или процедуры (ее сигнатуру). Конкретной реализацией операции является метод. В качестве имени класса следует использовать существительное в ед. числе.

Рисунок – Изображение класса на диаграмме классов
Изображение класса на диаграмме классов

Объекты обмениваются сообщениями через соединения — связи. Но, для того, что бы между объектами была связь, между классами этих объектов должна существовать ассоциация, так как связь между объектами – это экземпляр ассоциации между классами.
Ассоциация – это связь между классами, отражающая некоторое значимое отношение между ними.
В процессе анализа ассоциаций необходимо придерживаться принципами минимализма, поскольку, если МПО будет состоять из N классов, то теоретически между ними можно будет установить N(N-1). В этой связи, в модель включают только те ассоциации, знания о которых необходимо сохранять в течение некоторого периода.
Не только ассоциация в целом может иметь имя, но и классам на обоих концах ассоциации могут быть присвоены имена ролей, исполняемые объектами классов, когда они связаны экземпляром данной ассоциации. Стрелка показывает направление передачи информации (например, посылки сообщения) от одного объекта к другому.
Например, предположим, что компания нанимает n служащих. Ограничения кратности (множественность — multiplicity) «1» и «n» означают, что объекты Person в данный момент времени могут быть наняты только одним объектом Company и Person не могут быть безработными. Объект Company может посылать сообщения объектам Person, но не наоборот.

Рисунок – Использование символов множественности на диаграмме классов
Использование символов множественности на диаграмме классов

Недооцененная кратность ограничивает гибкость приложения, например, некоторые персональные менеджеры не позволяют охранять несколько телефонов для одного человека.
Частным случаем ассоциации является ассоциация-класс (Association Class), которая обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс – это место, где хранятся относящиеся к ассоциации атрибуты и операции.
Имена полюсов ассоциаций являются обязательными, когда класс имеет ассоциацию с самим собой (рефлексивная ассоциация), которая означает, что объекты данного класса имеют связи с другими объектами этого же класса.
Каждый объект Directory может иметь связь с объектами Directory, выступающими в роли subdirectory, число которых может меняться от 0 до n. C другой стороны у подкаталога родитель может быть только 1 или не иметься вообще. Кроме того, Directory может иметь связь с произвольным числом объектов File.

Рисунок – Пример использования рефлексивной ассоциации на диаграмме классов
Пример использования рефлексивной ассоциации на диаграмме классов

Ввиду широкого распространения ассоциаций типа многие-ко-многим в UML предусмотрены специальные классы ассоциации. Подобно обычным классам, классы ассоциаций могут иметь атрибуты и операции, являющиеся принадлежностью связи, т.е., такие, которые не могут быть приписаны ни к одному из объектов-участников ассоциации. На рис. атрибут accessPermission (разрешение доступа) класса AccessibleBy (Доступно) относится и к файлу и пользователю одновременно и не может быть прикреплен только к одному из них без потери информации.

Рисунок – Класс-ассоциация
Класс-ассоциация

Конкретизированные формы ассоциации (association):

  • зависимость (dependency) – однонаправленная связь, показывающая, что один класс зависит от определений, сделанных в другом. Такая связь имеет место, например, если один класс использует другой в качестве параметра операции. При генерации кода к исходному классу атрибуты целевого класса добавлены не будет, но в код будет добавлен оператор типа «#include».
  • агрегация (aggregation) – частный случай ассоциации, который выражает отношение целое-часть (например, автомобиль-двигатель). Агрегация является транзитивной: если А является частью В, а В – частью С, то А — часть С. Агрегация изображается с помощью ромба, который ставится около полюса, являющегося агрегатом. Жизненный цикл объекта–части совпадает с ЖЦ объекта-целого. Более сильная разновидность агрегации – это связь типа «композиция» (объединение – composition), которая накладывает на ассоциацию два дополнительных ограничения:
    • (i) составляющая часть может принадлежать не более чем одному агрегату;
    • (ii) составляющая часть получает срок жизни агрегата. Композиция обозначается закрашенным ромбом. Таким образом, агрегация – это способ встраивания нескольких объектов в один объект-контейнер и использование встраиваемых объектов для реализации методов контейнера.

Код:
агрегация (aggregation) – частный случай ассоциации, который выражает отношение целое-часть

Обобщение (generalization) – показывает связи наследования между двумя классами (суперкласс-подкласс). При этом, подклассы наследуют все возможности своих надклассов (атрибуты, операции, отношения, ограничения) – inheritance. Обобщение часто используется совместно с абстрактными классами, которые могут иметь абстрактные атрибуты и операции. Абстрактные классы не создают экземпляров. Подкласс абстрактного класса реализует абстрактные операции, добавляя новые возможности, или переопределяя их.

Рисунок – Наследование на диаграмме классов
Наследование на диаграмме классов

Поскольку обобщение транзитивно, экземпляр подкласса одновременно является экземпляром всех его предков, т.е. обладает значениями всех атрибутов всех классов-предков и может вызывать любую операцию, указанную у любого из его предков. Не следует создавать слишком глубокую иерархию классов, поскольку это затруднит восприятие модели – иерархия с количеством уровней не превышающих 3, как правило, всегда приемлема; 5-6 уровней иерархии может быть как приемлемо, так и нет в зависимости от особенностей проектируемой системы.
Кроме того, обобщение следует использовать только там, где по крайней мере один из подклассов обладает атрибутами, операциями или ассоциациями, неприменимыми к суперклассу. Например, не следует использовать обобщение, когда существуют подклассы одинаковые по своей сигнатуре и поведению с суперклассом (масть карты Таким образом, ассоциации типа «обобщение» позволяют обеспечить полиморфизм:
добавляя новый подкласс автоматически наследуется поведение суперкласса и, более того, новый подкласс не нарушает работу существующего класса.
Следует отметить, что некоторыми языками программирования поддерживается множественное наследование, которое позволяет классу наследовать составляющие от нескольких классов одновременно.

На рисунке показано дерево классов, в котором SubClass является подклассом (дочерним классом) по отношению к двум суперклассам (базовым классам) – SuperClass1 и SuperClass22. Object1 и Object2 – экземпляры класса SubClass, наследующие атрибуты класса SubClass (x и y). В свою очередь SubClass наследует атрибуты z и w классов SuperClass1 и SuperClass2, переопределяет3 атрибут x и добавляет атрибут y.
Таким образом, при вызове, например Object1.x или Object2.x будет использоваться атрибут SubClass.x, находящийся на один уровень выше в иерархии наследования; при вызове Object1.z или Object2.z будет использоваться атрибут SuperClass1.z, поскольку класс SuperClass1 находится левее в дереве по сравнению с SuperClass2, то SubClass будет наследовать атрибуты SuperClass1 в первую очередь. Таким образом, при использовании множественного наследования следует иметь в виду, что порядок классов, перечисленных в строке заголовка инструкции class наследующего класса, определяет порядок наследования атрибутов.

Рисунок – Множественное наследование
Множественное наследование

Рисунок – Листинг кода, демонстрирующий множественное наследование
Листинг кода, демонстрирующий множественное наследование

Множественное наследование стараются избегать или путем реструктурирования модели на этапе проектирования или с помощью механизма реализации «делегирование».

Видимость атрибута указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости:

  • public (общий) – любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;
  • protected (защищенный) – только класс или потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;
  • private (закрытый) – только данный класс может пользоваться закрытыми атрибутами. Обозначаются символом «-»;
  • package or implementation (пакетный) – атрибут является общим в пределах пакета в котором расположен класс. Обозначаются символом «~».

При определении видимости для той или иной составляющей необходимо руководствоваться следующими соображениями:

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

Еще одной важной характеристикой атрибутов и операций классов является область действия (scope), которая определяет к чему относится данная составляющая: к объекту или к классу. У объектов есть собственные копии атрибутов, принимающих разные значения и операций. Область действия этих атрибутов и операций instance (экземпляр) – у каждого экземпляра класса есть собственное значение данного свойства. Однако иногда нужно определить атрибуты, которые имеют единственное, общее для всех объектов класса значение. Аналогично нужны операции, не относящиеся ни к одному конкретному экземпляру класса (например, операция создания объекта — конструктор). Такие атрибуты и операции имеют область действия classifier (классификатор) – все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).
В этом случае оно называется статическим.
Для группировки классов, обладающих общностью, применяют пакеты, которые являются средством организации модели в процессе разработки, повышения ее управляемости и читаемости. Диаграмма пакетов – диаграмма, содержащая пакеты классов и зависимости между ними. Кроме того, пакеты используются для представления подсистем (модулей) системы в процессе проектирования. Подсистема, включающая совокупность классов, реализует набор операций, которые определены в ее интерфейсе.

Рисунок – Диаграмма пакетов
Диаграмма пакетов

Элемент может принадлежать пакету, в котором он определен или на него можно ссылаться из других пакетов. Если один элемент пакета зависит от элемента другого пакета, то эту зависимость можно отобразить с помощью связи.

Рисунок – Сопоставление пакетов проектным слоям
Сопоставление пакетов проектным слоям

Каждый пакет представляет пространство имен (namespace), следовательно каждый класс внутри собственного пакета должен иметь уникальное имя. Чтобы отличить один класс от другого, можно использовать полностью определенное имя (fully qualified name), то есть имя, которое указывает на структуру, владеющую пакетом. В языке UML в именах пакетов используются двойные двоеточия, поэтому классы дат могут иметь имена System::Date.
Можно показывать только имя пакета или имя вместе с его содержимым.
Согласно концепции UML классы в пакетах могут быть открытыми (public) или закрытыми (private). Открытые классы представляют часть интерфейса пакета и могут быть использованы классами из других пакетов; закрытые классы недоступны извне. Можно сделать это, присвоив всем классам модификатор видимости private (закрытый), так чтобы они были доступны только классам данного пакета, а также создав дополнительные открытые классы для внешнего использования. Эти дополнительные классы, называемые Facades (Фасады), делегируют открытые операции другим классам пакета.

Диаграмма компонент (Component Diagram)

Component Diagram (диаграмма компонентов) позволяет создать физическое отражение текущей модели. Диаграмма компонентов показывает организацию и взаимосвязи программных компонентов, представленных в исходном коде, двоичных или выполняемых файлах.
В связи с тем, что система может состоять из модулей различного типа, пользователь может использовать следующие стереотипы для определения этих различий, причем изменение стереотипа часто ведет к изменению графического отображения компонента на диаграмме:

  • Package (пакет) — объединяет группу компонентов в модели;
  • Main program (главная программа);
  • Subprogram body (тело подпрограммы);
  • Package specification/body (определение/тело пакета).

Рисунок — Диаграмма компонент
Диаграмма компонент

Диаграмма размещения (Deployment Diagram)

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

Рисунок – Диаграмма размещения
Диаграмма размещения