ДонНТУ   Портал магистров

Реферат по теме выпускной работы

Содержание

Введение

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

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

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

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

1. Актуальность темы

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

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

2. Цель и задачи исследования, планируемые результаты

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

Основные задачи исследования:

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

Объект исследования: системы управления проектами.

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

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

  1. актуальность разработки новых систем управления в наши дни;
  2. эффективность текущих систем управления в малых и средних коммандах разработчков;
  3. статистика использования методологий разработки в украинских коммандах разработчков.

3. Обзор исследований и разработок

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

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

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

3.1 Обзор международных источников

Pivotal Tracker – это интересный и удобный инструмент для совместной работы над софтверными проектами. Общий вид трекера представлен на рисунке 1.

Работа в Pivotal Tracker

Рисунок 1 – Общий вид Pivotal Tracker

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

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

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

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

У каждого пользователя Pivotal Tracker, будь-то менеджер или разработчик – свой собственный аккаунт. В этом аккаунте он видит проекты, которые создал сам или в которые его пригласили. Таким образом, менеджер может вести несколько проектов, в которых участвуют разные разработчики. А разработчик может работать в нескольких проектах с разными менеджерами [7].

Процесс добавления задачи представлен на рисунке 2.

Добавление задание в Pivotal Tracker

Рисунок 2 – Добавление задание в Pivotal Tracker

3.2 Обзор национальных источников

RedMine является бесплатной ИСУП, разработанной на Ruby on Rails. Рассмотрим далее основные достоинства системы.

  1. Приятный интерфейс, превосходит не только бесплатных конкурентов, но и некоторые платные разработки.
  2. Бесконечная иерархия задач. От существующей задачи можно всегда отделить подзадачи. Удобно на практике.
  3. Возможность добавить дочерний проект. Можно построить иерархию программы, благо в родительском проекте отображаются данные с дочерних проектов.
  4. Можно менять workflow, добавлять свои поля в issue ticket, изменять правила доступа и нотификации.
  5. Существует возможность интеграции с системами контроля версий, есть плагины для интеграции с серверами сборок.
  6. Неплохой отчет для учета времени. Даже лучше некоторых, которые есть у платных аналогов. Но существует и недостаток – проблема с экспортом.
  7. Существует большое количество плагинов, которые позволяют превратить систему в мощный инструмент управления.

Недостатков, разумеется, также достаточно. Основные из них были найдены сразу после краткого тестирования. Стоит отметить, что ввиду разных потребностей, понятие недостатков системы субъективно. Рассмотрим далее основные недостатки[7].

  1. Плагины работают крайне не стабильно. Большинство плагинов, разработанных под одну версию, не идут под следующую.
  2. В рассматриваемой системе существует проблема с экспортом данных. Даже выгрузить стандартные форматы CSV и Excel получается не всегда. Есть серьезные недоработки с экспортом русских буков в pdf.
  3. Нет никакой связки с MS Project. В таком случае затруднительно нормально планировать, учитывать утилизацию ресурсов. Некоторый функционал для планирования существует только для проформы.
  4. Все изменения workflow и issue ticket применяются ко всем проектам сразу, что не всегда нужно.
  5. Единая стандартизация управления. В случаи работы с заказчиком, у него могут быть свои требования к процессам, и тогда могут возникнуть трудности.
  6. Функционал issue трекера явно не доработан. Так как вещи вида отчета по трассировке issue, при тестировании так и не удалось. Не имеет значения, при использовании для разработки, не включая дальнейшую поддержку.

Общий вид системы представлен на рисунке 3.

работа в RedMine

Рисунок 3 – работа в RedMine

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

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

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

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

3.3 Обзор локальных источников

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

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

Агарков А.В. в своей публикации предлагает достойные алгоритмы в работе с графами [5].

Проблема экспертного управления объектов, в которых отсутствует четкая формализация, широко освещена в публикации В.А. Резников и Е.А. Пряничникова [4].

4. Разработка собственной системы управления

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

  1. Следует отказаться от всего лишнего. Очень часто система используется только на незначительную долю. Неиспользуемый функционал только усложняет работу с системой.
  2. Часть параметров, которые задаются, например, при добавлении задания, будет проигнорирована вследствие человеческого фактора. Следовательно, следует убрать все, что будет непригодно в реальной работе. Если очевидно, что что-либо используется формально и будет нарушено, это следует убрать из проекта.
  3. Система должна обладать функционалом, который обеспечит покрытие всего процесса. Это значит, что при использовании системы для управления проектом, не должно даже очень малой части процесса вестись вне этой системы.

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

  1. Планирование. На основе полученных, на предыдущем этапе (на предыдущей итерации) результатов, менеджером проекта производиться оптимальное распределение задач между сотрудниками. Система должна предложить менеджеру оптимальную балансировку, учитывая всю доступную ей информацию о сотрудниках. Распределение должно учитывать время работы сотрудника, его показатели, и уровень. Разумеется, выбор остается за менеджером. Система также должна обучаться на своих ошибках, запоминать, когда предложенные ею варианты были отклонены.
  2. Выполнение работы. Сотрудники приступают к выполнению задач, попутно обновляю статусы своих задач. Допускается изменение рабочего плана в процессе работы, снятие или же замена задач другими.
  3. Анализ. Производиться контроль результатов, сбор статистики. Статистика должна показать отклонение от запланированного графика, граничные показатели. Осуществляется подсчет гонораров сотрудников, на основе их рейта в час. Также, на основании этого анализа система на следующей итерации должна принимать участие в планировании новых задач.

Абстрактный алгоритм подсчета точности приведен на рисунке 4.

Алгоритм пересчета точности оценки сотрудника

Рисунок 4 – Алгоритм пересчета точности оценки сотрудника

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

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

Стадии, которые проходит задача от ее постановки до закрытия показаны на рисунке 5.

Диаграмма состояний задачи на трекере PivotalTracker

Рисунок 5 – Диаграмма состояний задачи на трекере PivotalTracker
(анимация: 9 кадров, 5 циклов повторения, 137 килобайт)

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

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

Выводы

Для компании, занимающейся разработкой ПО нет необходимости в крупной ERP-системе. Для ведения разработки вполне достаточно хорошей системы управления проектами, которая также могла бы заменить бумажную работу, ведущуюся попутно [9-10].

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

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

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

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

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

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

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

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

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: январь 2013 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.

Список источников

  1. Волченко Е.В. Метод формирования обучающей выборки мета-объектов // Искусственный интеллект. – 2007. – №3. – С.284-289.
  2. Волченко Е.В. Анализ эффективности выбора условий формирования обучающей выборки метаобъектов // Вестник Хмельницкого национального университета. – 2007. – № 2, Том 1: Технические науки. – С. 85-89.
  3. Волченко Е.В. Генетический алгоритм биссекции графов // Искусственный интеллект. – 2007. – №1. – С.233-237.
  4. Резников В.А., Пряничникова Е.А. Об экспертном управлении плохо формализуемыми объектами // Искусственный интеллект. – 2007 – №2. С.40-47.
  5. Агарков А.В. Поиск изоморфных пересечений двух графов за полиномиальное время // Искусственный интеллект. 2007. – No.2. – С.62-74.
  6. Электронные документы как доказательства по уголовным делам / Виталий Вехов // – Режим доступа к статье: http://www.crime–research.ru/articles/Wechov3/
  7. Pivotal Tracker – сказка для управления софтверными проектами / Н.А. Наумов // Livebusiness – 2010. – Режим доступа к статье: http: //www.livebusiness.ru/news/8817
  8. Записки PM'a о RedMine / П. Мант // LiveJournal – 2007. – Режим доступа к статье: // http://pmant.livejournal.com/18169.html
  9. Установка RedMine / П. Мант // LiveJournal – 2007. – Режим доступа к статье: // http://pmant.livejournal.com/18150.html
  10. Мухин В.А. Исследование систем управления документов / В.А. Мухин. – М.: Экзамен, 2003.