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

3. Задачи между участниками проектных групп распределяются в процессе работы.

4. Описание всей выполненной работы содержится в одном отчете, который впоследствии хранится на кафедре.

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

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

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

3. Отсутствие четкого распределения ролей в проектных группах. Например, в начале работы не всегда определяется так называемый капитан команды, который занимается организацией работы внутри группы и взаимодействием с научным руководителем, из-за этого обычно возникают трудности в процессе коммуникации как внутри группы, так и с самим научным руководителем. Также, из-за этой проблемы, задачи изначально не всегда распределяются между участниками проектных групп, то есть они понимают общий объем работ, но не всегда понимают деталей и сопутствующих процессов, их трудоемкости. Таким образом, это ведет к неравномерному распределению задач между всеми участниками проектных команд. Это же касается и взаимодействия с преподавателем, обычно этим занимается тот студент, которому это удобно в данный момент. Таким образом каждое взаимодействие между проектной группой и научным руководителем будет различаться, так как каждый раз состав участников будет различен, что негативно сказывается на результатах самого взаимодействия [15]. Это может привести, например, к недопониманию требований, или представитель проектной группы может не знать обо всех аспектах, которые нужно было в данный момент уточнить у преподавателя.

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

2.2 Описание бизнес-процесса «как должно быть»

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

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

На рисунке В.1 приведен общий процесс разработки программного обеспечения, который декомпозируется в дальнейшем для этапов «Формирование первичных требований» и «Разработка программного продукта».

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

1. Распределение ролей в команде.

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

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

2. Подготовка к процессу разработки. Данный этап более подробно отображен на рисунке В.2 в приложении В.

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

Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику [5].

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

Краи?не важным моментом является «встраивание» информации, полученнои? в процессе интервью с заказчиком, в проектную документацию - иначе вся собранная информация не имеет никакого значения для проекта [5].

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

На основе полученного списка требований формируется календарный план работ с использованием MS Project. Данный план должен включать не только основные этапы проекта, но и примерное разбиение по итерациям циклов разработки с примерным перечнем задач на каждую итерацию. В процессе разработки итоговое количество таких итераций может изменяться в зависимости от итоговой сложности задач или каких-либо других факторов. Каждое такое изменение должно фиксироваться в итоговом календарном плане. Следует отметить, что в TFS имеется интеграция с сервером сетевого планирования, что упростит задачу актуализации календарного плана и доступа к нему всех участников проектной команды.

3. Разработка программного продукта. Данный этап более подробно отображен на рисунке В.3 в приложении В.

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

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

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

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

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

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

3.3. Группа разработчиков самостоятельно распределяет между собой задачи, требующие реализации в текущем спринте. Это сделано, так как разработчики лучше могут оценить свой набор навыков и компетенций и распределить задачи так, чтобы увеличить качество конечного продукта [6, 13]. Все свои задачи каждый разработчик вносит в общую рабочую область TFS, таким образом, остальные участники проектной команды смогут отслеживать статус текущих работ.

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

Для определения длительности операции? можно использовать следующие инструменты и методы.

Оценка по аналогам подразумевает оценку фактической? длительности аналогичной? предыдущей? плановой? операции в качестве основы для оценки длительности будущей? плановой? операции и использует историческую информацию и экспертную оценку [5].

Параметрическая оценка. Оценочную величину длительности операции? можно вычислить путем умножения количества работы на производительность труда. Для определения длительности операции? по рабочим периодам общее количество ресурсов умножается на количество рабочего времени или производительность за рабочий? период и делится на количество привлеченных ресурсов [5].

После определения задач, их длительности и назначенных исполнителей следует процесс их реализации.

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

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

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

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

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

Глава 3. Симуляция процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь

В данной части работы будет рассмотрено моделирование спроектированного ранее бизнес-процесса.

3.1 Выбор инструмента моделирования бизнес-процессов

Сейчас на рынке информационных технологий представлено множество различных технических средств для построения бизнес-процессов и информационных потоков данных в различных нотациях. Для рассматриваемой задачи предполагается использование BPMN методологии в построении бизнес-процесса разработки ПО.

Спецификация BPMN описывает графическую модель для отображения бизнес- процессов в виде диаграмм бизнес-процессов. Для построения диаграмм используется базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. В рамках BPM-систем методология BPMN служит связующим звеном между фазой проектирования бизнес- процесса и фазой его реализации [17].

Базовый набор элементов диаграмм содержит четыре категории:

· Объекты потока: события, задачи и шлюзы (логические операторы).

· Соединяющие объекты: поток выполнения, поток сообщений и ассоциации.

· Роли: пулы и дорожки.

· Артефакты: данные, группы и текстовые аннотации.

Существует ряд инструментов, позволяющих моделировать бизнес-процессы с использованием нотации BPMN. Наиболее удобными представителями являются программные инструменты Bizagi и RunaWFE. Далее будут более подробно рассмотрены данные инструменты.

Система Bizagi в полном виде называется BPM Suite и включает в себя 3 модуля для полноценной настройки процессов:

· Modeler -- полнофункциональная среда моделирования процессов в нотации BPMN;

· Studio -- среда разработки бизнес-процессов;

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

Первым шагом к созданию полноценного решения является определение и моделирование процесса с использованием приложения Bizagi Process Modeler. Это приложение позволяет визуализировать диаграммы, модели и документы бизнес-процессов согласно стандарту BPMN.

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

· Возможность назначения ролей и стоимостей процессов.

· Вероятностный анализ (What-If).

· Встроенная отладка бизнес процессов.

· Временной анализ бизнес-процессов (демонстрация затрат временных ресурсов на выполнение работ).

· Анализ ресурсов.

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

Модель, полученная при помощи данного модуля, является основой для построения BPM приложения.

Важным шагом к полной автоматизации бизнес-процесса является отражение всей информации, необходимой для моделирования каждого этапа данного процесса. Особенность системы Bizagi в том, что она поддерживает эту информацию в виде реляционной модели данных, что является наиболее значимым конкурентным преимуществом по сравнению с другими решениями по автоматизации бизнес-процессов [18]. Это позволяется различным процессам обмениваться информацией в едином поле, что в свою очередь позволяет избежать ненужной передачи данных.

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

· Простота.

· Качественные выразительные средства.

· Интеграция с Microsoft Office.

· Гибкость.

· Доступ через веб-интерфейс.

· Полная кастомизация пользовательского интерфейса.

При этом основным недостатком данной системы является модель её распространения. Модуль Bizagi Modeler является бесплатным и позволяет строить и симулировать бизнес-процессы. Однако для создания полнофункционального приложения необходимо приобретать и разворачивать все модули пакета Bizagi Suite.

RunaWFE -- это свободная система управления бизнес-процессами и административными регламентами с открытым кодом. RunaWFE распространяется некоммерческим образом: бесплатно, вместе с исходными кодами программы под свободной лицензией LGPL [19].

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

Особенности работы системы:

· Работа с определениями и экземплярами бизнес-процессов, работа со списками заданий исполнителей.

· Визуализация форм, соответствующих заданиям. На формы в данном случае выносятся переменные модели, а также различные пояснения. Формы могут дополнительно кастомизироваться при помощи Javascript и CSS.

· Работа с системой через веб-интерфейс.

· Авторизация и аутентификация пользователей в веб-интерфейсе.

· Отображение текущих этапов бизнес-процесса во время его симуляции [19].

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

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

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

3.2 Описание созданного решения с использованием выбранного инструмента моделирования бизнес-процессов

В качестве инструмента моделирования был выбран программный продукт RunaWFE. Данный продукт позволяет не только создать модель бизнес-процесса, но и развернуть его как веб-приложение, назначить различные группы пользователей в качестве исполнителей, а также настроить пользовательские формы ввода переменных модели.

Граф построенной модели отображен в приложении Г на рисунке Г.1. Его этапы были подробно рассмотрены во второй главе, поэтому в данном случае необходимо детально рассмотреть дополнительные компоненты бизнес-процесса - назначение ролей и операции с переменными модели.

Для данной модели были созданы 5 категорий пользователей, согласно обозначенным ранее ролям проектной группы:

· Менеджер проекта.

· Аналитик.

· Архитектор.

· Разработчик.

· Тестировщик.

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

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

Таблица 3.1. Перечень переменных модели

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

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

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

В таблице ниже представлен перечень всех этапов процесса с исполнителями и используемыми на данных этапах переменных модели:

Таблица 3.2. Перечень этапов процесса

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

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

3.3 Организация работы проектной команды в веб-интерфейсе

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

Меню веб-интерфейса RunaWFE включает в себя следующие разделы:

· Список заданий - список назначенных для текущего пользователя заданий процесса.

· Запустить процесс - перечень всех опубликованных процессов, для которых можно начать симуляцию.

· Запущенные процессы - запущенные на данный момент процессы.

· Исполнители - перечень групп и исполнителей для всех опубликованных процессов.

· Отношения - выстраивание иерархии между исполнителями (в рамках данной работы не рассматривается).

· Бот станции - добавление роботов, которые будут симулировать поведение исполнителей процесса (в рамках данной работы не рассматривается).

· Система - общая информация о развернутой версии RunaWFE.

· Настройки - различные настройки разделов, включающие настройки веб-интерфейса, настройки графов и другие.

· Логи сервера.

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

Инициатором запуска симуляции процесса разработки ПО является менеджер проекта. Для начала симуляции достаточно выбрать процесс из общего списка и нажать на его кнопку запуска:

Рисунок 3.1. Запуск симуляции процесса разработки ПО

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

Рисунок 3.2. Проставление условий для запуска симуляции

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

Рисунок 3.3. Перечень назначенных пользователю заданий

По окончанию работы по текущей задаче пользователю необходимо заполнять переменные на форме задания для корректной работы модели. Так, на рисунке 3.4 отображена форма окончания выполнения этапа «Уточнение задания у научного руководителя». Перечень вводимых и отображаемых переменных, а также описание всех этапов процесса были описаны ранее (табл. 3.2.). Для всех форм была реализована проверка заполнения переменных модели. То есть если пользователь, например, не загрузит файл со списком требований на этапе «Уточнение задания у научного руководителя», то ему отобразится соответствующая ошибка.

Рисунок 3.4. Форма окончания выполнения задания с заданием переменной модели

Помимо описания задания, на форму могут быть вынесены переменные модели, информация из которых необходимо для решения текущей задачи. Так, на рисунке 3.5 отображается форма для этапа «Формирование списка первоначальных требований», на которой пользователю отображаются добавленные на предыдущих этапах файлы с требованиями от научного руководителя и с документацией по смежным проектам. Данные файлы необходимы для формирования списка первоначальных требований, они загружаются из веб-приложения по клику на них.

Рисунок 3.5. Форма с отображением внесенных ранее данных

Полный перечень форм для всех этапов моделируемого процесса можно посмотреть в приложении Д.

На вкладке меню «Запущенные процессы» в веб-интерфейсе отображается сводная информация по всем симулируемым в текущий момент времени процессам. Данная информация включает в себя:

· Дату запуска;

· Текущее состояние процесса (на каком этапе в текущий момент времени он находится);

· Все роли процесса и соответствующих им исполнителей;

· Все проинициализированные на текущий момент времени переменные модели со значениями;

· Отчет с историей выполнения задач с датами и временем их выполнения;

· Отчет в виде диаграммы Ганта по этапам процесса;

· Граф процесса, на котором визуально отображается не только текущий этап процесса, но и по каким веткам условий отработала симуляция.

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

Рисунок 3.6. Сводная информация по процессу

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



Рисунок 3.7. История выполнения задач моделируемого процесса

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

Рисунок 3.8. Диаграмма Ганта моделируемого процесса

На рисунке Г.2 в приложении Г приведен пример графа модели, на котором визуально отображается текущий этап процесса (для примера взят этап «Реализация текущих задач») и ветки условий, по которым данная модель работала. Таким образом, был реализован пользовательский интерфейс для симулируемой модели. Данный интерфейс включает в себя набор форм с описанием этапов процесса разработки ПО. Часть таких форм предоставляет пользователям необходимую для решения поставленной задачи информацию, введенную ранее другими пользователями. При этом все пользователи в любой момент времени могут посмотреть общую информацию о процессе, включая информацию о текущем этапе и все загруженные в модель файлы. Это позволяет организовать прозрачный рабочий процесс, где каждый пользователь чётко знает, что уже было сделано, что ему необходимо сделать, какая ему для этого нужна информация, а также что еще предстоит сделать для достижения поставленной цели всего проекта.

Заключение

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

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

Следующим этапом стало определении концепции разрабатываемой модели процесса разработки ПО. В рамках данной задачи были рассмотрены основные принципы организации процесса разработки, которые включают формирование проектной команды и организацию её работы. Были определены основные роли проектной команды, которые представлены в приложении А, а также описаны принципы их назначения. В рамках организации работы были рассмотрены принципы гибких методологий разработки, в частности методологии Scrum, определенные элементы которой было решено внести в новую модель. Помимо этого, для организации эффективной работы было решено использовать инструмент TFS, который позволит создавать единое рабочее пространство для всей проектной команды, тем самым обеспечивая централизованное хранение и обмен информации по проекту. Следует отметить, что в настоящий момент осуществляется внедрение данного инструмента в стенах НИУ ВШЭ - Пермь.

На этапе построения бизнес-процессов были рассмотрены процессы «как есть» и «как должно быть». Процесс «как есть» визуально отражает недостатки текущей модели. В рамках процесса «как должно быть» были определены основные этапы разработки ПО в учебных проектах, для каждого из которого был определен общий алгоритм действий и задач, которые лежат перед проектной командой. Для каждой из задач в рамках процесса были назначены роли членов проектных групп, которые будут заниматься её исполнением. При построении данного процесса было также учтено использование инструмента TFS на этапах, непосредственно, разработки ПО, а также написания проектной документации.

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

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

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

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

Библиографический список

1. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. [Электронный ресурс] [Режим доступа: http://docs.cntd.ru/document/gost-r-iso-mek-12207-2010] [Проверено: 17.03.2016].

2. Современный подход к организации групповой работы в проектной команде // Информационный портал iTeam. [Электронный ресурс] [Режим доступа: http://iteam.ru/publications/project/section_37/article_1147] [Проверено: 17.03.2016].

3. Брукс Ф., Мифический человеко - месяц или как создаются программные системы. СПб. Символ Плюс, 1999 г.

4. Учебный курс «Технологии программирования. Курс на базе Microsoft Solutions framework (MSF)». Лекция 5. Методология Microsoft Solutions Framework. Введение. Версии. Модель проектной группы. Нижний Новгород, 2006 г.

5. В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов «Методические основы управления ит-проектами». Москва, 2011г.

6. Методика RACI: оптимизация распределения полномочий и ответственности // Корпоративный менеджмент [Электронный ресурс] [Режим доступа: http://www.cfin.ru/management/people/instructions/RACI.shtml] [Проверено: 17.03.2016].

7. Матрица ответственности // bodunov.org [Электронный ресурс] [Режим доступа: http://www.bodunov.org/index.php/features/35-pmbok/2009-09-30-15-36-26/66-2009-10-01-20-54-43] [Проверено: 17.03.2016].

8. What is Agile? // Agile Alliance information site. [Электронный ресурс] [Режим доступа: https://www.agilealliance.org/agile101/what-is-agile/] [Проверено: 17.03.2016].

9. Скрам, описание. Версия 2012.12.13, Scrum Alliance Inc. [Электронный ресурс] [Режим доступа: https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/Why%20Scrum/Core%20Scrum%20Translations/Core-Scrum-Russian.pdf] [Проверено: 17.03.2016].

10. Обзор методологии Scrum // Информационный портал Agile Russia. [Электронный ресурс] [Режим доступа: http://agilerussia.ru/methodologies/обзор-методологии-scrum/] [Проверено: 17.03.2016].

11. Гибкие методологии разработки. Вольфсон Борис, версия 1.2. [Электронный ресурс] [Режим доступа: http://adm-lib.ru/books/10/Gibkie-metodologii.pdf] [Проверено: 17.03.2016].

12. Сетевое планирование в проектах // Институт международных программ Российского Университета Дружбы Народов. [Электронный ресурс] [Режим доступа: http://ido.rudn.ru/Open/menegment/t5_2.htm] [Проверено: 17.03.2016].

13. Microsoft Team Foundation Server // Aplana Quality Services. [Электронный ресурс] [Режим доступа: http://aplana.ru/experience/tools/2229-microsoft-team-foundation-server] [Проверено: 17.03.2016].

14. Дж.Д. Мейер, Джейсон Тейлор, Алекс Макман Прашант Бансод, Кевин Джонс. «Коллективная разработка с использованием Visual Studio Team Foundation Server». Корпорация Microsoft, июль 2007 г.

15. С. Архипенков. «Руководство командой разработчиков программного обеспечения». Москва, 2008 г.

16. С. Архипенков. «Лекции по управлению программным проектом». Москва, 2009 г.

17. Business Process Model and Notation (BPMN). Version 2.0, January 2011.

18. Bizagi Cources // Bizagi Suite Official Site [Электронный ресурс] [Режим доступа: http://www.bizagi.com/en/learning] [Проверено: 17.03.2016].

19. About RunaWFE // RunaWFE Official Site [Электронный ресурс] [Режим доступа: http://www.runawfe.org/About] [Проверено: 17.03.2016].

Приложение А. Роли и зоны ответственности участников проектной команды

Таблица В.1. Определение ролей проектной команды

Роль	Зона ответственности	Задачи
Менеджер проекта	Отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.	§ Выстраивание процесса взаимодействия с заказчиком и между членами проектной группы; § Координация и регулирование работы команды; § Разработка, поддержка и исполнение сводного плана задач и календарного графика проекта; § Мониторинг временного графика проекта;
Аналитик	Отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.	§ Организация работы с поставленными научным руководителем требованиями; § Анализ смежных проектов и формирование общего видения задачи; § Определение требований к разрабатываемому решению; § Определение компромиссов между параметрами “функциональные возможности продукта / время / ресурсы”; § Предоставление понятных и тестируемых требований команде разработчиков;
Архитектор	Отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.	§ Формулировка спецификации решения и разработка его архитектуры; § Определение структуры развертывания (внедрения) решения, если разрабатываемое решение планировалось внедрять в стенах университета;
Разработчик	Отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.	§ Оценка необходимого времени и ресурсов на реализацию каждого элемента разрабатываемого продукта; § Разработка или контроль разработки отдельных элементов; § Подготовка продукта к внедрению, если разрабатываемое решение планировалось внедрять в стенах университета; § Консультация членов команды по технологическим вопросам;
Тестировщик	Отвечает за качество решения с точки зрения заказчика и будущих пользователей.	§ Обнаружение всех дефектов разрабатываемого продукта; § Разработка стратегии и плана тестирования; § Тестирование программного продукта;

Приложение Б. Бизнес-процесс «как есть»

Рис А.1. Бизнес процесс «AS-IS»

Приложение В. Бизнес-процесс «как должно быть»

Рисунок Б.1. Основной процесс



Рисунок Б.2. Формирование первоначальных требований

Рисунок Б.3. Разработка программного продукта

Приложение Г. Модель симулируемого бизнес-процесса

Рисунок Г.1. Модель симулируемого бизнес-процесса

Рисунок Г.2. Пример симуляции модели

Приложение Д. Формы модели процесса разработки ПО

Рисунок Д.1. Стартовая форма

Рисунок Д.2. Уточнение задания у научного руководителя

Рисунок Д.3. Поиск и анализ документации по смежным проектам

Рисунок Д.4. Формирования списка первоначальных требований

Рисунок Д.5. Создание календарного плана работ



Рисунок Д.6. Описание ключевых требований к архитектуре решения

Рисунок Д.7. Проработка и описание архитектуры решения

Рисунок Д.8. Формирование перечня задач для текущей разработки

Рисунок Д.9. Распределение задач между разработчиками

Рисунок Д.10. Реализация текущих задач

Рисунок Д.11. Тестирование текущей разработки



Рисунок Д.12. Документирование результатов спринта разработки

Рисунок Д.13. Анализ результатов текущего спринта

Рисунок Д.14. Демонстрация промежуточной версии заказчику

Рисунок Д.15. Корректировка календарного плана

Рисунок Д.15. Демонстрация конечной версии заказчику

Рисунок Д.16. Сбор информации по проекту



Рисунок Д.17. Оформление отчета о работе

Размещено на Allbest.ru