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

Реферат за темою випускної роботи

Зміст

Вступ

Під впливом стрімкого процесу комп'ютеризації світового співтовариства, неухильно зростає кількість фізичних і юридичних осіб, які застосовують різноманітні електронні технічні пристрої, автоматизовані мережі і системи для створення, обробки і передачі документованої інформації. На зміну паперовим технологіям приходять так звані «Безпаперові», засновані на використанні засобів електронно-обчислювальної техніки та електрозв'язку, одним з продуктів яких є електронні документи. Вони стали повсюдно і широко застосовуватися в багатьох сферах діяльності [6].

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

Здатність прийняти вірне рішення і вчасно відреагувати на ситуацію, залежить не тільки від таланту і досвіду керівників. Ефективність управління підприємством залежить і від того, наскільки розумно в ньому організовано управління процесом роботи. Малоефективне використання накопиченої інформації або ж відсутність її систематизації може привести до втрати гнучкості управління і, як наслідок, втрати ефективності виробництва. Адже вчасно не отримана інформація або документ, не проаналізована зміна ситуації, і як наслідок, не поставлена вчасно завдання – це, перш за все, втрачені гроші, час і втрачені можливості.

Але керівникам потрібно бути обережним, впроваджуючи в свій бізнес подібні системи, адже серед величезної кількості пропозицій далеко не все можуть підійти окремо взятій фірмі.

1. Актуальність теми

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

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

2. Мета і завдання дослідження, плановані результати

Метою дослідження є розробка власних підходів та алгоритмів в області систем управління проектами.

Основні завдання дослідження:

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

Об'єкт дослідження : системи управління проектами.

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

В рамках магістерської роботи планується отримання актуальних наукових результатів за наступними напрямками:

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

3. Огляд досліджень і розробок

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

Система управління проектами як правило реалізує одну з методологій розробки ПЗ. Використовує її терміни та реалізовує стандартні для даної методології підходи.

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

3.1 Огляд міжнародних джерел

Pivotal Tracker – це цікавий і зручний інструмент для спільної роботи над софтверними проектами. Загальний вид трекера представлений на рисунку 1.

Работа в Pivotal Tracker

Рисунок 1 – Загальний вид трекера Pivotal Tracker

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

У кожного завдання є коментарі, так що менеджер і виконавець можуть обговорити всі незрозумілі деталі. Сповіщення про відповідях приходять на 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 і буде підтримувати систему, тому що вона є досить нестабільною.

Вважається, що безкоштовна продукція завжди буде відставати по стабільності. В даному випадку слід визнати, що це так. Це досить великий недолік системи, так як передбачає додаткову статтю витрат для компанії. Якщо проект розрахований на тривалий період, змінити систему може призвести до втрати цінної інформації, користуватися нестабільною системою – ризик і можливо зайва втрата часу для команди [10].

Оскільки час розробників в рази ценней будь-якої системи управління, варто звернути увагу і на інші безкоштовні системи. На закінчення огляду варто відзначити, що якість системи управління – не єдиний фактор, що впливає на швидкість розробки. Важливо знати і використовувати по максимуму всі можливості системи. Тоді менеджер отримає максимальний ефект, від використання трекера.

3.3 Огляд локальних джерел

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

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

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

Проблема експертного управління об'єктів, в яких відсутня чітка формалізація, широко висвітлена в публікації В.А. Резніков і Е.А. Пряничникова [4].

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

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

  1. Слід відмовитися від усього зайвого. Дуже часто система використовується тільки на незначну частку. Невикористаний функціонал тільки ускладнює роботу з системою
  2. Частина параметрів, які задаються, наприклад, при додаванні завдання, буде проігнорована внаслідок людського фактора. Отже, слід прибрати все, що буде непридатне в реальній роботі. Якщо очевидно, що небудь використовується формально і буде порушено, це слід прибрати з проекту.
  3. Система повинна володіти функціоналом, який забезпечить покриття всього процесу. Це означає, що при використанні системи для управління проектом, не має навіть дуже малої частини процесу вестися поза цією системи.

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

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

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

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

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

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

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

Стадії, які проходить завдання від її постановки до закриття показані на рисунку 5.

Діаграмма станів завдання на трекері PivotalTracker

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

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

Цілком можливо, що в ряді випадків подібна інформація про співробітників буде марна. Причин цьому може бути багато. Навіть очевидно, що в більш ніж половині випадків подібні підказки будуть малоефективні. Але основна ідея полягає в тому, що навіть якщо певні функції виявляться незатребуваними, це ніяк не завдасть шкоди процесу, через нульовi витрати на отримання цієї інформації.

Висновки

Для компанії, що займається розробкою ПЗ немає необхідності у великій ERP-системі. Для ведення розробки цілком достатньо гарної системи управління проектами, яка також могла б замінити паперову роботу, що ведеться попутно [9-10].

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

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

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

Після аналізу низки систем, які взяли за основу різні методології, можна зробити наступний висновок. Ідеальною програми для автоматизації управління проектами, що задовольняє всім без винятку вимогам підприємства не існує. Але шляхом додавання елементів аналітики в розроблювану систему, можна дати можливість аналізувати фактичні показники і вносити своєчасну корекцію в хід робіт, накопичувати, аналізувати і використовувати в подальшому досвід реалізованих проектів. Таким чином, наступним кроком в системах управління проектами повинно стати додавання інструментів аналізу для проектного менеджера.

Магістерська робота присвячена актуальній побудова системи для управління розробкою програмного забезпечення У рамках проведених досліджень виконано:

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

Подальші дослідження спрямовані на наступні аспекти:

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

При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: січень 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.