Программная реализация надстройки над системой управления проектами "YouTrack"
Изучение возможностей системы YouTrack. Аналитический обзор ее аналогов и их функциональности. Анализ требований к системе управления проектами и надстройке. Визуализация данных. Проектирование интерфейса надстройки. Определение технологий реализации.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 13.09.2017 |
| Размер файла | 2,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Оглавление
- Введение
- Глава 1. Определение и формулировка требований к надстройке
- 1.1 Scrum-методология
- 1.2 Требования к системе управления проектами
- 1.3 Требования к разрабатываемой надстройке
- 1.3.1 Delivery report
- 1.3.2 Cumulative report
- 1.4 Визуализация данных
- 1.5 Обзор систем управления проектами
- 1.5.1 YouTrack
- 1.5.2 JIRA
- 1.5.3 Team Foundation Server
- 1.5.4 Bugzilla
- 1.5.5 Сравнение представленных систем
- 1.6 Устав проекта
- 1.6.1 Описание идеи
- 1.6.2 Цель и задачи проекта
- 1.6.3 Актуальность
- 1.6.4 Возможные риски
- 1.6.5 Классификация рисков
- 1.6.6 Анализ и приоритезация рисков
- Глава 2. Проектирование надстройки
- 2.1 Проектирование извлечения данных из YouTrack
- 2.2 Проектирование интерфейса надстройки
- 2.3 Взаимодействие с системой
- Глава 3. Разработка и тестирование надстройки
- 3.1 Средства разработки и технологии
- 3.2 Результат разработки
- Заключение
- Библиографический список
- Приложения
Введение
Трудовые ресурсы составляют значительную часть затрат предприятия в себестоимости продукции. Таким образом, повышение эффективности их использования является одним из наиболее важных факторов в снижении стоимости производства и роста прибыли. Рациональное использование труда во многом определяется организацией аналитической работы, которая требует особого внимания в условиях рыночной экономики.
На сегодняшний день существует множество различных ПО для отслеживания работ сотрудников исполнителя по проекту. Во многих таких системах есть возможность создания графиков и диаграмм, для лучшего восприятия информации и представления общей картины готовности проекта. Однако набор таких визуализаций ограничен и может возникнуть необходимость создания собственных графиков с конкретными показателями. Также, в зависимости от роли, пользователи должны иметь возможность редактирования задач и данных по ним или же только просмотра данных. Таким образом, задача состоит в том, чтобы предоставить сотрудникам заказчика интерфейс для работы с задачами из системы управления проектами, используемой на предприятии.
Необходимо создать инструмент, который позволит заказчику в удобный момент узнать актуальные данные и при этом не задействовать остальных сотрудников.
В работе будут рассмотрены эти задачи, в частности, извлечения, обработки и анализа данных по проекту и предоставления информации пользователям в соответствии с ролью. На предприятии данные извлекаются из инструмента для управления проектами YouTrack. Проблема актуальна, поскольку она может сократить время работы с данными, и, таким образом, повысить эффективность рабочего процесса и заказчика, и исполнителя.
Основная цель данного исследования заключается в поиске подходящего способа решения поставленной задачи. В качестве возможного решения, мы рассмотрим веб-приложение, которое принимает данные из текущей системы YouTrack, обрабатывает их в соответствии с формулами, предоставленными заказчиком и представляет их в виде отчетов, необходимых заказчику.
Данные о задачах могут быть отредактированы определенной группой пользователей, другие пользователи имеют доступ только для чтения. Для того, чтобы разработать качественное приложение, которое отвечает требованиям заказчика, необходимо определить наборы данных, способы их извлечения из системы управления проектами, провести анализ технологий, с помощью которых будет реализована надстройка, и выбрать наиболее подходящие из них.
Цель работы - изучение существующих систем управления проектами, их функций, которые позволят извлекать данные о задачах проекта, их преимуществ и недостатков и программная реализация собственной надстройки над системой управления проектами YouTrack с учетом проведенного анализа.
Цель работы можно разделить на пять задач:
1. Изучение возможностей системы YouTrack, её ограничений и аналитический обзор её аналогов и их функциональности.
2. Определение требований к надстройке.
3. Разработка надстройки:
- проектирование интерфейса;
- определение технологий реализации;
- программная реализация надстройки.
В представленной работе объектом исследования является процесс управления проектами, предметом - системы управления проектами.
В работе использованы следующие методы исследования:
1. Общенаучные методы анализа - для поиска и определения необходимой информации.
2. Профессиональные методы:
2.1. Объектно-ориентированное проектирование и программирование - для проектирования всей системы.
2.2. Теория управления проектами и человеческими ресурсами - для анализа предметной области.
2.3. Общение с заказчиком - для определения требований и координации работ.
1. Определение и формулировка требований к надстройке
Требования были определены в ходе были бесед с заказчиком, также сформулированы необходимые ему данные о проекте и требуемые операции для обработки данных. Система планируется использоваться на предприятии более чем двадцатью людьми.
1.1 Scrum-методология
Scrum - один из наиболее популярных механизмов для реализации методологии Agile. Многие люди считают, что Agile и Scrum - одно и то же, однако это не так. Многие фреймворки могут быть использованы для реализации Agile, например, Kanban, но scrum отличается более короткими итерациями работы [1].
С помощью scrum разработка продукта происходит серией итераций фиксированной длины, называемых спринтами, которые определяют командам регулярные сроки выпуска версии ПО. Вехи - конец спринта - происходят часто и с ощущением прогресса с каждым циклом, который фокусирует и заряжает команду. Короткие итерации также усиливают важность хорошей оценки и быстрой обратной связи от тестов.
В scrum есть четыре церемонии, которые создают структуру спринта:
1. Планирование спринта: совещание по планированию задач, на котором определяется, что необходимо сделать в предстоящем спринте.
2. Ежедневное собрание: 15-минутное мини-собрание команды разработчиков ПО для синхронизации задач.
3. Спринт-демонстрация: совместное собрание, на котором команда показывает, что реализовано в спринте.
4. Ретроспектива спринта: обзор того, что и почему сделано и не сделано, формирование выводов, чтобы сделать следующий спринт лучше. Во время спринта визуальные артефакты, такие как панели задач и диаграммы сгорания задач, видимые команде, являются мощными мотиваторами. Возможность продемонстрировать новую работу на демонстрационном спринте в равной степени мотивирует, а последовательная, поэтапная обратная связь, которую команда получает от заинтересованных сторон в каждой демонстрации, создаёт мощный способ разработки продуктов.
Характеристики методологии scrum, которые понадобятся в надстройке:
1. Epic - большой кусок работы, который содержит Story.
2. Story - наименьшая единица работы, также известная как таск.
3. Delivery - дата показа программного продукта заказчику.
4. Sprint - итерация, где команда выполняет работу.
1.2 Требования к системе управления проектами
Для создания надстройки, которая позволит управлять данными о проекте, необходимо, чтобы:
1. Система управления проектом на предприятии-исполнителе имела возможность представлять информацию о характеристиках проекта, пользовательских и системных полях и их значениях.
2. Система управления проектом поддерживала методологию Scrum, т. к. именно она используется на предприятии при разработке ПО.
3. Система предоставляла возможность создания пользовательских полей.
4. Данные о проекте предоставлялись в популярном формате, таком как xml или json.
1.3 Требования к разрабатываемой надстройке
надстройка визуализация интерфейс проект
Разрабатываемая надстройка должна предоставлять интерфейс для работы с задачами из системы управления проектами YouTrack.
С помощью надстройки должна извлекаться информация о проекте и его задачах, а также информация, необходимая для визуализации данных. Настраиваемые поля в YouTrack могут использоваться для хранения значений для планирования, ссылок, аппаратных характеристик или любого другого, что нужно для эффективного отслеживания проблем.
Все характеристики задачи являются настраиваемыми полями. По умолчанию в YouTrack включены часто используемые поля задач, такие как Type, State и Assignee. Также есть список настраиваемых полей, которые прикреплены к проектам по умолчанию [8].
В дополнение к предварительно определенным полям есть возможность определить свои собственные поля.
Интересующий заказчиков проект содержит следующие характеристики задач:
1. Priority - приоритет задачи (show-stopper, critical, major, normal, minor).
2. Type - тип задачи (bug, task, epic).
3. State - состояние задачи (open, in progress, to verify, done, duplicate, investigation).
4. Assignee - исполнитель задачи.
5. Due Date - крайний срок (необязательное поле).
6. Sprints - список спринтов проекта.
7. Delivery - список дат отчётности по проекту.
8. Discipline - дисциплина задачи (Development, Content development, Documentation).
9. Request Type - тип запроса (requirement, enhancement, defect, support request).
10. Epic - набор спринтов.
11. Area Path - путь к компоненту в приложении, по которому производится работа в данной задаче.
12. Spent time - потраченное время на задачу.
13. Estimation Total - оценка всего времени, потраченного на задачу.
14. Estimation DB - оценка времени, потраченного на задачу в рамках работ по базам данных.
15. Estimation Web - оценка времени, потраченного на задачу в рамках работ по веб-части.
16. Estimation Testing - оценка времени, потраченного на задачу в рамках работ по тестированию.
Пользователи надстройки должны иметь возможность работать с этими полями, в зависимости от роли просматривать или редактировать их.
В первой версии надстройки требуется реализовать два отчёта: Delivery report и Cumulative report.
1.3.1 Delivery report
Отчёт Delivery отображает информация в разрезе выбранного Delivery. На нём можно увидеть потраченное время на работу каждого кластера (DB, Web, Testing). Задачи, которую выполняет каждый кластер имеют свои приоритеты, которые также отражены в столбцах.
Отчёт представляет из себя диаграмму, составленную из двух типов - bar и line (см. рис. 1.1). По оси X представлены виды работ (работы с базами данных, работы в веб-части приложения, тестирование), по оси Y - количество человеко-часов. Столбцы графика bar составлены из трёх частей, каждая из которых является обозначением количества часов по задаче с определённым приоритетом (P-1, P-2, P-3). Линия графика line обозначает количество доступных человеко-часов в данном Delivery. На отчёте должны присутствовать элементы выбора Delivery и Epic.
Рисунок 1.1. Макет отчёта Delivery
Для создания отчёта Delivery понадобятся следующие данные:
1. Названия Delivery - для данных в элементе выбора Delivery.
2. Названия Epic - для данных в элементе выбора Epic.
3. Количество часов, потраченных на работу в каждом кластере (DB, Web, Testing) - для значения общего количества часов в кластере.
4. Количество доступных для работы человеко-часов - для значений по line-диаграмме.
5. Информация о приоритете выполненных задач и количестве часов, потраченном на каждый приоритет - для значений в bar-диаграмме.
1.3.2 Cumulative report
Отчёт Cumulative отражает прогресс работ по каждому из Delivery в году, суммарный объём сделанных работ по проекту и запланированный годовой объём работ. Горизонтальная target-линия показывает запланированный объём работ на год, а общий сделанный объём работ показывает оранжевая линия.
Отчёт также сочетает в себе два типа диаграмм: bar и line. По оси X представлены Delivery по месяцам, на левой оси y указано число человеко-часов для line-диаграммы, на правой оси Y - количество часов для bar-диаграммы (рис 1.2). В столбцах предыдущих Delivery указано реальное количество часов (Done), потраченных на задачи в конкретном Delivery; в предстоящих Delivery указано суммарное количество часов на планируемые задачи (Open); для текущего Delivery отображается три показателя по задачам: In Progress, Open и Done (в человеко-часах). Линия показывает суммарное количество часов задач со статусом Done с начала года. Линия target показывает годовую цель по количеству сделанных задач. На отчёте должен присутствовать элемент выбора года.
Рисунок 1.2. Макет отчёта Cumulative
Для создания отчёта Cumulative понадобятся следующие данные:
1. Названия Delivery - для данных в элементе выбора Delivery.
2. Дата Delivery - для названий периодов по оси X.
3. Статус задачи (Open, In Progress, Done) - для разделения столбца текущего Delivery по часам.
4. Оценочное время выполнения задачи - для суммарного значения времени планируемых задач по каждому Delivery.
5. Плановая цель по задачам за год - линия target.
С помощью надстройки также необходимо уметь выполнять следующие операции:
1. Просмотр данных о задаче.
2. Редактирование данных о задаче.
3. Создание новой задачи.
4. Просмотр графиков с необходимыми данными.
5. Ограничение доступа к информации в соответствии с ролью пользователя.
1.4 Визуализация данных
Визуализация данных представляет собой графическое отображение абстрактной информации для двух целей: создания смысла (также называемого анализом данных) и коммуникации [3]. Важные истории живут в данных, и визуализация данных является мощным средством для обнаружения и понимания этих историй, а затем для их представления другим. Информация абстрактна в том смысле, что она описывает вещи, которые не являются физическими. Статистическая информация абстрактна. Независимо от того, касается ли это продаж, случаев заболевания, спортивных результатов или чего-то еще, даже если это не относится к физическому миру, все же возможно визуально отобразить её, но для этого необходимо найти способ придать форму тому, что формы не имеет. Этот перевод абстрактного в физические атрибуты видения (например, длина, положение, размер, форма и цвет) может быть успешным только в том случае, если имеется визуальное восприятие и познание. Другими словами, чтобы эффективно визуализировать данные, необходимо следовать принципам проектирования, основанным на понимании человеческого восприятия.
Картина стоит тысячи слов, но только тогда, когда рассказ лучше всего описывается графически, а не словесно, и картина хорошо разработана. Вы могли бы целый день наблюдать за таблицей чисел и никогда не увидеть, что было бы сразу очевидно при просмотре хорошей картины тех же чисел. Для примера приведена простая таблица данных о продажах - годовая стоимость - разделённая на два региона (рис. 1.3):
Рисунок 1.3. Пример табличных данных
Эта таблица делает две вещи очень хорошо: выражает точные значения продаж и обеспечивает эффективные средства для поиска значений для определенного региона и месяца. Но если появляется задача поиска шаблонов, тенденций или исключений среди этих значений, если нужно быстро понять содержание, содержащееся в этих числах, или сравнить целые наборы чисел, а не отдельные два, то эта таблица не самое лучшее решение.
Эта же информация, представленная в виде линейного графика (рис. 1.4):
Рисунок 1.4. Пример представления информации в виде графика
Из графика просматривается несколько фактов:
1. Внутренние продажи были значительно выше, чем международные.
2. Продажи на внутреннем рынке в целом за год выросли.
3. Международные продажи, напротив, оставались относительно плоскими, с одним очевидным исключением: в августе они резко снизились.
4. Внутренние продажи демонстрировали циклический характер, который повторялся на ежеквартальной основе, всегда достигая пика в последнем месяце квартала, а затем резко снижался в первый месяц следующего.
То, что информация, представленная в виде текста в таблице, не могла передать, который мозг человека интерпретирует с помощью вербальной обработки, становятся видимыми и понятными при общении визуально. Это и есть «визуализация данных».
1.5 Обзор систем управления проектами
В сравнении рассмотрены наиболее популярные решения для управления проектами. Среди них YouTrack - система, которая используется в данный момент на предприятии и JIRA - наиболее популярная система (45 500 000 пользователей [6]), соответствующая заявленным требованиям.
1.5.1 YouTrack
YouTrack является продуктом компании JetBrains, и сочетает в себе коммерческую систему отслеживании ошибок на основе браузера, систему отслеживания проблем и возможности управления проектами в одном аккуратном и всеобъемлющем пакете (рис. 1.5). Система предлагает функцию поиска задач на основе запросов с автозавершением и позволяет пользователям манипулировать проблемами в пакетах, настраивать набор атрибутов задачи и создавать собственные рабочие процессы.
Можно настроить синхронизацию между Sprints и Versions приложения и использовать доску Agile как еще один способ просмотра списка проблем. В этом случае доска определяется версией Fix, которая определяет спринт на плате. YouTrack помогает управлять и распределять время с помощью возможностей отслеживания времени.
Рисунок 1.5. Интерфейс Youtrack
YouTrack имеет функцию интеллектуального поиска, которая позволяет пользователям быстро находить нужную информацию благодаря автозавершению. Он также предлагает короткие сокращения, которые значительно ускоряют рутинные процессы, что значительно повышает эффективность и производительность. Пользователи также могут внимательно следить за каждым проектом и действиями команды через личную панель управления.
С помощью YouTrack пользователи могут получать информацию и отслеживать ход выполнения каждого проекта с помощью мощных инструментов отчетности, что позволяет им принимать более эффективные бизнес-решения и эффективно реализовывать стратегии. YouTrack помогает управлять и распределять время с помощью возможностей отслеживания времени.
Поддержка Scrum. Доски Agile в YouTrack поддерживают процессы Scrum и Kanban [2]. Они разработаны, чтобы помочь командам планировать, визуализировать и управлять своей работой эффективным образом. Доски Agile в YouTrack поддерживают обновления в режиме реального времени, что означает, что все изменения отражаются на карточках на доске Agile, независимо от того, где они применяются к проблемам.
Рабочий процесс можно организовать несколькими способами. Доску можно использовать в качестве отдельного объекта, где связи между задачами и доской не контролируются любым настраиваемым полем. В этом случае задачи должны быть явно добавлены в Sprint доски. Например, есть возможность перетащить задачу из невыполненных задач (backlog) или создать новую задачу прямо на доске.
Кроме того, можно настроить синхронизацию между Sprints и Versions приложения и использовать доску Agile как еще один способ просмотра списка проблем. В этом случае доска определяется версией Fix, которая определяет спринт на плате. Другими словами, спринты рассматриваются как версии Fix. Карточки на доске могут быть отфильтрованы с помощью поискового запроса (при применении запроса все задачи, не соответствующие запросу, не удаляются с доски, они просто скрыты от пользователя).
YouTrack предоставляет мощную функциональность, которая помогает выполнять различные действия программным путем через свой RESTful API, в том числе:
- импортировать задачи из другой системы отслеживания ошибок - для более плавной миграции на YouTrack. программно создавать, изменять и выполнять другие операции - чтобы можно было легко интегрировать YouTrack в свою среду. Например, через автоматическое предоставление задач от сторонних приложений. управлять проектами, пользователями, группами, ролями, типом ссылок и пользовательскими атрибутами.
API возвращает данные в форматах xml и json.
Пользовательские поля
В роли администратора можно создавать, редактировать и удалять пользовательские поля в YouTrack. Есть возможность добавить в систему настраиваемые поля и определить их свойства, не привязывая их к проектам в системе.
Пользователи с ролями администратора проекта могут создавать собственные настраиваемые поля и прикреплять их к своим собственным проектам.
При создании нового поля можно присоединить его к проекту или позволить администратору проекта при необходимости присоединить это поле.
1.5.2 JIRA
JIRA - это гибкий инструмент управления проектами, который поддерживает любую гибкую методологию, будь то Scrum, Kanban или любая другая, которая соответствует предпочтениям пользователя (рис. 1.6). Можно планировать, отслеживать и управлять всеми Agile проектами разработки программного обеспечения с помощью единого инструмента.
Рисунок 1.6. Интерфейс JIRA
Scrum - это гибкая методология, где продукты строятся в серии итераций фиксированной длины. Есть четыре столпа, которые привносят структуру в эту методологию: планирование спринта, организация ежедневных недолгих собраний, спринты и ретроспективы. Вне зависимости от того, JIRA поставляется с исчерпывающим набором гибких инструментов, которые помогают команде легко выполнять эти события.
Совещания планирования спринтов определяют, что команда должна завершить в предстоящем спринт из отставания, или список работ, которые предстоит сделать. JIRA делает отставание центром вашего совещания по планированию спринта, чтобы вы могли оценивать задачи, настраивать спринты, проверять скорость и переопределять приоритеты в режиме реального времени. В JIRA есть несколько инструментов, которые могут помочь планированию спринта.
Поддержка Scrum Доска Scrum автоматически создается с помощью проекта разработки программного обеспечения типа Scrum. После того, как проект создан, список невыполненных задач инициализируется пустым на доске Scrum. Затем пользователь заполняет backlog историями пользователей или задачами, которые необходимо выполнить для проекта, функции или продукта.
Как только создано шесть или более задач, появляется возможность начать расставлять их приоритеты в отставании. В JIRA можно расставить приоритеты задач, перетаскивая их в порядке важности отставания, который работает для команды.
Прежде чем приступить к первому спринту, важно оценить истории отставаний, чтобы вы могли определить, сколько времени займет выполнение кусков работы.
Оценки также помогут понять, сколько работы необходимо добавить к следующему спринту, исходя из количества членов вашей команды. После нескольких спринтов команда будет лучше разбираться в том, сколько работы они могут выполнять каждый спринт.
В JIRA можно оценить задачи, перейдя к списку несделанных задач и введя число в поле «Оценка» для каждой задачи.
Затем создаётся Sprint для организации задач в спринты.
JIRA REST API предоставляет стандартный интерфейс для взаимодействия.
REST API предоставляют доступ к ресурсам (сущностям данных) через пути URI. Чтобы использовать REST API, приложение делает HTTP-запрос и анализирует ответ. Используемые методы - стандартные HTTP-методы, такие как GET, PUT, POST и DELETE. REST API работает через HTTP(s), что упрощает их использование с любым языком программирования или фреймворком. Формат ввода и вывода для JIRA REST API - это JSON.
JIRA использует плагин Atlassian REST для реализации JIRA API. Плагин REST идёт в комплекте с JIRA. Есть возможность добавить свои собственные REST API к JIRA, создав плагин JIRA, который включает модуль плагинов REST.
JIRA позволяет добавлять настраиваемые поля в дополнение к встроенным полям. При создании настраиваемого поля необходимо быть администратором проекта и можно выбрать между стандартным и расширенным типами. Для стандартных типов для каждого типа отображается предварительный просмотр, поэтому можно заранее увидеть, что было создано. Это гарантирует, что будет получено желаемое поле намного быстрее. Чтобы настроить шаблоны поиска или добавить контексты в настраиваемые поля, используется параметр «Настроить» в каждом настраиваемом поле.
Пользовательские поля всегда являются необязательными. Это означает, что можно создать новое настраиваемое поле, не требуя изменения существующих задач. Существующие задачи не будут содержать значения для нового настраиваемого поля, даже если определено значение по умолчанию.
1.5.3 Team Foundation Server
Team Foundation Server (обычно сокращенно TFS) - это продукт Microsoft, который обеспечивает управление исходным кодом (с Team Foundation Version Control или Git), отчетность, управление требованиями, управление проектами (для agile и waterfall разработки программного обеспечения), автоматизированные сборки, управление тестированием и управление релизами (см. рис. 1.7). Он охватывает весь жизненный цикл приложения и обеспечивает возможности DevOps.
TFS поддерживает два типа контроля версий Git и Team Foundation Version Control (TFVC).
В зависимости от того, что используется (Git или TFVC) в качестве репозитория, разрабатывать приложения можно в Android Studio, Eclipse, IntelliJ, Visual Studio, Visual Studio Code или Xcode.
Рисунок 1.7. Интерфейс TFS
TFS может использоваться в качестве back-end для многочисленных интегрированных сред разработки (IDE), но адаптирована для Microsoft Visual Studio и Eclipse на всех платформах. Процесс Scrum поддерживает несколько типов рабочих элементов для планирования и отслеживания работы, тестов, отзывов и обзора кода. С разными типами можно отслеживать различные виды работ, такие как элементы списка незавершённых задач, новые задачи, ошибки и т. д. Эти артефакты создаются при создании командного проекта с использованием процесса Scrum. Они основаны на принципах и ценностях Scrum.
В дополнение к типам рабочих элементов, команды имеют доступ к набору общих запросов рабочих элементов для отслеживания информации, анализа прогресса и принятия решений. Если работа производится в локальной системе TFS, также предоставляется доступ к дополнительным отчетам SQL Server и панелям SharePoint.
Службы Visual Studio Team Services и API Team Foundation Server основаны на REST, OAuth, Json и сервисных перехватах - все стандартные веб-технологии, широко поддерживающиеся в отрасли.
Командный проект может содержать сто или более полей данных на основе процесса - Agile, Scrum или CMMI - используемого для создания командного проекта. Данные обновляются во время изменения поля данных внутри рабочего элемента. Каждый рабочий элемент связан с типом рабочего элемента, и данные, которые можно отслеживать, соответствуют полям, назначенным для типа.
Есть возможность изменить существующее поле или добавить настраиваемое поле, чтобы отслеживать дополнительные требования к данным. Например, можно настроить список выбора в раскрывающемся меню, добавить правило, чтобы указать значение по умолчанию или ограничить значение, которое оно может принять, или изменить атрибут поля.
Не все списки выбора определяются одинаково. Некоторые списки определяются через пользовательский интерфейс или путем добавления учетных записей пользователей в командный проект.
1.5.4 Bugzilla
Bugzilla является «системой отслеживания дефектов» или «системой отслеживания ошибок» (рис. 1.8). Системы отслеживания дефектов позволяют отдельным разработчикам или их группам эффективно отслеживать выдающиеся ошибки в своем продукте.
Рисунок 1.8. Интерфейс Bugzilla
Большинство коммерческих поставщиков программного обеспечения для отслеживания дефектов взимают огромные лицензионные сборы. Несмотря на то, что Bugzilla является бесплатным, у него есть множество функций, которых не хватает дорогостоящим коллегам.
Таким образом, Bugzilla быстро стала фаворитом тысяч организаций по всему миру.
Bugzilla предоставляет следующее:
1. Отслеживание ошибок и изменение кода.
2. Общение с товарищами по команде.
3. Отправка и просмотр исправлений.
4. Управление качеством (QA).
Scrum в Bugzilla можно организовать с помощью сторонних расширений. AgileTools предоставляет инструменты для управления командами и их процессами. В настоящее время он поддерживает процесс Scrum и предоставляет инструменты планирования и отслеживания прогресса для команд, использующих процесс Scrum.
Данные, которые необходимо связать с задачей - это данные о пользователе, который получит выгоду от работы, о компоненте продукта, на который он повлияет, и о счете времени, которое представляет воспринимаемую сложность работы. В Bugzilla нет полей для них, но поле catchall, называемое «whiteboard», может быть отформатировано таким образом, чтобы инструменты, такие как BugzillaJS и Scrumbu.gs, могли легко найти его [5]. И когда вы совмещаете это с данными истории ошибок из Bugzilla API, у вас есть все, что вам нужно для расчета графика выполнения работ, скорости команды и разработчика, а также всевозможных даже ужасных вещей.
Bugzilla имеет собственный REST API, версию HTTP своего XMLRPC и API JSONRPC. Он документирован вместе с другими интерфейсами WebServices и Bugzilla. Это предпочтительный способ взаимодействия с Bugzilla с внешними приложениями, в Интернете или иным образом.
До недавнего времени Bugzilla поддерживала только более старые технологии, а именно XMLRPC и JSONRPC. Команда BMO создала новый API REST летом 2013 года, чтобы предоставить современный веб-интерфейс для Bugzilla.
До нативного API REST была создана отдельная служба прокси, называемая BzAPI, которая предоставила API REST, используя данные, полученные с помощью более старых интерфейсов RPC, а также различные другие источники данных Bugzilla, включая представления CSV. Дополнительную информацию смотрите в документах на уровне совместимости BzAPI. Пользовательские поля обрабатываются как любые другие поля - они могут быть установлены в проектах и использоваться для поисковых запросов. Пользовательские поля следует добавлять только в случае необходимости и с тщательным учетом.
Перед добавлением настраиваемого поля лучше убедиться, что Bugzilla уже не может выполнить требуемое поведение. Многие параметры Bugzilla по умолчанию не включены, и иногда оказывается, что достаточно просто включить определенные параметры, которые уже существуют.
1.5.5 Сравнение представленных систем
Сравнение рассмотренных систем представлено в таблице 1.1.
Таблица 1.1. Сравнение систем по выделенным критериям
|
Критерий/Название системы |
Youtrack |
TFS |
JIRA |
Bugzilla |
|
|
Поддержка Scrum |
+ |
+ |
+ |
С помощью отдельных расширений |
|
|
Возможность извлечения данных о проекте (метаданные полей, значения полей) |
REST API |
REST API |
REST API |
REST API |
|
|
Возможность создания пользовательских полей |
+ |
+ |
+ |
+ |
|
|
Формат извлекаемых данных |
xml, json |
json |
json |
xml, csv |
|
|
Стоимость |
500$ в год/25 пользователей; 750$ в год/25 пользователей - в облаке |
1800$ в год/25 пользователей |
1500$ в год/25 пользователей |
Бесплатно |
На предприятии было принято решение приобрести лицензию Youtrack. Он не является бесплатным, но дешевле всех остальных аналогов и при этом имеет встроенные инструменты управления проектом с помощью методологии Scrum.
1.6 Устав проекта
Устав проекта является нормативным документом, регламентирующим реализацию проекта и порядок взаимодействия участников проекта.
Устав проекта нацелен на создание системы управления проектом, которая позволит обеспечить выполнение необходимого объема работ определенными ресурсами в заданные сроки при обеспечении требуемого качества результатов.
1.6.1 Описание идеи
Приложение будет визуализировать данные о трудозатратах сотрудников компании и представлять их в виде графических отчётов. Функциональные возможности данной системы предполагают разделения пользователей на три ролевые группы: администратор, сотрудники компании, которым необходим доступ на чтение и редактирование и сотрудники, которым необходим доступ только на чтение. Неавторизированные пользователи не смогут воспользоваться приложением.
Также в данной системе есть функция расчёта эффективности конкретного сотрудника, наличие которой позволит оценить работу сотрудника за определённый период времени, рассчитать затраты на заработную плату сотрудников и спланировать будущие затраты. К тому же будет снижена вероятность неэффективного использования ресурсов.
1.6.2 Цель и задачи проекта
Основной целью проекта является разработка ПО, состоящего из серверной и клиентской части. ПО представляет собой программный продукт для web-браузеров. В рамках реализации проекта планируется реализовать следующие задачи:
1. Определить рамки системы.
2. Спроектировать архитектуру системы.
3. Спроектировать интерфейсы взаимодействия с пользователем.
4. Разработать программную реализацию ПО.
5. Выполнить тестирование системы.
6. Развернуть систему на аппаратуре заказчика.
1.6.3 Актуальность
Описываемый проект реализует потребность заказчика в программном обеспечении (ПО) в виде автоматизированной системы генерации отчётов и работы с тасками основанном на:
- хранении информации о трудозатратах в системе Youtrack;
- хранении информации о тасках в системе Youtrack;
- хранении информации о ролях пользователей и авторизация по данным пользователя из системы Youtrack.
Разработанное программное обеспечение автоматизированной системы генерации отчётов о трудозатратах сотрудников исполнителя позволит снизить трудозатраты сотрудников заказчика за счет уменьшения времени, требуемого на анализ данных (за счёт их визуализации), расчёт эффективности сотрудников и текущее состояние проекта.
1.6.4 Возможные риски
С целью выявления каких-либо рисков проекта было проведено рабочее собрание, результатом которого стал сформированный список факторов, которые могут повлиять на процесс выполнения проекта. Данный список представлен в таблице 1.2.
Таблица 1.2. Возможные риски
|
Наименование риска |
Комментарий |
||
|
1 |
Ненадлежащее исполнение служебных обязанностей |
Для исполнения какого-либо этапа понадобится время для обучения членов команды. Невозможность вернуть долги инвестору и окупить свои затраты |
|
|
2 |
Уход или временная недееспособность одного из членов команды |
В команде для каждого отведена определенная роль и определенный объем работ, отсутствие одного из членов команды ведет к задержке в работах |
|
|
3 |
Наличие ошибок в планировании работ по проекту |
В случае неправильного распределения фронта работ по ролям, а вследствие неверной организации работы и планирования длительности выполнения работ, возможно отклонение от указанных сроков сдачи проекта в негативную сторону |
|
|
4 |
Потеря доступа к сети Интернет |
Уменьшается скорость получения необходимой информации членами группы, пропадает основное средство удаленной информации |
|
|
5 |
Потеря доступа к репозиториям |
В случае проблем с доступом к репозиториям разработчик не сможет корректно управлять версиями |
|
|
6 |
Недостаточное покрытие функционала приложения тестами |
На время устранения ошибки пользователи не смогут осуществить, например, просмотр отчётов. Потребуется “ручная” работа персонала, что увеличит время анализа информации. |
|
|
7 |
Поломка оборудования у разработчика |
Увеличение сроков с учетом починки |
|
|
8 |
Недопонимание заказчика |
Неточное выявление нужд и требований заказчика увеличит время проектирования и разработки |
|
|
9 |
Потеря мотивации у членов группы |
Отсутствие мотивации приведет к задержке/ невыполнению работ, из-за чего необходимо перераспределение ресурсов либо увольнение члена команды |
1.6.5 Классификация рисков
Еще одним результатом совместного обсуждения рисков стал список с их основными причинами, условиями возникновения, последствиями и возможным ущербом (табл. 1.3).
Таблица 1.3. Классификация рисков
|
Первопричина |
Условие |
Последствия |
Приносимый ущерб |
||
|
1 |
Неудовлетворенность проектом / безразличие к проекту и команде |
Уход одного из членов команды |
1. Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 2. Не весь запланированный функционал реализован |
Потеря времени |
|
|
2 |
Отсутствие опыта / Некомпетентность |
Ненадлежащее исполнение служебных обязанностей |
1. Увеличение сроков, выделенных на выполнение проекта 2. Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 3. Не весь запланированный функционал реализован 4. Невозможность вернуть долги инвестору и окупить свои затраты |
1. Потеря времени 2. Потеря доверия заказчика 3. Потеря инвестора |
|
|
3 |
Плохой иммунитет |
Временная недееспособность одного из членов команды |
1. Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 2. Не весь запланированный функционал реализован |
Потеря времени |
|
|
4 |
Отсутствие опыта работы в команде |
Наличие ошибок в планировании работ по проекту |
1. Задержки на различных стадиях выполнения проекта 2. Не весь запланированный функционал реализован |
1. Потеря времени 2. Потеря доверия заказчика |
|
|
5 |
Форс-мажор |
Потеря доступа к сети Интернет |
1. Потеря связи с членами группы/ с документацией по проекту 2. После восстановления работы по сети придется увеличить интенсивность работы |
Потеря времени |
|
|
6 |
Форс-мажор |
Потеря доступа к репозиториям |
В случае проблем с доступом к репозиториям разработчик не сможет корректно управлять версиями. |
1. Потеря времени 2. Потеря данных |
|
|
7 |
Некорректно организован процесс тестирования |
Недостаточное покрытие функционала приложения тестами. |
1. Неправильно функционирующее приложение 2. На время исправления ошибок система станет недееспособна |
1. Потеря времени 2. Потеря доверия заказчика |
|
|
8 |
Форс-мажор |
Поломка оборудования |
Понадобится время на устранение поломки |
Потеря времени |
|
|
9 |
Ошибки при организации взаимодействия с заказчиком |
Недопонимание заказчика |
Дополнительные встречи с заказчиком прибавят время к срокам |
Потеря времени |
|
|
10 |
Незаинтересованность в проекте |
Потеря мотивации |
Отсутствие мотивации приведет к задержке/ не выполнению работ |
1. Потеря времени 2. Необходимость в перераспределении ресурсов 3. Увольнение члена команды |
1.6.6 Анализ и приоритезация рисков
Список с приоритетами рисков представлен в таблице 1.4.
Таблица 1.4. Анализ и приоритезация рисков
|
Приоритет |
Условие |
Последствие |
Вероя-сть |
Угроза (по пяти балльной шкале) |
Ожидаемая величина (у. е.) |
|
|
1 |
Наличие ошибок в планировании работ по проекту |
1. Задержки на различных стадиях выполнения проекта 2. Не весь запланированный функционал реализован |
60% |
3 |
1,80 |
|
|
2 |
Уход одного из членов команды |
1.Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 2. Не весь запланированный функционал реализован |
50% |
2 |
1,00 |
|
|
3 |
Временная недееспособность одного из членов команды |
1. Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 2. Не весь запланированный функционал реализован |
60% |
2 |
1,20 |
|
|
4 |
Недостаточное покрытие функционала приложения тестами. |
1. Неправильно функционирующее приложение 2. На время исправления ошибок система станет недееспособна |
45% |
5 |
2,25 |
|
|
5 |
Недопонимание заказчика |
Дополнительные встречи с заказчиком прибавят время к срокам |
10% |
2 |
0,20 |
|
|
6 |
Потеря доступа к репозиториям |
В случае проблем с доступом к репозиториям разработчик не сможет корректно управлять версиями. |
27% |
2 |
0,54 |
|
|
7 |
Потеря доступа к сети Интернет |
1.Потеря связи с членами группы/ с документацией по проекту 2. После восстановления работы по сети придется увеличить интенсивность работы |
10% |
1 |
0,10 |
|
|
8 |
Потеря мотивации |
Отсутствие мотивации приведет к задержке/ невыполнению работ |
90% |
4 |
3,60 |
|
|
9 |
Ненадлежащее исполнение служебных обязанностей |
1. Увеличение сроков, выделенных на выполнение проекта 2. Обучение участников проекта (переквалификация)/Поиск дополнительной помощи вне команды 3. Не весь запланированный функционал реализован |
80% |
4 |
3,40 |
|
|
10 |
Поломка оборудования |
Понадобится время на устранение поломки |
10% |
2 |
2,00 |
Инвестором будет являться заказчик. Проект реализуется в рамках существующей компании ООО «Смарт Аналитикс».
2. Проектирование надстройки
Чтобы разработать качественное приложение, которое отвечает требованиям заказчика, необходимо определить наборы данных, способы их извлечения из системы управления проектами.
2.1 Проектирование извлечения данных из YouTrack
YouTrack использует встроенную базу данных JetBrains Database -- транзакционное хранилище пар «ключ -- значение». Для удалённых вызовов процедур используется REST-стиль.
Пользовательский тип поля - это формат, который присваивается значениям, хранящимся в поле. Этот формат определяет, как YouTrack интерпретирует данные.
Поддерживаемые типы можно разделить на две категории [7]:
1. Простые типы - эти типы включают типы даты, целого и строки.
2. Перечисляемые типы - эти типы позволяют выбирать значения из предопределенного списка. Простые типы хранят отдельные значения в определенном формате. Среди простых типов, которые поддерживаются в YouTrack есть такие, как: string, date, period, integer, float.
В перечисляемых типах хранятся одно или несколько значений из предопределенного набора значений. Перечисляемые типы, поддерживаемые системой YouTrack представлены в таблице 2.1.
Таблица 2.1. Перечисляемые типы полей в YouTrack
|
Тип поля |
Описание |
|
|
enum |
Содержит значения из предопределенного набора значений. Набор значений для этого типа поля представляет собой произвольный массив значений, которые хранятся в виде строкового типа. |
|
|
group |
Содержит ссылку на группу. Набор возможных значений берется из списка групп в YouTrack. В настраиваемом поле отображается имя группы. Список доступных групп основан на назначении разрешения «Чтение пользовательских групп». |
|
|
user |
Хранит ссылку на учетную запись пользователя. По умолчанию в поле Assignee используется этот тип. Набор возможных значений берется из списка пользователей в YouTrack. В настраиваемом поле отображается полное имя. В раскрывающемся списке также отображается имя пользователя. Список доступных пользователей основан на назначении разрешения «Чтение пользователя». |
|
|
ownedField |
Сохраняет значения из предопределенного набора значений. По умолчанию в поле Subsystem используется этот тип. Этот тип аналогичен типу перечисления, за исключением того, что каждое значение в наборе значений хранит владельца. Это свойство хранит ссылку на пользователя, который отвечает за подсистему как пользовательский тип. |
|
|
state |
Сохраняет состояние проблемы из предопределенного набора состояний проблемы. Этот тип также является разновидностью типа enum. Здесь каждое значение в наборе значений имеет свойство isResolved. Это свойство указывает, будет ли проблема считаться разрешенной, когда ей присвоено соответствующее значение в этом поле. Это значение хранится как логический тип. |
|
|
version |
Хранит версию из предопределенного списка версий. Каждое значение в наборе версий хранит следующую информацию: ReleaseDate - сохраняет дату выпуска в виде даты. Может соответствовать фактической или запланированной дате выпуска. Released - указывает, будет ли версия освобождена, сохранена как логический тип. Archived - указывает, сохранена ли версия в виде логического типа. |
|
|
build |
Сохраняет номер сборки из предопределенного набора номеров сборки. Каждое значение в наборе сборок хранит дату сбора. Это свойство хранит дату, когда выбранная сборка была собрана как тип даты. |
Типы полей характеристик проекта представлены в таблице 2.2.
Таблица 2.2. Типы полей проекта
|
Название поля |
Тип |
|
|
Priority |
enum |
|
|
Type |
enum |
|
|
State |
state |
|
|
Assignee |
user |
|
|
Due Date |
date |
|
|
Sprints |
version |
|
|
Ideal days |
integer |
|
|
Story points |
integer |
|
|
Delivery |
enum |
|
|
Discipline |
enum |
|
|
Request Type |
enum |
|
|
Epic |
enum |
|
|
Area Path |
enum |
|
|
Estimation |
period |
|
|
Spent time |
period |
|
|
Estimation Total |
period |
|
|
Estimation DB |
period |
|
|
Estimation Web |
period |
|
|
Estimation Predictive |
period |
|
|
Estimation Testing |
period |
Для извлечения значений полей необходимо воспользоваться REST API, который предоставляет YouTrack. Запросы варьируются в зависимости от типа извлекаемого значения:
1. GET /rest/admin/customfield/stateBundle/{bundleName} - возвращает группу значений состояний по её имени.
2. GET /rest/admin/agile/{agileById}/sprint/{sprintById} - возвращает информацию о спринте по его Id.
3. GET /rest/admin/customfield/versionBundle/{bundleName} - возвращает группу значений версий по её имени.
4. GET /rest/admin/project/{projectName}/assignee - возвращает всех участников проекта.
5. GET /rest/admin/customfield/userBundle/{bundleName} - возвращает группу значений пользователей по её имени.
6. GET /rest/admin/customfield/bundle/{bundleName} - возвращает значение из группы значений перечисляемого типа.
7. GET /rest/admin/project/{projectId}/customfield/{customFieldName} - возвращает настраиваемое поле проекта по его имени.
Также у пользователя должна быть возможность создавать новые задачи и редактировать существующие: PUT /rest/issue?{project}&{summary}&{description}&{attachments}&{permittedGroup} - создание новой задачи в YouTrack.
1. POST /rest/issue/{issueID}?{summary}&{description} - редактирование существующей задачи.
После того, как данные из YouTrack извлечены и обработаны, они могут быть визуализированы.
Аутентификация пользователя в YouTrack также производится через REST API. Соответствующий запрос: POST /rest/user/login?{login}&{password}, где login - логин пользователя в системе YouTrack, password - пароль пользователя в системе YouTrack. Запрос возвращает cookie аутентификации, с помощью которой пользователь сможет производить действия через систему.
2.2 Проектирование интерфейса надстройки
Конечный пользователь системы будет работать с задачами из YouTrack и сформированными отчётами о задачах и трудозатратах. Функции, предусмотренные в рамках первой версии системы и требующие собственного интерфейса:
1. Страница просмотра списка задач.
2. Страница просмотра списка отчётов.
3. Страница просмотра отчёта.
4. Страница просмотра подробной информации и редактирования задачи.
5. Страница создания новой задачи.
Главная страница приложения содержит список задач (рис. 2.1). Списки задач сгруппированы по поисковым запросам пользователя из YouTrack, которые отражены в боковой панели. Основной блок контента содержит список задач по выбранному запросу. Вверху страницы находится панель с кнопками переключения между списком задач из YouTrack и списком отчётов, а также кнопка создания новой задачи.
Рисунок 2.1. Макет главной страницы приложения
Чтобы отобразить список отчётов необходимо нажать на кнопку отображения списка отчётов. Произойдёт смена заголовка боковой панели и её содержание (см. рис. 2.2). Также при нажатии на отчёт в списке отчётов в основном блоке контента будет показано превью отчёта.
Рис. 2.2. Макет страницы приложения со списком отчётов
Отредактировать задачу можно при просмотре её подробной информации (рис. 2.3). Дизайн страницы создания задачи аналогичен странице просмотра детальной информации задачи, за исключением вкладок «Комментарии», «История» и «Связанные задачи».
Рисунок 2.3. Макет страницы просмотра подробной информации задачи
2.3 Взаимодействие с системой
Описание действий, совершаемых при взаимодействии пользователя и системы показаны в диаграммах прецедентов.
Название прецедента №1: Работа с отчётами (рис. 2.4).
Акторы: Зарегистрированный пользователь с любыми правами доступа.
Краткое описание: Пользователь открывает систему, авторизуется и совершает необходимые ему действия (просмотр отчёта, смена временной отметки в отчёте).
Основной поток (табл. 2.3):
Таблица 2.3. Работа с отчётами
|
Действия акторов |
Отклик системы |
|
|
Пользователь вводит логин (Е1). Логин зарегистрирован в базе данных и система находит его. |
Подтверждает пользователя и высвечивает главную страницу. |
|
|
Пользователь выбирает вкладку «Отчёты» на панели. |
Отображает список отчётов. |
|
|
Пользователь выбирает необходимый отчёт. |
Происходит подгрузка данных, необходимых для отчёта и затем информация высвечиваются в виде графика. |
|
|
Пользователь меняет временную отметку отчёта. |
Происходит подгрузка данных, соответствующих новой отметке отчёта и затем информация высвечиваются в виде графика. |
|
|
Пользователь просматривает данные и завершает работу с отчётом, закрывая его. |
Система перенаправляет пользователя к списку отчётов. |
Рисунок 2.4. Использование надстройки. Работа с отчётами.
Название прецедента №2: Работа в надстройке с задачами из YouTrack.
Акторы: Пользователь с правами Администратора, пользователь с правами редактирования и просмотра задач, пользователь с правами просмотра задач.
Краткое описание: Авторизованный пользователь открывает главную страницу приложения и совершает необходимые ему действия (просматривает, редактирует информацию о диаграммах и пользователях).
Потоки действий (табл. 2.4):
Таблица 2.4. Работа в надстройке с задачами из YouTrack
|
Действия акторов |
Отклик системы |
|
|
Администратор/пользователь с правами редактирования и чтения задач создаёт новую задачу. |
При успешной валидации информации система отправляет запрос на создание задачи в YouTrack, после чего система оповещает об успехе/ошибке выполнения операции. |
|
|
Администратор/пользователь с правами редактирования и чтения задач редактирует существующую задачу. |
При успешной валидации информации система отправляет запрос на обновление задачи в YouTrack, после чего система оповещает об успехе/ошибке выполнения операции. |
|
|
Администратор/пользователь с правами редактирования и чтения задач удаляет существующую задачу. |
Система отправляет запрос на удаление задачи в YouTrack, после чего система оповещает об успехе/ошибке выполнения операции. |
|
|
Администратор добавляет нового пользователя. |
Система отправляет запрос на обновление пользователя в YouTrack, после чего система оповещает об успехе/ошибке выполнения операции. |
|
|
Пользователь с правами только на чтение информации просматривает информацию задач/отчётов. |
Система высвечивает запрошенную информацию, при этом функционал редактирования информации недоступен. |
Глава 3. Разработка и тестирование надстройки
В результате этапа проектирования было получено представление о системе и её реализации. В главе рассматриваются использованные технологии реализации и приведены фрагменты кода надстройки.
3.1 Средства разработки и технологии
Была изучена документация по выбранным языкам программирования (C# для серверной части, TypeScript для клиентской части) и библиотекам (ReactJS, Highcharts). Также возможно было использовать язык программирования Java, но в организации мало людей, которые работали с ним, и гораздо меньше опыта работы с этим языком. ReactJS дает возможность ускорить работу приложения, обновляя только конкретные компоненты на странице с отчетом, а не на всей странице. Highcharts - это библиотека, которая помогает создавать интерактивные диаграммы для веб-страницы. Одновременный доступ к данным и различные права доступа могут быть обеспечены выбранными технологиями.
Highcharts - библиотека для создания графиков написанная на JavaScript, позволяет легко добавлять интерактивные, анимированные графики на сайт или в веб-приложение. На данный момент графиков поддерживают большое количество диаграмм линейных, круговых, колоночных рассеивающих и многих других типов.
Поддерживаются следующие типы вывода графиков [4]:
Подобные документы
Сущность управления проектами, этапы его реализации и необходимые для этого знания, порядок составления и назначение Плана управления проектом. Концепция тройственной ограниченности. Использование программы MS Oficce Project в управлении проектами.
реферат [24,9 K], добавлен 16.11.2009Обзор рынка Информационных технологий. Современные автоматизированные системы управления проектами и их классификация. Open Plan (Welcom Software) - система, предлагающая решение по управлению проектами масштаба корпорации. Основные модули Open Plan.
курсовая работа [630,9 K], добавлен 24.02.2010Методы и алгоритмы построения инструментариев для разработки систем управления проектами посредством Web интерфейса. Составление модели обработки информации "как должно быть". Годовой экономический эффект и прочие показатели экономической эффективности.
дипломная работа [1,1 M], добавлен 28.09.2015Аналитический обзор целевой аудитории сайта. Анализ требований к сайту. Проектирование функций и архитектуры системы при помощи CMS WordPress. Разработка интерфейса и структуры данных. Реализация интерфейса (экранные формы и руководство по эксплуатации).
дипломная работа [2,0 M], добавлен 19.01.2017Разработка системы управления проектами для компании ЗАО "Диакон". Экономические параметры разработки и внедрения электронной информационной системы. Технология разработки программного обеспечения. Выбор типа графического интерфейса, его составляющие.
дипломная работа [1,4 M], добавлен 10.06.2014Характеристика основных методик управления проектами, их отличительные особенности, критерии и обоснование выбора, анализ информационных технологий. Анализ возможностей, предоставляемых программой Microsoft Project, ее экономическая эффективность.
дипломная работа [4,6 M], добавлен 28.06.2010Внедрение системы управления проектами Microsoft Project 2003 в Московский институт экономики, менеджмента и права для автоматизации учета выполнения дипломных проектов. Сравнительная характеристика систем управления проектами в России и за рубежом.
дипломная работа [1,4 M], добавлен 25.10.2013Формирование требований к системе. Описание входной и выходной информации. Концептуальное и логическое проектирование структуры и пользовательского интерфейса. Выбор средств реализации подсистемы. Реализация функциональности программного средства.
курсовая работа [1,3 M], добавлен 28.08.2012Проектирование корпоративных информационных систем. Автоматизация процесса выполнения лабораторных работ по дисциплине "Управление программными проектами". Построение модели ИС учебного процесса: архитектура, формализация пользовательских требований.
дипломная работа [1,1 M], добавлен 20.08.2017Проектирование базы данных "Менеджер". Выбор системы проектирования и реализации. Задачи, выполняемые приложением. Технические требования, предъявляемые к базе данных. Ее информационно-логическая структура. Основные принципы работы с приложением.
дипломная работа [2,5 M], добавлен 20.05.2013
