Размещено на http://www.allbest.ru/

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное образовательное

учреждение высшего образования

"Национальный исследовательский университет

"Высшая школа экономики"

Пермский филиал

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа магистра

по направлению подготовки 38.04.05 «Бизнес-информатика»

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

Студент: Кагарманов Евгений Вадимович

Научный руководитель: В.В. Лебедев, к.т.н., доцент,

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

Пермь 2016

Аннотация

В данной работе рассматривается процесс разработки программного обеспечения в рамках учебных проектов студентов НИУ-ВШЭ. Выполнен анализ текущего процесса, выявлены его недостатки. Данные недостатки послужили основой при проектировании и моделировании улучшенного процесса организации и ведения разработки программного обеспечения.

Результат работы представлен в виде симулируемой модели спроектированного процесса. Данная модель может быть использована студентами университета при организации работы в своих проектных командах.

Оглавление

• Введение
• Глава 1. Обзор текущего процесса разработки ПО в НИУ ВШЭ - Пермь и методик его улучшения
• 1.1 Обзор текущего процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь
• 1.2 Определение понятия проектной группы в рамках учебных проектов в НИУ ВШЭ - Пермь
• 1.3 Обзор предлагаемого подхода к разработке ПО в рамках учебных проектов в НИУ ВШЭ - Пермь
• 1.3.1 Использование гибкой методологии Scrum при ведении учебных проектов
• 1.3.2 Использование инструментов сетевого планирования при ведении учебных проектов
• 1.3.3 Использование инструмента TFS при ведении учебных проектов
• 1.4 Резюме обзорной части
• Глава 2. Построение моделей процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь
• 2.1 Описание бизнес-процесса «как есть»
• 2.2 Описание бизнес-процесса «как должно быть»
• Глава 3. Симуляция процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь
• 3.1 Выбор инструмента моделирования бизнес-процессов
• 3.2 Описание созданного решения с использованием выбранного инструмента моделирования бизнес-процессов
• 3.3 Организация работы проектной команды в веб-интерфейсе
• Заключение
• Библиографический список
• Приложения

Список терминов и обозначений

Сокращение	Расшифровка
BPMN	Business Process Model and Notation
MSF	Microsoft Solution Framework
ПО	Программное обеспечение
НИУ ВШЭ	Национальный исследовательский университет «Высшая Школа Экономики»
ARIS	Architecture of Integrated Information Systems
TFS	Team Foundation Server
MS	Microsoft

Введение

программный обеспечение бизнес процесс

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

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

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

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

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

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

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

В рамках НИУ-ВШЭ данный процесс будет включать в себя не только непосредственно само проектирование и разработку программного продукта, но и взаимодействие всех участников определенной проектной группы, а также ведение проектной документации, включающей, например, техническое задание и описание программных компонентов решения. Известно, что в пермском кампусе НИУ ВШЭ планируется внедрение программного продукта Team Foundation Server, данная платформа может использоваться в качестве площадки для взаимодействия участников проектных групп, где они могут вести свои текущие задачи, а также хранить промежуточные результаты своей работы и документацию по программному решению.

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

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

Целью работы является создание инструмента для симуляции организации и планирования рабочего процесса в рамках ведения проектов по разработке программного обеспечения на базе пермского кампуса НИУ-ВШЭ.

Для осуществления поставленной цели были определены следующие задачи:

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

2. Построить модель «как есть» в нотации ARIS для данного процесса для формального представления существующего процесса.

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

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

5. Построить модель «как должно быть» в нотации ARIS для данного процесса для формального представления моделируемого процесса.

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

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

Глава 1. Обзор текущего процесса разработки ПО в НИУ ВШЭ - Пермь и методик его улучшения

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

1.1 Обзор текущего процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь

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

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

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

Считается, что для задач, которые могут быть разбиты на части, но требуют обмена данными между подзадачами, затраты на обмен данными должны быть добавлены к общему объему необходимых работ. При этом, если все задачи должны быть скоординированы между собой, то затраты возрастают как n(n-1)/2 (где n число работников, выполняющих эти задачи) [3]. То есть, если проектная группа состоит из трех человек, то требуется втрое больше попарного общения, чем для двух, для четырех человек - уже вшестеро.

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

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

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

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

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

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

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

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

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

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

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

1.2 Определение понятия проектной группы в рамках учебных проектов в НИУ ВШЭ - Пермь

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

За основу описания принципов построения проектной группы и организации взаимодействия её участников были взяты принципы Microsoft Solution Framewоrk.

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

К основным концепциям построения проектной команды в университете можно отнести:

· Концентрация на требованиях научного руководителя как заказчика - главный приоритет любой хорошо работающей проектной группы. Означает обязательное понимание задачи руководителя и стремление к их решению со стороны команды [4]. Не менее важным является активное участие самого руководителя в проектировании решения и получение его отзывов в ходе процесса разработки.

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

· Установка на отсутствие дефектов - подразумевает стремление к высочайшему уровню качества [4]. Данная установка означает, что цель команды - выполнение своей работы с максимально возможным качеством. В успешной команде каждый её участник чувствует ответственность за качество продукта.

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

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

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

Определение ролей университетских проектных групп и их зон ответственности аналогично базируются на определении основных ролей в методологии Microsoft Solution Framewоrk. Так, к таким ролям относятся:

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

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

· Разработчик - отвечает за проектирование и реализацию конечного продукта.

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

· Аналитик - отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении [4].

Далее более подробно рассмотрены зоны ответственности для каждой из ролей. Сводная таблица с данной информации представлена в приложении А.

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

Зона ответственности включает следующие задачи:

· управляет процессом разработки с целью получения готового продукта в отведенные сроки;

· регулирует взаимоотношения и коммуникацию внутри проектной группы;

· следит за временным графиком проекта и готовит отчетность о его состоянии;

· разрабатывает, поддерживает и исполняет сводный план задач и календарный график проекта.

Архитектор

Зона ответственности включает следующие задачи:

· формулирует спецификацию решения и разрабатывает его архитектуру;

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

Разработчик

Зона ответственности включает следующие задачи:

· оценивает необходимые время и ресурсы на реализацию каждого элемента разрабатываемого продукта;

· разрабатывает или контролирует разработку элементов;

· подготавливает продукт к внедрению, если разрабатываемое решение планировалось внедрять в стенах университета;

· консультирует команду по технологическим вопросам.

Тестировщик

Зона ответственности включает следующие задачи:

· обеспечивает обнаружение всех дефектов разрабатываемого продукта;

· разрабатывает стратегию и планы тестирования;

· осуществляет тестирование.

Аналитик

Зона ответственности включает следующие задачи:

· организует работу с поставленными научным руководителем требованиями;

· определяет компромиссы, относящиеся к удобству использования и функциональным требованиям программного продукта;

· определяет требования к разрабатываемому решению;

· определяет компромиссы между параметрами “функциональные возможности продукта / время / ресурсы”;

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

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

Таблица 1.1. Совмещение ролей в проектной команде

	Архитектор	Менеджер проекта	Аналитик	Разработчик	Тестировщик
Архитектор		Нет	Да	Да	Не желательно
Менеджер проекта	Нет		Не желательно	Нет	Да
Аналитик	Да	Не желательно		Нет	Не желательно
Разработчик	Да	Нет	Нет		Нет
Тестировщик	Не желательно	Да	Не желательно	Нет

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

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

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

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

Матрица ответственности включает в себя следующие элементы [5, 6]:

1. Основные работы проекта.

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

2. Группы и роли внутри проектнои? команды.

По горизонтали в матрице перечисляются группы и роли проектнои? команды.

3. Полномочия членов команды.

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

В таблице ниже приведены основные условные обозначения полномочий ролей для матрицы ответственности [6, 7]:

Таблица 1.2. Условные обозначения матрицы ответственности

Обозначение	Расшифровка	Описание
И. (R)	Исполнитель (Responsible)	Несет ответственность за непосредственное исполнение задачи.
О. (A)	Ответственный (Accountable)	Полностью отвечает за выполнение задачи и вправе принимать решения по способу ее реализации.
К. (C)	Консультант (Consulted)	Согласует принимаемые решения, консультирует членов команды.
Н. (I)	Наблюдатель (Informed)	Его информируют об уже принятом решении.

Разработанная матрица ответственности представлена на таблице ниже:

Таблица 1.3. Матрица совместимости

	Заказчик	Менеджер проекта	Аналитик	Архитектор	Разработчик	Тестировщик
Формирование требований
Уточнение задания у научного руководителя	К	О	И
Поиск и анализ документации по смежным проектам	К	О	И
Формирование списка первоначальных требований		О	И	Н	Н	Н
Организация работы по разработке
Создание и модификация календарного плана работ		О
Описание архитектуры программного продукта		Н	К	О	Н	Н
Формирование списка требований и задач для разработки на каждом спринте		О	И		Н	Н
Разработка программного продукта
Распределение текущих задач между разработчиками		Н	К		О
Реализация текущих задач			Н		О	К
Тестирование программного продукта			Н		К	О
Документирование текущего результата		Н	О		И	И
Работа с заказчиком
Демонстрация текущей версии программного продукта	Н	О	И	Н	Н	Н
Уточнение отдельных вопросов	К	О	И	Н	Н	Н

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

1.3 Обзор предлагаемого подхода к разработке ПО в рамках учебных проектов в НИУ ВШЭ - Пермь

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

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

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

1.3.1 Использование гибкой методологии Scrum при ведении учебных проектов

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

Ценности методологий Agile могут быть напрямую применены к Скраму. Они включают в себя следующие принципы [9]:

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

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

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

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

Методология Scrum включает в себя три важных артефакта: Бэклог Продукта, Спринт Бэклог и Инкремент Продукта [9].

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

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

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

Scrum - команда включает в себя три роли: владелец продукта, скрам мастер и посредственно сами члены команды разработки [6, 7, 8].

Скрам Мастер - является одним из членов команды и отвечает за успех Scrum в проекте [10]. Следует отметить, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера:

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

· Определение открытых вопросов в проектах, доведение информации о различных проблемах до всех участников проектной группы.

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

· Координация работы команды.

· Помощь команде в проведении планирования каждого спринта и их запуска.

Владелец продукта - это человек, отвечающий за разработку продукта. Его основной задачей является принятие окончательных решений для команды в проекте [10]. Его обязанности включают в себя:

· Формирование единого видения конечного программного продукта для всех участников проектной группы.

· Ведение бэклога продукта, включая обозначение приоритетов задач и определение основных задач на следующие спринты.

· Предоставление понятных и тестируемых требований команде разработчиков.

· Взаимодействие с командой разработки и заказчиком.

· Приемку кода в конце каждого спринта.

Таким образом, владелец продукта ставит задачи всей команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта [10].

Команда разработчиков является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению определенного владельцем продукта объема работ на текущий спринт. При этом, работа команды оценивается как работа единой группы [10]. В методологии Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды включают в себя:

· Оценку трудоемкости текущих и планируемых задач.

· Принятие решений по дизайну продукта и технологическими аспектами в его разработке.

· Разрабоку программного продукта.

· Отслеживаие прогресса по текущим задачам.

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

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

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

Общий процесс разработки программного продукта с точки зрения методологии Scrum схематически отображен на рисунке ниже:

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

· все задачи беклога должны быть оценены командой разработчиков;

· самые важные элементы бэклога должны быть уточнены и понятны всеи? команде и владельцу продукта;

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

Основным результатом планирования спринта является беклог спринта - список задач, которые команда планирует реализовать в рамках спринта [11]. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов беклога (объем работ), которые она может реализовать. Таким образом, планирование спринта завершается, когда у команды разработчиков имеется общее понимание количества и сложности работы, которая должна будет быть завершена в следующии? спринт.

Рисунок 1.1. Процесс разработки ПО согласно методологии Scrum

Обзор спринта - показ владельцу продукта и заинтересованным лицам (в данном случае, научному руководителю) работающего функционала продукта, сделанного за спринт [11]. Основная задача проведения обзора спринта заключается в получении обратнои? связи, а общии? цикл ее получения выглядит следующим образом:

Основнои? мерои? прогресса по проекту, согласно принципам Agile, является функционал разработанного продукта, поэтому показывать на демонстрации заказчику (научному руководителю) надо именно программу, ведь только так можно получить качественную обратную связь. При этом в обзоре спринта желательно должна принимать участие вся команда.



Рисунок 1.2. Получение обратной связи в Scrum

В долгосрочном плане ретроспективы являются самои? важнои? практикои? Scrum, так как именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкии? фреи?мворк для управления проектами [11]. Ретроспективуа традиционно проводится после обзора спринта спустя небольшое количество времени, чтобы можно было оперативно обсудить результаты работы.

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

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения нужно реализовывать?

Команда должна обязательно в том или ином виде составить план улучшении? для контроля их исполнения [11].

Ключевыми моментами в процесса разработки ПО с точки зрения методологии Scrum являются спринты и скрам - митинги.

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

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

1.3.2 Использование инструментов сетевого планирования при ведении учебных проектов

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

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

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

· Временной анализ проекта. С помощью сетевых моделей осуществляют расчет временных параметров проекта: ранние и поздние сроки выполнения работ, отдельных задач и всего проекта, резервы времени, определяются критические участки работы и критические пути их осуществления [12].

· Ресурсный анализ проекта. Используя календарный план, определяется количество и сроки расходования ресурсов [12].

· Распределение ресурсов. Методы распределения ресурсов позволяют:

o при неизменном сроке завершения проекта минимизировать различие между графиком возникновения потребностей в ресурсах и графиком их поступления;

o при неизменном уровне текущих ресурсов минимизировать срок завершения проекта;

o решить смешанную задачу: когда ресурсы и сроки одних частей проекта остаются неизменными, тогда как ресурсы и сроки других частей минимизируются.

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

Наиболее распространенным инструментом сетевого планирования является Microsoft Project. При этом следует отметить, что у НИУ ВШЭ имеется партнерское соглашение с компанией Microsoft, что позволит студентам пользоваться лицензионной версией данного программного продукта для работы над учебными проектами. Кроме того, в MS Project поддерживается интеграция с Team Foundation Server, что позволит оперативно отслеживать все задачи по проекту и соответствующие им программные решения. Более подробно использование TFS в работе над учебными проектами будет рассмотрено далее.

1.3.3 Использование инструмента TFS при ведении учебных проектов

Помимо этапа разработки ПО, также немаловажным являются этапы накопления и передачи знаний, а также взаимодействия членов проектной команды.

На сегодняшний момент известно, что в ближайшее время планируется внедрение Microsoft Team Foundation Server в стенах университета для учебных целей. Данный инструмент может быть использован в разрабатываемой модели в качестве средства коммуникации всех членов внутри проектной команды, а также для хранения документации и исходных кодов для дальнейшей доработки в случае, когда один крупный проект разбивается на несколько отдельных студенческих проектных групп.

Таким образом, с использованием данного продукта члены команды смогут отслеживать отдельные процессы разработки ПО, управлять инфраструктурой тестирования и различными программными продуктами проекта, а также осуществлять эффективные коммуникации между собой [13]. Microsoft Team Foundation Server поддерживает практики гибкой разработки ПО [13], включая Agile методологии, конкретно - Scrum, элементы которого планируется использовать в разрабатываемой модели.

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

· Интеграция с современными средствами разработки от Microsoft. Включая использование Visual Studio для разработки приложений на различных языках программирования, а также MS Project для организации планирования работ по проекту.

· Использование Agile-практик в планирования и в совместной работе. Платформа TFS позволяет адаптировать agile-практики под нужды каждого проекта, используя готовые шаблоны для Scrum, Agile или собственные. Кроме того TFS поддерживает Kanban доски и средства сбора обратной связи. Все участники, вовлеченные в проект, интегрируются в единое пространство.

· Управление версиями. Технология версионного контроля аналогична SVN и обладает всеми необходимыми функциями.

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

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

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

· Кастомизация под нужды каждого проекта [13].

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

Успех групповых проектов разработки ПО обеспечивает сочетание многих элементов, процессов и ролеи? [14]. Основными процессами являются:

§ Процесс разработки ?компонентов.

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

§ Процесс управления проектом.

?Следующая диаграмма иллюстрирует отношения между типовыми процессами коллективнои? разработки ПО и тем, как может использоваться Team Foundation Server для обеспечения единообразнои? фундаментальнои? поддержки этих инициатив [14]: ?



Рисунок 1.3. Использование TFS

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

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

Ниже представлен пример логическои? реализации Team Foundation Server с точки зрения наиболее типичных ролеи? в разработке ПО и жизненном цикле разработки [14]:



Рисунок 1.4. Логическая реализация TFS

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

Если говорить о разворачиваемом в стенах университета наборе компонентов TFS, известно, что он будет включать следующий функциональный набор:

· Система управления инцидентами.

· Система управления требованиями.

· Система управления программной документацией.

· Система управления планами работ.

· Система управления репозиторием архитектур.

· Система управления репозиторием кода.

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

1.4 Резюме обзорной части

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

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

В первую очередь в команде должны быть определены роли её участников и соответствующие сферы ответственности. Роли и ответственности участников типового проекта разработки ПО были подробно рассмотрены ранее и представлены в приложении А. Их все можно условно разделить на пять групп:

· Анализ. Включает задачи по формированию, документированию и сопровождению требовании? к продукту.

· Управление. Включает задачи по определению и управлению производственными процессами, координации работы команды.

· Производство. Включает задачи по проектированию и разработке ПО.

· Тестирование. Включает задачи по тестированию ПО.

· Обеспечение. Включает задачи по поддержанию эффективного рабочего процесса, а также доведению информации о различных проблема до всех участников команды.

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

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

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

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

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

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

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

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

2.1 Описание бизнес-процесса «как есть»

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

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

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

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