Лекция 5. Паттерны архитектуры ПО. Инструментарий управления проектами ИС и ИТ

**Первый учебный вопрос. Agile. SCRUM. Kanban.** *Гибкая методология разработки (Agile)* — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля» . Гибкая методология направлена на уменьшение рисков за счёт сведения процесса разработки программного обеспечения к последовательности коротких итераций, длинною в пару недель. «В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике. В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают: - отчёт о проделанной работе с момента последнего Scrum’a; - список задач, которые сотрудник должен выполнить до следующего собрания; - затруднения, возникшие в ходе работы. Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации требования изменяются. Данную методологию целесообразно использовать, когда: - потребности пользователей постоянно меняются в динамическом бизнесе; - изменения на Agile реализуются за меньшую цену из-за частых инкрементов; - в отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Как минимум, она (команда) включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных. Данное семейство процессов разработки определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. *Agile Manifesto* принят 13 февраля 2001 года и содержит 4 основные идеи и 12 принципов, при этом не содержит практических советов для профессиональных разработчиков. Основные идеи Манифеста быстрой разработки: - люди и их взаимодействие важнее процессов и инструментов; - работающий продукт важнее исчерпывающей документации; - сотрудничество с заказчиком важнее согласования условий контракта; - готовность к изменениям важнее следования первоначальному плану. Принципы, которые разъясняет Agile Manifesto: - удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения; - приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта); - частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще); - тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; - проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; - рекомендуемый метод передачи информации — личный разговор (лицом к лицу); - работающее программное обеспечение — лучший измеритель прогресса; - спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; - постоянное внимание улучшению технического мастерства и удобному дизайну; - простота — искусство не делать лишней работы; - лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; - постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Существует большое разнообразие методологий разработки программного обеспечения, которые придерживаются ценностей и принципов заявленных в Agile Manifesto. Наиболее популярны среди экспертов SCRUM и Kanban. ***Методология SCRUM*** В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости. Scrum (англ. scrum «схватка») — методология гибкой разработки ПО, делающая акцент на качественном контроле процесса разработки. Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. Далее последуют основные определения методологии SCRUM. Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру, согласно скрам-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта. Бэклог (или баклог) — это журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов - источником пользовательских историй. *Журнал пожеланий проекта* (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса. *Журнал пожеланий спринта* (англ. Sprint backlog) — содержит функциональность, выбранную владельцем проекта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта. *Диаграмма сгорания задач* – диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта. Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом. Данные должны быть доступны для всех членов проекта. Пример диаграммы сгорания задач изображён на Рисунке 4.1:  Красным цветом выделяют задачи, запланированные разработчиками до начала их реализации. Синим – график фактической реализации запланированных задач. Процесс SCRUM представлен на Рисунке 4.2:  *История спринта* (Sprint story). Требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам. *Остановка спринта* (Abnormal Termination). Остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведённое время. Спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта. После остановки спринта проводится совещание с командой, где обсуждаются причины остановки. После этого начинается новый спринт. *Очки за пользовательскую историю* (Story Points). Абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL). *Задачи истории спринта* (Sprint Story Tasks). Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню). *Критерий готовности *(Definition of Done (DoD)). Критерии, определяющие степень готовности элемента из журнала пожеланий пользователя. *Скорость команды* (Velocity). Общее количество очков, набранных командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт. Основные роли (Core roles) в методологии SCRUM: 1. Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон. 2. Команда Разработки (Development Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта. Дополнительные роли (Ancillary roles) в методологии скрам: 1. Пользователи (Users). 2. Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review). 3. Управляющие (Managers) — люди, которые управляют персоналом. 4. Эксперты-консультанты (Consulting Experts). Пользовательские истории Обязательные поля ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования. Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и владелец проекта могли понять, о чём идёт речь и отличить одну историю от другой. Важность (Importance) — степень важности данной истории, по мнению владельца проекта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет. Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов». Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания. Критерии приемки (acceptance criteria) — значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками команды при планировании спринта. Дополнительные поля Иногда, также, используются дополнительные поля в бэклоге проекта, в основном для того, чтобы помочь владельцу проекта определиться с его приоритетами. Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля владелец проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет. Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений. Инициатор запроса (requestor) — владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ. ID в системе учёта дефектов (bug tracking ID) — если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся. Методология SCRUM подразумевает при планировании и реализации разработки программного обеспечения пять видов собраний персонала, каждое из которых носит вполне конкретную цель и призвано решить ряд прикладных задач. Планирование спринта (Sprint Planning Meeting) Происходит в начале новой итерации Спринта. - Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. - На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах. - Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи. - Обсуждается и определяется, каким образом будет реализован этот объём работ. - Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и т. п. Первая часть совещания – участвует владелец проекта и скрам команда: выбирают задачи из бэклога продукта. Вторая часть совещания – участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта.  Ежедневное совещание (Daily Scrum meeting) - начинается точно вовремя; - все могут наблюдать, но только «свиньи» говорят; - длится не более 15 минут; - проводится в одном и том же месте в течение спринта. В течение совещания каждый член команды отвечает на 3 вопроса: - Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта? - Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта? - Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.) Скрам над скрамом (Scrum of Scrums) Проводится после ежедневного скрам-совещания. Позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам-совещании плюс следующие вопросы: - Что каждая команда сделала с момента предыдущего ежедневного совещания? - Что каждая команда сделает к следующему ежедневному совещанию? - Есть ли проблемы, мешающие или замедляющие работу каждой команды? - Нужно ли другой команде сделать что-то из задач вашей команды? Обзор итогов спринта (Sprint review meeting) Проводится в конце спринта. - Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам. - Привлекается максимальное количество зрителей. - Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). - Нельзя демонстрировать незавершенную функциональность. - Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта. Ретроспективное совещание (Retrospective meeting) Проводится в конце спринта. - Члены команды высказывают своё мнение о прошедшем спринте. - Отвечают на два основных вопроса: что было сделано хорошо в прошедшем спринте и что надо улучшить в следующем? - Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения). - Ограничена одним-тремя часами.  ***Методология Kanban*** Данная методология, основанная на Agile-методах, набирает всё большую популярность среди разработчиков программного обеспечения. Kanban — метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу. Kanban основан на четырёх основных принципах: - Опора на существующие методы разработки. Kanban начинается с существующих методов разработки и стимулирует в них дополнительные изменения. - Предварительная договорённость о проведении важных изменений. Команда разработчиков должна учитывать, что постоянные изменения — это способ улучшить существующий процесс разработки, однако проведение глобальных перемен имеет большой риск. Kanban поощряет небольшие и эволюционные изменения. - Уважение к существующему порядку, ролям и обязанностям. - Поощрение инициативы. Приветствуются проявления инициативы каждого разработчика. Kanban отлично работает с командами поддержки, такими как: - группы поддержки программного обеспечения, где не важен «план», но важна скорость реагирования на изменения; - группы тестирования, работающие отдельно от групп разработки; - службы поддержки; - другие примеры «неосновных производств». Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Например, давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе — 1 шт.  Для управления процессом руководитель проекта может: - изменить лимит на количество задач в работе; - добавить задачу с более высоким приоритетом (к примеру p0) для того, чтобы она была взята как можно скорее. В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. К ограничениям Kanban'а при использовании его в продуктовых командах можно отнести: - данная методология плохо работает с большими командами (больше 5 человек); - в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами; - ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования **Второй учебный вопрос. RAD. XP.** Доктрина создания средств разработки программного обеспечения, отдающая предпочтение скорости и практичности написания программного кода, формирующая условия для разработчиков наиболее быстро, комфортно и качественно создавать программные продукты. *RAD-модель *(rapid application development model) — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений. Инструментарий должен быть нацелен на минимизацию времени разработки. Создание прототипа для уточнения требований заказчика. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком. Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию. Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей. Управление проектом должно минимизировать длительность цикла разработки. Модель быстрой разработки приложений включает следующие фазы: - Бизнес-моделирование: определение списка информационных потоков между различными подразделениями. - Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации. - Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки. - Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код. - Тестирование: тестируются новые компоненты и интерфейсы.  Для использования данной модели рамках реализации проекта необходимо выполнение следующих условий: - «Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. - Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. - RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев. Основная особенность методологии *экстремального программирования* (eXtreme Programming) состоит в ее эффективности в условиях неопределенных или нечетких требований. Популярность данного подхода увеличивалась по мере роста числа разработчиков, недовольных традиционным подходом со множеством формальных требований и постоянно готовивших документацию, собиравшими информацию о показателях проекта. Напротив, новая методология предлагала простой дизайн, переработку (рефакторинг) кода для контроля затрат, постоянное присутствие заказчика, разработку через тесты и другие аспекты, выгодно отличавшие ее. Для работы в подобных условиях необходима постоянная связь с заказчиком, которая обеспечивается полноценным участием в работе проектной команды квалифицированного, находящегося в курсе проекта представителя заказчика. При разработке в большинстве случаев выбираются наиболее простые методы, исходя из принципа того, что легче в будущем вносить дополнения в базовую версию, чем перестраивать усложненную (хотя, разумеется, бывают исключения, когда изначально учет многих факторов в системе может помочь избежать в дальнейшем многих сложностей). Принцип простоты также важен и в интерфейсном решении, когда более интуитивный пользовательский дизайн интерфейса обладает исключительно необходимыми (но не излишними!) функциями. Однако предварительное детальное проектирование интерфейса согласно исходной версии методологии не осуществляется, он создается лишь по мере работы команды в течение проекта. Коллективная работа по написанию кода / внесению изменений в настройки. Этот принцип относится к двум аспектам. В первую очередь, это «коллективное владение кодом», когда любой участник команды разработчиков может внести изменения благодаря единым правилам оформления, когда и использованию стандартов для ПО. С другой стороны, применяется метод «парного программирования», в соответствии с которым двое разработчиков используют один компьютер, чередуя написание кода и доработку настроек, реализацию требований и прочие вопросы. **Третий учебный вопрос. Feature Driven Development** Feature driven development (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям, 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени. Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов: - Разработка общей модели. Команда разработчиков делится на группы создаёт модели для отдельных задач. Затем выбирается одна из предложенных моделей или их сочетание. - Создание списка функций. Когда команда разработала общую модель, она определяет полезные для клиента функции. - Планирование. Здесь важно учитывать нагрузку на группу, риски и другие аспекты, чтобы предотвратить возникновение критических проблем. - Дизайн и разработка. На основе данных первого процесса, менеджер проекта выбирает группу функций, которые команда должна реализовать за определённый срок. - Реализация. После того как команда разработала и протестировала код и модули, она приступает к созданию ПО. На этот и предыдущий этап уходит 75% усилий команды разработчиков.  Успех проекта напрямую зависит от опыта и знаний ведущего программиста. В FDD он играет все главные роли: руководителя, наставника, аналитика и так далее. При этом методология создана для долгосрочных проектов, поэтому, как отмечают резиденты Stack Overflow, применять её для небольших задач просто нет смысла. Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает, что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее. Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов». **Четвёртый учебный вопрос. Model – Driven architecture and development** MDA и MDD часто рассматриваются как направление дальнейшего развития UML. Суть MDA и MDD заключается в том, что модели будут способны управлять созданием исполняемой программной архитектуры. Иными словами, ПО будет создаваться за счет трансформации визуальной одели в программный код при помощи средств и инструментов MDA/ MDD. На практике развитие средств MDA/MDD позволит превратить UML в основной механизм производства программного кода, тогда как сейчас UML является скорее прообразом подобной методики. Разница между подходами не так уж велика: в обоих случаях делается акцент на применении моделей, как для создания архитектуры, так и для разработки ПО. Иными словами, модель — это своеобразный центр, вокруг которого происходит вся дальнейшая деятельность. В случае с построением архитектуры на основе модели программирование играет второстепенную роль, поскольку в идеале удается получить автоматически сгенерированный код на основе с разработчиками точных и исчерпывающих UML-диаграмм. Рассмотреть логику применения данных подходов проще всего на примере MDA. На первом шаге требуется создание машинно-независимой модели (CIM), которая характеризуется высоким уровнем абстракции. CIM фиксирует основные требования к системе и включает в себя словарь предметной области. **Пятый учебный вопрос. Model – Domain – Driven Design (DDD)** Основная цель Domain-Driven Design — это борьба со сложностью бизнес-процессов и их автоматизации, и реализации в коде. «Domain» переводится как «предметная область», и именно от предметной области отталкивается разработка и проектирование в рамках данного подхода.  Domain-Driven Design включает в себя множество вещей. Это и стратегическое проектирование, и взаимодействие между людьми, и подходы к архитектуре, и тактические паттерны — это целый арсенал, который реально работает и реально помогает делать проекты. Есть только одно «но». Прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design. Общение между участниками проекта формирует то, что в Domain-Driven Design называется «единый язык» (ubiquitous language). Единый он не в том смысле, что он один на все случаи жизни. Как раз наоборот. Единый он в том смысле, что все участники общаются на нём, всё обсуждение происходит в терминах единого языка и все артефакты максимально должны быть в терминах единого языка, то есть начиная от ТЗ и заканчивая кодом. **Шестой учебный вопрос. Методика Gantt** Это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами. Горизонтальная ось в диаграмме Гантта — шкала времени, которая может быть выражена в абсолютном значении либо значении времени, привязанного к началу проекта. Выбор времени зависит от типа проекта: обычно используются недели или месяцы. Столбы в диаграмме показывают время начала и окончания индивидуальной задачи в проекте (Рисунок 4.9).  Для больших проектов, задачи могут быть разделены на подзадачи, которые имеют собственные дополнительные диаграммы Гантта для более удобного прочтения. Сильная сторона диаграммы Гантта в возможности наглядно отобразить статус каждой задачи, создавать план проекта с шаблоном диаграммы, отслеживать процессы на основе приоритетного планирования. Обычно диаграммы Гантта строят в специальном софте для управления проектами. Ключевым понятием диаграммы Гантта является «Веха» — метка значимого момента в ходе выполнения работ, общая граница двух или более задач. Вехи позволяют наглядно отобразить необходимость синхронизации, последовательности в выполнении различных работ. Вехи, как и другие границы на диаграмме, не являются календарными датами. Сдвиг вехи приводит к сдвигу всего проекта. Поэтому диаграмма Гантта не является графиком работ. Кроме того, диаграмма Гантта не отображает значимости или ресурсоемкости работ, не отображает сущности работ (области действия). Для крупных проектов диаграмма Гантта становится чрезмерно тяжеловесной и теряет всякую наглядность. **Седьмой учебный вопрос. Методика CPM. Методика PERT.** Метод критического пути - инструмент планирования расписания и управления сроками проекта. В основе метода лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи. Задачи, лежащие на критическом пути (критические задачи), имеют нулевой резерв времени выполнения, и, в случае изменения их длительности, изменяются сроки всего проекта. В связи с этим, при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути. Ключевая задача метода – определить критический путь, и установить на нем максимальный контроль выполнения задач. Данное моделирование обладает следующими преимуществами: - Графически визуализирует этапы проекта. - Прогнозирует временной период, требуемый для завершения задачи. - Показывает, какие задачи критичны для выполнения проекта, а какие нет. Критический путь моделирует активности и события проекта во взаимосвязанную сеть. Активности отображаются как “узлы”, а события (начало и конец активности) выглядит как арки и линии между узловыми пунктами. Этапы построения диаграммы: - Выделить индивидуальные задачи проекта. «Следует начать со списка всех задач проекта. Он может быть использован как базис для создания последовательностей и оценки времени выполнения проекта на следующих этапах. - Определите последовательность выполнения выделенных задач. Выполнение одних задач напрямую связано с окончанием других. Определить, какие задачи следует выполнить в первую очередь, чтобы другие задачи не сдвигались. - Изобразить диаграмму в виде графической сети взаимосвязанных задач. Когда задачи и их последовательность определена, может быть построен критический путь в виде граф-схемы. - Оценить время каждой конкретной активности. «Время, требуемое для завершения каждой задачи, может быть оценено на основе прошлого опыта или оценок экспертов. - Обозначить критический путь (наиболее длинная цепочка действий в рамках сети). «Это наибольшая по длительности цепочка задач в системе. Важность заключается в том, что задачи, располагающиеся на этом пути, не могут быть отложены либо просрочены без переноса дедлайнов проекта. Такой вид анализа очень важен для оценки длительности проекта в целом. - Мониторинг обновления диаграммы по ходу реализации проекта.  Критический путь может быть определен 4 ключевыми параметрами каждой активности: - Ближайшее время старта (БС) — момент, когда все предыдущие задачи завершены. - Ближайшее время окончания (БО) — Ближайшее время старта плюс время, необходимое для завершения задачи. - Последнее время окончания (ПО) — Финальный момент, когда все активности завершены без переносов сроков задач. - Последнее время начала (ПН) — Последнее время окончания минус время, требуемое для завершения задачи. - Резервное время — это время между ближайшим и последним временем старта, или между ближайшим и последним временем окончания проекта. Резервное время — это то время, на которое может быть отложены ближайшее время старта и финиша без движения дедлайнов всего проекта. Критический путь — это цепочка через всю сеть задач проекта, в которой ни одна из задач не имеет резервного времени, когда БС=ПН и БО=ПО для всех задач на пути. Перерыв автоматически ведет к сдвигу проекта. Если подводить итог, то, чтобы уменьшить длительность проекта, нужно уменьшить время на задачи на критическом пути. В примере на Рисунке 4.10 ситуация обстоит следующим образом: 1 путь: начало-A1-A3-A6-конец = 3+1+3 = 7 (критический путь). 2 путь: начало-A1-A4-конец = 3+2 = 5 (резерв 2). 3 путь: начало-A2-A5-конец = 4+2 = 6 (резерв 1). Бывают случаи, когда точно определить длительность задачи сложно или невозможно (инновационный проект или проект с рисками). Для этих случаев эксперты в области проектирования информационных систем используют PERT метод. Диаграмма PERT — это многоцелевой инструмент в управлении проектами, который графически отображает сроки и ход задач проекта. Эти диаграммы состоят из кругов или прямоугольников (узлов), которые представляют собой ключевые вехи в рамках проекта. Линии или векторы, которые определяют различные задачи соединяют узлы (Рисунок 4.11):  Когда стрелка рисуется от задачи А к задаче B, то это означает, что задача А должна быть обязательно завершена до начала задачи B. Можно создать параллельные задачи, которые могут быть расположены на той же стадии, но на разных линиях задач. Они не должны зависеть друг от друга. Диаграмма представляет события, которые должны быть реализованы в рамках хода проекта. Стрелки показывают направления и указывают на потоки событий, которые должны произойти. Пунктирные линии представляют собой фиктивные активности, которые являются элементами, расположенными на другом пути. Номера, присвоенные каждой задаче, регулируют их. Как правило, диаграмма содержит горизонтальный график с подразделениями (дни или недели). Последовательные шаги по созданию диаграммы PERT: - Составить список уровней и этапов проекта, определить время, необходимое для завершения каждого события. - Добавить зависимости для создания связи между событиями. - Линии покажут время, которое занимает каждое событие. - Каждая линия на диаграмме должна прийти к шагу, который связан с завершением события. Диаграмма также отображает критический путь с последовательностями задач, которыми необходимо тщательно управлять, чтобы закончить все цели вовремя. PERT предназначен для очень масштабных, единовременных, сложных, нерутинных проектов. Метод подразумевает наличие неопределённости, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих. Метод в особенности нацелен на анализ времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта. Эксперты, применяющие методику PERT при планировании проектов, оперируют следующими терминами: - Событие PERT (англ. PERT event) — момент, отмечающий начало или окончание одной, или нескольких задач. Событие не имеет длительности и не потребляет ресурсы. В случае, если событие отмечает завершение нескольких задач, оно не «наступает» (не происходит) до того, пока все задачи, приводящие к событию, не будут выполнены. - Предшествующее событие (англ. predecessor event) — событие, которое предшествует некоторому другому событию непосредственно, без промежуточных событий. Любое событие может иметь несколько предшествующих событий и может быть предшественником для нескольких событий. - Последующее событие (англ. successor event) — событие, которое следует за некоторым событием непосредственно, без промежуточных событий. Любое событие может иметь несколько последующих событий и может быть последователем нескольких событий. - Задача PERT (англ. PERT activity) — конкретная работа (задача), которое имеет длительность и требует ресурсов для выполнения. Примерами ресурсов являются исполнители, сырьё, пространство, оборудование, техника и т.д. Невозможно начать выполнение задачи PERT, пока не наступили все предшествующие ей события. - Оптимистическое время (англ. optimistic time) t_0— минимальное возможная длительность выполнения задачи в предположении, что всё происходит наилучшим или наиболее удачным образом. - Пессимистическое время (англ. pessimistic time) t_p— максимально возможная длительность выполнения задачи в предположении, что всё происходит наихудшим или наименее удачным образом (исключая крупные катастрофы). - Наиболее вероятное время (англ. most likely time) t_m— длительность выполнения задачи в предположении, что всё происходит так, как бывает чаще всего (как обычно). - Ожидаемое время (англ. expected time) t_e— оценка длительности выполнения задачи на основе оценок оптимистического, пессимистического и наиболее вероятного времени:t_e=1/6 (t_0+4t_m+t_p ). - Проскальзывание или провисание (англ. float, slack) — мера дополнительного времени и ресурсов, доступных для выполнения работы. Время, на которое выполнение задачи может быть сдвинуто без задержки любых последующих задач (свободное проскальзывание) или всего проекта (общее проскальзывание). Позитивное провисание показывает опережение расписания, негативное провисание показывает отставание, и нулевое провисание показывает соответствие расписанию. - Критический путь (англ. critical path) — длиннейший маршрут на пути от начального до финального события. Критический путь определяет минимальное время, требуемое для выполнения всего проекта, и, таким образом, любые задержки на критическом пути соответственно задерживают достижение финального события. - Критическая задача (англ. critical activity) — задача, проскальзывание которой равно нулю. Задача с нулевым проскальзыванием не обязательно должна находиться на критическом пути, но все задачи на критических путях имеют нулевое проскальзывание. - Быстрый проход (англ. fast tracking) — метод уменьшения общей длительности проекта путём параллельного выполнения задач, которые в обычной ситуации выполнялись бы последовательно, например, проектирование и строительство. **Восьмой учебный вопрос. Методика RACI, RACIS** Методика RACI является удобным и наглядным средством проектирования и планирования изменений, а именно участия различных ролей в процедурах и задачах процесса. RACI matrix (RAM Responsibility Assignment Matrix) – график линейной ответственности. Показывает степень участия разных ролей в разных активностях процесса или проекта. «Матрица RACI представляет собой простой инструмент, используемый для определения ролей и обязанностей и избежания путаницы при исполнении задач или процессов. Используется при управления проектами и для показа обязанностей в состояниях "AS-IS" и "TO-BE". Часто метод RACI называют диаграммой или таблицей, но, по сути, это именно матрица ответственностей. Термин RACI (или ARCI) является аббревиатурой: R – Responsible (ответственный исполнитель). На исполнителе лежит обязанность реализации поставленной задачи; A – Accountable (утверждающий). Перед ним производится отчет в полученном результате, имеются полномочия, как принимать, так и отвергать предложения, накладывать на них вето; C – Consult before doing (консультант). До реализации задачи консультирует участников проекта. Данная роль подразумевает двустороннюю связь между задействованными в проекте подразделениями; I – Inform after doing (информируемый). Данное лицо оповещается после реализации проекта или отдельных его задач. Иногда можно встретить вариант аббревиатуры – RACIS, где S – supported (оказывает поддержку). Также, существует RACI-VS вариант модели, в котором добавляются 2 роли: «Verifies (V) – один сотрудник или группа, проверяющие соответствие результата выполнения задачи согласованным заранее допустимым критериям. Signs off (S) – утверждает сдачу продукта заказчику (выполнения задачи). Данную роль можно совместить с подотчетной ролью. Такое кодирование используется для формирования таблицы, которая характеризует участие той или иной роли при выполнении задач в процессе. Далее приводится пример использования матрицы RACI в процессе управления конфигурациями. Часть деятельностей в процессе, которые требуется назначить ролям: - Ввод новой категории. - Предоставление информации. - Устранение расхождений. - Обновление информации. - Аудит. - Совершенствование процесса. Некоторые роли процесса: - Владелец процесса. - Менеджер процесса. - Ассистент менеджера. - Владелец категории CI - Continuous Integration (непрерывная интеграция). Матрица представляет собой таблицу, столбцами которой являются роли, а строками – деятельности процесса или проекта. Пример матрицы распределения ответственности RACI представлен на Рисунке 4.12: Рисунок 4.12 – Матрица RACI процесса управления конфигурациями Есть несколько правил, которых следует придерживаться при построении матрицы RACI: - Accountable – должен быть только один. Если это не так, то нужно четко ограничить рамки, в которых, либо в данный момент по данной деятельности, либо в данных условиях ответственный только один, но в других условиях по той же деятельности возможно ответственность несет другой. Эту ситуацию разберем на следующем примере. - Responsible – должен быть в наличии по каждой деятельности, их может быть несколько, причем возможны совмещения. - Каждая деятельность обязательно должна иметь Accountable и Responsible. Матрица RACI это удобный инструмент визуализации, являющийся частью проектирования любого процесса, ибо в любом процессе есть роли и деятельности, которые требуется распределить и контролировать. **Девятый учебный вопрос. Методика WBS** WBS является средством для разделения всех работ по проекту на управляемые, определяемые пакеты работ, позволяющие достичь уровень детализации предоставляемой информации, соответствующий потребностям руководства проекта в контроле. Иерархическая структура проекта (WBS) имеет следующие характеристики: - Описывает с необходимой точностью содержание работ по проекту. - Определяет весь объем работ по проекту. - Формируется в виде иерархической структуры (проект декомпозируется на пакеты/субпакеты и т. д. работ). - Представляет объем работ по пакету как перечень работ, имеющих измеримый или сравнимый результат. - Имеет объективный или измеримый результат, который рассматривается как результат работы по пакету или совокупность результатов работ. WBS является инструментом, позволяющим руководителю проекта получить описание конечного результата (продукта, услуги) проекта и всех подпроектов, в результате которых будет достигнут запланированный результат. Далее WBS может разделяться (и результаты подразделяться) на части для специализации видов и объемов работ участников проекта, координации их действий и закрепления ответственности за объемами работ, вплоть до уровня, обеспечивающего управляемость и надлежащее администрирование проекта. WBS обеспечивает выявление работ, необходимых для достижения целей проекта. При таком подходе проект определяется в терминах иерархически взаимосвязанных ориентированных на результат элементов (пакетов работ — комплексов работ, сгруппированных по заданным основаниям/критериям). Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта. Предложенный подход декомпозиции работ формирует необходимую основу для определения измеримых показателей (трудоемкости, стоимости), а также позволяет с высокой степенью достоверности говорить о том, что цели, связанные с данным пакетом работ, могут и будут достигнуты. Для упрощения управления сложным проектом целесообразно его разделять на компоненты в иерархическую структуру, так называемую ИСП, или WBS (the work breakdown structure). Такая иерархическая структура проекта может быть представлена в виде блочной диаграммы.  Каждый уровень использует собственную терминологию: Каждая организация использует собственную терминологию для классификации компонентов ИСП, согласно их уровню иерархии. Например, некоторые организации разделяют на разные уровни задачи, подзадачи и перечни работ. ИСП может быть сформирована вокруг фаз и результатов проекта на протяжении всего его жизненного цикла. За более высокие уровни структуры обычно ответственны рабочие группы. Тогда как задачи нижнего уровня выполняются индивидуально. Таким образом, в ИСП как структуре, основанной на результатах, вовсе не обязательно создавать конкретные задачи. Разбиение проекта на компоненты ускоряет распределение ресурсов и устанавливает сферы ответственности каждого члена команды. Чем лучше детализация ИСП, тем более точными будут действия. С одной стороны, не следует слишком детализировать структуру, чтобы не стать жертвой микро-менеджмента. Но с другой, не стоит делать элементы слишком крупными, чтобы сохранить их управляемость. Оптимальная величина элементы — от нескольких дней до нескольких месяцев. ИСП — это основа планирования проекта. Однако она делается тогда, когда вы четко знаете взаимосвязь ваших задач и время, необходимое на их решение. ИСП создается специально, чтобы выделить задачи в CPM или PERT подходах.