Система управления проектами территориально-распределенной IT-компании

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

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

Введение

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

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

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

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

Целью данного дипломного проекта является проектирование и разработка Web-приложения «Система управления проектами территориально-распределенной IT-компании».

Для реализации поставленной цели необходимо выполнить ряд задач:

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

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

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

спроектировать и разработать Web-приложение «Система управления проектами территориально-распределенной IT-компании».



1.Обзор систем управления IT-проектами и патентный поиск

1.1 Краткая история управления проектами

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

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

Одним из основоположников современной теории управления проектами считается Генри Гант (Henry Gantt, 1861-1919) -- американский инженер, предложивший в 1910 году новую технику календарного планирования с использованием горизонтальных диаграмм. Диаграммы, включая отрезки задач и маркеры вех, показывают последовательность и продолжительность всех задач в процессе. В последствие диаграмма Ганта стала инструментом де-факто, а изобретателю присвоили звание «отца техники планирования». Диаграмма Ганта оказалась настолько серьезным аналитическим инструментом, что на протяжении почти ста лет не претерпевала изменений. И только в 1990-х годах для более подробного описания зависимостей между задачами были добавлены связи.

Француз Анри Файоль (Henri Fayol, 1841-1925) -- создатель классической теории управления. Известен тем, что определил пять основных функций менеджмента, ставших основой управления проектами.

Работы автора «научного менеджмента», Фредерика Уинслоу Тейлора (Frederick Winslow Taylor, 1856-1915), стали прототипами многих современных инструментов, включая иерархическую структуру работ (WBS).

В 50-х годах прошлого столетия проектный менеджмент окончательно сформировался как отдельная область знаний. В эти годы появились две основных математических модели управления расписанием проектов - метод критического пути и метод анализа и оценки программ PERT. Метод критического пути появился благодаря трудам специалистов корпораций «Дюпон» и «Ремингтон Рэнд», работавших над проектами по ремонту оборудования заводов «Дюпон».

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

ВМФ США - разработкой баллистической ракеты «Поларис» компанией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» был создан метод планирования работ на основании оптимальной логической схемы процесса, названный методом анализа и оценки программ.

Эти успешные и эффективные методики быстро распространились среди частных компаний запада.

В 1969 году в США появилась профессиональная некоммерческая организация, представляющая интересы индустрии управления проектов - Институт управления проектами (PMI). В 1981 в PMI началась подготовка документа, излагающего методологические основы управления проектами, - «A Guide to the Project Management Body of Knowledge» (PMBOK Guide). Пробный вариант руководства стал доступен в 1987 году, а первая редакция опубликована в 1996-м. Сегодня стандарт PMBOK широко признается во всем мире и является международным де-факто.

В 1967 году в Европе основана Международная ассоциация управления проектами International Project Management Association (IPMA), которая создала квалификационный стандарт (профессиональные требования) к деятельности специалистов по управлению проектами IPMA Competence Baseline (ICB). В 2006 году вышла третья версия требований.

В настоящее время PMI и IPMA принимают активное участие в разработке ISO стандарта по управлению проектами [1].

Управление проектами продолжает свое. Возникли две значимые тенденции.

Планирование "снизу вверх". В этой тенденции основной упор делается на простую структуру проекта, сокращение цикла проекта, эффективную совместную работу в группе, более глубокое вовлечение членов рабочей группы и принятие решений. Эта тенденция широко известна как динамичное управление проектами, и она включает связанные методики, такие как Scrum, Crystal, Extreme Programming, Unified Process и т. д.

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

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

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

Управление проектами - это применение методов, инструментов, техник и компетенцией к проекту. Управление проектами включает интеграцию различных фаз жизненного цикла проекта [3].

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

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

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

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

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

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

планирование различных событий, зависящих друг от друга;

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

расчет времени, необходимого на решение каждой из задач;

сортировка задач в зависимости от сроков их завершения;

управление нескольким проектами одновременно;

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

управление данными и предоставление информации

Программное обеспечение для управления проектами предоставляет большое количество требуемой информации, такой как:

список задач для сотрудников и информацию распределения ресурсов;

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

ранние предупреждения о возможных рисках, связанных с проектом;

информации о рабочей нагрузке;

информация о ходе проекта, показатели и их прогнозирование.

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

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

Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех -- цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.

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

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

Обзор прототипов

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

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

Существует большое количество систем управления проектами разных типов:

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

Microsoft Project;

Open Workbench;

OpenProj;

Cerebro - многопользовательское ПО для управление медиа проектами;

GanttProject;

KPlato - приложение для управления проектами под ОС Linux;

TaskJuggler.

многопользовательские системы управления - предназначены для координации действий нескольких десятков или сотен пользователей. Обычно строятся по технологии клиент-сервер[5]. К многопользовательским системам относятся:

Easy Projects .NET;

OpenProj;

ProjectMate;

Project Kaiser;

Redmine;

Trac;

TeamLab;

Wrike.

Web-based - Web-приложения. К ним относятся:

Мегаплан;

Worksection;

Teamer;

Basecamp;

Bontq;

Easy Projects .NET - многофунциональная (Enterprise) система управления проектами;

Kommandcore - веб-сервис для командного управления проектами;

Project Kaiser.

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

Программное средство управления проектами Microsoft Project

Программа управления проектами, разработанная и продаваемая корпорацией Microsoft.

Microsoft Project создан, чтобы помочь менеджеру проекта в разработке планов, распределении ресурсов по задачам, отслеживании прогресса и анализе объёмов работ. Microsoft Project создаёт расписания критического пути. Расписания могут быть составлены с учётом используемых ресурсов. Цепочка визуализируется в диаграмме Ганта [6].

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

Все данные о проекте в Microsoft Office Project хранятся в двух наборах данных. Первый содержит данные о задачах, а второй - данные о ресурсах. Эти наборы данных содержат множество полей с полным перечнем параметров задач и ресурсов.

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

Наиболее очевидными преимуществами продукта являются следствием того, что он входит в семейство Microsoft Office. Это обеспечивает следующие плюсы характерные для всех продуктов MS Office:

такое же малое время обучения пользователей, как с остальными программами Microsoft Office;

богатые возможности по настройке в стиле формул Microsoft Excel (сам продукт выдержан в интерфейсе максимально приближенном к Microsoft Excel);

возможность адаптировать продукт под свою специфику путем программирования или покупки готовых решений созданных на базе Visual Basic или Microsoft.Net.

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

Microsoft решает данную проблему надежности Microsoft Project Server с помощью целого набора программ:

через программу Microsoft ISV Royalty партнерам и клиентам компенсируется часть стоимости по усиленной технической поддержке решения;

Microsoft приглашает сильнейших экспертов из клиентов и партнеров, в том числе и в первую очередь критически настроенных к качеству Microsoft Project Server, принять участие в программе его разработки и тестировании Microsoft Technology Adoption Program;

Microsoft выдает наградные статусы экспертам по продукту, которые соглашаются бесплатно консультировать по инцидентам поддержки на форумах. Сервис бесплатной форумной консультации Microsoft обеспечивает через программу "Наиболее ценный специалист"(Microsoft MVP).

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

Программное обеспечение по управлению проектами Open Workbench

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

Составление проекта, как правило, начинается с формирования базы ресурсов; в Open Workbench ресурсом могут быть человек, оборудование, материал или статья расхода (это особенно удобно при использовании в работе outsource-специалистов, которые не являются непосредственными участниками команды). Пользователям предлагается строить свои проекты из активностей (activities), фаз (phases), заданий (tasks) и майлстоунов (milestones, этот термин обозначает важную точку в проекте).

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

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

Философия Open Workbench заключается в том, чтобы предоставить пользователям бесплатную альтернативу Microsoft Project, которая в будущем превзойдет ее по функциональности.

Microsoft Project базово ориентируется на задания, а Open Workbench упор делает на ресурсы, и это определяет идеологию этих двух продуктов. В Microsoft Project график строится на основе Работы (Work), а в Open Workbench - на основе Продолжительности (Duration). Другими словами, планирование в Open Workbench завязано на доступности тех или иных ресурсов. Microsoft Project имеет несколько иной подход: он имеет собственную систему распределения ресурсов, которая зачастую дает сбой, и пользователю приходится вручную определять время работы по каждому заданию [7].

Система отслеживания ошибок Atlassian JIRA

Atlassian JIRA - коммерческая система отслеживания ошибок, предназначена для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. Разработана компанией Atlassian Software Systems. Платная. Имеет веб-интерфейс. Название системы (JIRA) было получено путём модификации названия конкурирующего продукта - Bugzilla. JIRA создавалась в качестве замены Bugzilla и во многом повторяет архитектуру Bugzilla [9]. Это система для коллективной работы с задачами в рамках бизнес-процесса или проекта. Система позволяет работать с несколькими проектами, разбивать их на этапы, настраивать любые типы задач, связывать задачи между собой, назначать ответственных по различным направлениям, настраивать роли участников проектов, легко формировать отчеты, и многое другое.

Работа в JIRA происходит через Web-браузер, установка JIRA на рабочих местах не требуется [9]. Возможности JIRA:

система масштабируема и подходит как для организаций с небольшим количеством сотрудников (менее 10 человек), так и для более крупных предприятий (до 200 человек);

возможность отслеживания проблем проекта и хода исполнения;

поддержка и сервисное обслуживание проекта;

управление ходом исполнения каждой задачи;

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

рабочие процессы / Управление процессами.

Система платная. Цена зависит от количества пользователей: от 50 у.е. в месяц (11-15 пользователей) до 1000 у.е в месяц (501-2000 пользователей) [9].

1.2 Web-приложение для управления проектами Redmine

Открытое серверное веб-приложение для управления проектами и отслеживания ошибок. Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails [10].

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

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

Пользователям назначается роль в каждом проекте, в котором он участвует, например «менеджер в проекте по разработке сайта А», «разработчик в проекте по поддержанию интранета компании» или «клиент в проекте по рефакторингу информационной системы компании Б». Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.

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

Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool), представлявшим каждая в отдельности один проект.

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

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

Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» -- актуальные, а «закрыт», «отклонен» - нет).

Для каждого проекта отдельно определяются набор этапов разработки и набор категорий задач. К задачам имеется возможность прикреплять файлы (имеется отдельная сущность «Приложение»).

За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Измененный параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.

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

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

Система поддерживает учет затраченного времени благодаря сущности «Затраченное время», связанной с пользователями и задачей. Сущность позволяет хранить затраченное время, вид деятельности пользователя (разработка, проектирование, поддержка) и краткий комментарий к работе. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоемкости и стоимости разработки.

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

Уведомления пользователей об изменениях, происходящих на сайте, осуществляется с помощью сущности «Наблюдатели», связывающей пользователей с объектами различных классов (проекты, задачи, форумы и др.). В базе данных хранятся также ключи доступа к подписке RSS, позволяющие получать уведомления посредством этой технологии, также уведомления рассылаются с помощью электронной почты [11].

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

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

Если пользователь Redmine получил доступ к проекту, то сейчас нельзя ограничить его активность какими-то отдельными типами задач (трекерами). Например, нельзя разрешить просматривать или создавать задачи только какого-то определенного типа.

В Redmine не реализовано делегирование задач -- нельзя передать задачу другому исполнителю, отметив, что задача должен исполнять он, но оставив себе наблюдение за задачей [10].

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

Trac - средство управления проектами и отслеживания ошибок в программном обеспечении.

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

Trac использует минималистичный веб-интерфейс, основанный на технологии Wiki, и позволяет организовать перекрёстные гиперссылки между базой данных зарегистрированных ошибок, системой управления версиями и вики-страницами. Это даёт возможность использовать Trac в том числе и как веб-интерфейс для доступа к системе контроля версий Subversion и Git, а также, через плагины, к Mercurial, Bazaar и другим.

Поддерживаются базы данных SQLite, PostgreSQL, MySQL и MariaDB [12].

Основные функции:

управление проектом, разделение проекта на этапы (milestones);

контроль выполнения (roadmap);

все изменения по проекту заносятся на временную шкалу (timeline);

поддержка rss;

Tickets;

учет ошибок, замечаний, пожеланий с возможностью фильтрации и занесение соответственно в milestone, roadmap;

просмотр репозитория;

управление пользователями;

встроена система WiKi с возможностью делать ссылки на milestone, roadmap, ticket.

Функциональность может быть расширена за счет дополнительных модулей. Система бесплатна, поддерживает множество языков [13].

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

Система управления бизнесом - Мегаплан

Мегаплан (компания) - один из лидеров среди SaaS-провайдеров на российском рынке. Был создан в 2006 году Михаилом Уколовым и Михаилом Смоляновым.

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

Компания в первую очередь ориентируется на малый и средний бизнес, на организации (или подразделения организаций), численностью до 300 человек [14].

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

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

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

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

Конструктор отчетов - создание отчетов, используя широкие возможности конструктора в Мегаплане. Выгрузка отчета в "Эксель", возможность отправлять пo почте или распечатать.

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

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

Синхронизация с 1С. Легкий импорт и экспорт данных об операциях.

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

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

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

Патентный поиск

Был проведен патентный поиск в информационно-поисковых системах по базам данных объектов промышленной собственности патентных бюро Республики Беларусь и Российской Федерации. По результатам анализа проведенного патентного поиска дано заключение об отсутствии сравнимых по характеристикам аналогов программных средств как на территории Республики Беларусь, так и на территории Российской Федерации.

Из результатов поиска был выбран прототип программного средства из патентной базы Российской Федерации. Патент № 2480830 на изобретение «Способ автоматизированной обработки данных для принятия управленческих решений по проекту и портфелю проектов» имеет индекс МПК G06Q50/10, является действующим по данным на 27.05.2013. Страна - Российская Федерация, авторы изобретения: Штернлиб Теймур Томазиевич, Мирецкая Екатерина Александровна. Патентообладатель - Закрытое акционерное общество "Торговый Дом «ПЕРЕКРЕСТОК». Техническим результатом является расширение функциональных возможностей и ускорение обработки информации. Способ осуществляется на автоматизированной системе, состоящей из сервера, снабженного программным обеспечением, по меньшей мере, одной рабочей станции ввода данных и, по меньшей мере, одной рабочей станции экспертов, связанных между собой сетью. Сервер формирует на устройствах отображения информации этих рабочих станций различные поля диалоговых окон для пяти этапов - «Идея», «Оценка», «Выбор», «Определение», «Выполнение». Для каждого этапа вводятся соответствующие данные, производится их экспертная оценка, в результате сравнения которой с пороговым значением переходят к следующему этапу, или дорабатывают этап, или завершают проект. Сервер сохраняет информацию, полученную от рабочих станций.

Вывод

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

Эффективная система управления проектами является свидетельством зрелости, уровня организации и дает следующие преимущества:

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

унифицированные подходы к управлению проектами позволяют работать не только над отдельными проектами, но и программами (мультипроектами), включающими в себя множество составляющих проектов, получить картину ("big picture") состояния всех проектов предприятия, независимо от того, как и какой менеджер управляет конкретным направлением;

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

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

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

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



2. Постановка задачи и выбор средств разработки

2.1 Основные технические требования

управление проект территориальный приложение

Целью дипломного проекта является разработка программного средства, представляющего собой Web-приложение, организующее совместную работу над одним проектом сотрудников, территориально удалённых друг от друга. Так же система должна поддерживает роль администратора, который отвечает за регистрацию сотрудников, дополнение новых элементов в систему; роль клиента и менеджера проекта. Менеджер определяет параметры проекта (срок выполнения, бюджет, количество этапов, задач) и состав разработчиков; клиент имеет право на добавление заказа, просмотра хода выполнения заказа, корректировки плана, просмотр и корректировка личных данных. Каждый сотрудник отвечает за выполнение поставленных задач, корректирует статус их выполнения, может просматривать и корректировать личные данные.

Для реализации поставленной цели использовался язык программирования С#, поддерживающий платформу Microsoft .Net Framework 4.0; технология ASP.NET, интерфейс Membership API . Среда разработки Microsoft Visual Studio 2010 Express. Для осуществления хранения данных использовалась база данных, созданная в системе управления базами данных Microsoft SQL Server 2008.

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

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

Группа стандартов, применимых к отдельным объектам управления

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

ISO 10006:2003. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов.

Данный международный стандарт сам по себе не является руководством по УП. В нем приведены руководящие указания по качеству процессов УП. В стандарте приводятся основные принципы и практические методики, которые влияют на качество разработки и реализации проектов. В нем процессы по проекту сгруппированы в две категории: процессы УП и процессы, связанные с продуктом проекта (т.е. такие, как проектирование, производство, проверка).

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

В основе руководящих указаний по менеджменту качества при проектировании, содержащихся в данном международном стандарте, лежат восемь принципов менеджмента качества [17]:

ориентация на потребителя;

лидерство руководителя;

вовлечение работников;

процессный подход;

системный подход к менеджменту;

постоянное улучшение;

принятие решений, основанное на фактах;

взаимовыгодные отношения с поставщиками.

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

PMI. А Guide to the Project Management Body of Knowledge (РМВОК Guide). Руководство к своду знаний по управлению проектами.

PMBOK Guide является американским национальным стандартом УП и широко используется в мире. В основу стандарта положена процессная модель описания деятельности по УП. В качестве основных целей разработки Руководства называют унификацию терминологического пространства и использование данного документа в качестве базового справочного пособия для сертификации профессионалов по управлению проектами (РМР).

В Руководстве определяются:

структура УП (основные сведения об УП, основные термины и общий обзор глав Руководства);

описание пяти групп управленческих процессов (инициация, планирование, организация исполнения, контроль, завершение);

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

Кроме того, PMI разрабатывает стандарты, связанные с отдельными методиками УП. На сегодняшний день выпущены стандарты, регламентирующие методы разработки иерархической структуры работ проекта и контроля по методу освоенного объема (Practice Standard for Work Breakdown Structures, Practice Standard for Earned Value Management) [16].

PRINCE2 (Projects in Controlled Environments)

Разработан в Государственном департаменте коммерции в Великобритании.

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

Относительно новая область стандартизации - процессы управления такими объектами, как программа и портфель проектов. Однако стандартов международного уровня в данной области до последнего времени не существовало. На роль общепризнанных могут претендовать стандарты, выпущенные PMI в 2006 г.: The Standard for Program Management и The Standard for Portfolio Management. Данные стандарты также построены по процессному принципу [16].

Группа стандартов, определяющих требования к квалификации участников управления проектами

Среди стандартов, определяющих требования к компетенции менеджера проекта, можно выделить Международные требования к компетенции специалистов по УП (ICB), разработанные Международной ассоциацией управления проектами IPMA (Швейцария), и Руководство по развитию компетенций менеджера проекта (ProjectManager Competency Development Framework), разработанное PMI на базе структуры и процессов PMBОK Guide. В настоящее время международной инициативной группой профессионалов в области проектного менеджмента завершается разработка еще одного стандарта оценки квалификации менеджеров проектов на основании достигнутых результатов - Global Performance Based Standards for Project Management Personnel [16].

Международные требования к компетенции менеджеров проектов, а также основанный на них российский национальный стандарт, выпущенный Российской ассоциацией УП СОВНЕТ, определяют требования к знаниям и квалификации специалистов, а также к процессу их сертификации по четырем уровням квалификации в области проектного менеджмента:

специалист по проектному менеджменту;

менеджер проекта;

ведущий менеджер проекта;

директор программы.

Содержат три группы взаимосвязанных элементов знаний, включающие:

20 технических элементов знаний, относящихся к содержанию проектного менеджмента;

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

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

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

элементы технической компетенции;

элементы поведенческой компетенции;

элементы контекстуальной компетенции.

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

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

Пионером в этой области является стандарт, разработанный Ассоциацией инновационного развития и управления проектами Японии, P2M (Program and Project Management for Innovation of Enterprises).

Наибольшую популярность в мире сегодня приобретает стандарт OPM3® (Organizational Project Management Maturity Model), разработанный PMI.

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

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

OPM3® Organizational Project Management Maturity Model.

В конце 2003 г. PMI выпустил модель зрелости организационного управления проектами OPM3 (Organizational Project Management Maturity Model), которая изначально позиционировалась как между народный стандарт в данной области.

По определению PMI, организационное УП - это систематичное управление проектами, программами и портфелями проектов, направленное на достижение стратегических целей компании. Это использование знаний, навыков, инструментов и техник в проектной деятельности организации для достижения стратегических целей через реализацию проектов [16].

Основное назначение OPM3:

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

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

Новый стандарт PMI предусматривает комплексный подход к описанию системы УП в организации на разных уровнях управления - от отдельного проекта и программы до портфеля проектов.

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

Основные методы разработки программного обеспечения

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

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

Каскадная разработка или модель водопада

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

Рисунок 2.1 - Внешний вид диаграммы каскадной модели

Классическая водопадная модель включает следующие области:

разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту;

анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.;

реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.

тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации;

развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию [18].

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

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

Такой подход хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО [18].

Однако практика показала следующие недостатки этого процесса:

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

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

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

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