Проектная деятельность органов власти Пермского края в реализации государственных программ
Анализ проектной деятельности Администрации губернатора Пермского края. Программное обеспечение процессов управления государственными программами, роли и функции участников. Требования к информационной системе и средствам моделирования бизнес-процессов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 30.06.2017 |
| Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Дополнительные согласующие выбираются на при заполнении запроса на внесение изменений. Пользователь должен указать дополнительным согласующих по иерархии (значимости) согласующего. Но согласование должно происходить в обратном порядке, указанном в данном разделе.
Исполнитель задачи согласования внесенных изменений должен иметь возможность согласовать, вернуть на доработку пользователю, который вносил изменения в проект или перенаправить задачу.
При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Также ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.
Если форма исполнения задания выбрана «Перенаправить», то на форме задачи должно появиться (открыться для редактирования) поле для указания пользователя, кому задачу необходимо перенаправить. Далее происходит назначение задачи по согласованию объекта управления пользователю, указанному при перенаправлении задачи.
Далее происходит назначение задачи по согласованию запроса на изменение пользователю, указанному при перенаправлении задачи.
Если форма исполнения задания выбрана «Требуется доработка», необходимо пользователю, который выполнил задачу по внесению изменений в проект назначить задачу по его доработке.
Если форма исполнения задания выбрана «Согласовано», происходит проверка по списку согласования, если согласовавший пользователь не последний в списке согласования, задача по согласованию объекта управления назначается следующему в списке.
Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.
Требования к этапу доработки внесенных изменений в проект
Если внесенные изменения в проект были отправлены согласующим на доработку, Исполнителю задачи по внесению изменений поступает задача «Доработайте внесенные изменения в проект». При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.
Исполнитель задачи по доработке изменений должен иметь возможность перенаправить ее или выполнить самостоятельно.
Если форма исполнения задания выбрана «Перенаправить», то на форме задачи должно появиться (открыться для редактирования) поле для указания пользователя, кому задачу необходимо перенаправить. При перенаправлении задачи процесса переходит и ответственность по ее исполнения на пользователя, которому она была перенаправлена, и дополнительной проверки перенаправившим пользователем не требует.
Далее происходит назначение задачи по доработке внесённых изменений в проект пользователю, указанному при перенаправлении задачи.
Если форма исполнения задания выбрана «Выполнено», внесенные изменения в проект снова отправляется на круг согласования.
После завершения этапа согласования внесенных изменений в проект (согласовали все пользователи из списка согласующих со статусом «Согласовано») необходимо сохранить базовый план объекта управления (только по изменённым строкам), опубликовать и снять версию.
После завершения этапа согласования внесенных изменений Система должна сохранить новый базовый план объекта только по незавершенным задачам Плана-графика. После завершения сохранения базового плана объект управления должен быть опубликован Системой и внесенные изменения должны стать доступны для просмотра.
После публикации объекта управления процесс внесения изменений завершается.
Схема процесса внесения изменений приведена в Приложении Г.
2.7 Общие требования к ИС УГП
В ходе сбора и систематизации требований были сформулированы требования, предъявляемые к ИС УГП.
Система предназначена для автоматизации деятельности по управлению государственными программами, а также проектами, «дорожными картами» и непроектными мероприятиями (далее - объектами управления).
Создаваемая система должна стать основным инструментом технологической поддержки управления проектной деятельностью ИОГВ Пермского края и призвана обеспечить повышение эффективности работы ИОГВ Пермского края в данной сфере.
Автоматизация управления проектной деятельностью ИОГВ Пермского края должна распространяться на все фазы жизненного цикла объектов управления, в том числе процессы разработки их структуры и содержания, включая процессы управления их изменениями, а также процессы управления выполнением планов реализации объектов управления.
В связи с тем, что разрабатываемая информационная система должна стать основным инструментом технологической поддержки управления проектной деятельностью ИОГВ и иметь единый источник данных о результатах достижения показателей государственных программ были сформулированы требования, касающиеся интеграции с ИАС ПК. Это позволит решить ряд организационных задач:
· Сокращение трудозатрат, минимизация ошибок и повышение скорости выполнения процессов управления проектной деятельностью.
· Обеспечение сопровождения полного жизненного цикла управления объектами управления.
· Обеспечение соответствия целей и задач государственных программ Пермского края кодификатору целей и задач социально-экономического развития Пермского края.
· Обеспечение результативности реализации объектов управления.
· Соблюдение и сокращение сроков достижения результатов объектов управления.
· Обеспечение эффективного использования временных, человеческих и финансовых ресурсов.
· Прозрачность, обоснованность и своевременность принимаемых решений.
· Повышение эффективности внутриведомственного, межведомственного и межуровневого взаимодействия, за счет использования единых подходов проектного управления.
· Вывод из действия ИАС УП, что в свою очередь позволит исключить из эксплуатации программное обеспечение зарубежного производства Microsoft Project и перейти к использованию технологий и платформ отечественного производства и/или свободно распространяемого программного обеспечения.
Требования к структуре и функционированию ИС УГП
Система должна представлять собой единый комплекс программных продуктов с интерфейсом на русском языке, предназначенных для выполнения задач автоматизации управления государственными программами Пермского края.
Система должна функционировать на основе современных программно-технических решений и удовлетворять следующим общим требованиям:
· Создание и развитие с использованием технологий и платформ отечественного производства и/или свободно распространяемого программного обеспечения.
· Масштабируемость системы, как с помощью программных модулей, так и инфраструктурных компонентов.
· Функционирование в архитектуре «клиент-сервер».
· Совместимость и масштабируемость процедур информационного обмена между компонентами системы и с внешними информационными системами.
· Интеграция модулей в рамках единого пользовательского интерфейса.
· Обеспечение эффективной обработки и надежного хранения большого объема данных.
· Обеспечение защиты от несанкционированного доступа.
В целях обеспечения преемственности и сохранения существующего опыта в сфере управления проектной деятельностью для разработки ИС УГП, в том числе, должны быть использованы существующие технологические решения, инструментарий и данные ИАС УП.
Архитектура ИС УГП должна соответствовать трехуровневой клиент-серверной архитектуре и состоять из следующих уровней:
· уровень хранения данных;
· уровень приложений;
· уровень клиента.
Общая программная архитектура ИС УГП приведена на рис. 2.7.
Рисунок 2.7 Общая программная архитектура ИС УГП
Все модули, входящие в состав системы, отечественного производства или созданы с использованием свободно распространяемого программного обеспечения.
При создании системы должны быть использованы и модернизированы существующие реализации процессов жизненного цикла объектов управления.
При создании системы должен быть сохранен массив данных существующих объектов управления типа «Подпрограмма государственной программы», «Дорожная карта», «Проект», «Непроектное мероприятие», «Непроектное мероприятие по привлечению федеральных финансовых средств».
Организация электронного взаимодействия, синхронизация данных и обмена необходимой информацией с информационными системами и их компонентами должна обеспечиваться с использованием Региональной сервисной шины Пермского края, развернутой на ресурсах Министерства информационного развития и связи Пермского края.
Доступ пользователей к прикладному программному обеспечению ИС УГП должен осуществляться в режиме тонкого клиента (работа пользователя осуществляется через веб-браузер), функционирующего в различных операционных средах.
Требования к способам и средствам связи для информационного обмена между компонентами ИС УГП
Информационный обмен между компонентами ИС УГП должен обеспечиваться с помощью современных протоколов и форматов передачи данных (Web-сервисы, TCP/IP, XML-файлы). Между серверной частью ИС УГП и клиентскими приложениями информационный обмен должен осуществляться по протоколу HTTP. На транспортном уровне для взаимодействия компонентов ИС УГП должен использоваться стек протоколов TCP/IP.
Информационное взаимодействие между физическими серверами ИС УГП должно обеспечиваться посредством локальной сети типа Ethernet 100/1000, обеспечивающей передачу данных по протоколу TCP/IP.
2.8 Функциональные требования
Для определения функциональных требований к системе управления государственными программами необходимо описать типичные взаимодействия между пользователями системы и самой системой и предоставить описание процесса её функционирования. Для этого будет применена диаграмма прецедентов.
Предполагается несколько сценариев взаимодействия пользователя с системой:
· Регистрация объекта управления в системе.
· Разработка объекта управления, включающая:
o Заполнение основных сведений об объекте.
o Формирование рабочей группы объекта
o Формирование плана-графика.
o Формирование перечня показателей.
o Формирование плана финансирования.
o Планирование рисков.
· Согласование разработанного объекта.
· Формирование отчетности о результатах достижения вех.
· Согласование и утверждение фактических данных о достижении вех.
· Внесение изменений в объект.
· Согласование изменений.
· Формирование регламентных отчетов.
· Актуализация справочников.
· Аудит изменений.
· Администрирование процессов.
· Администрирование базы данных.
· Управление полномочиями и разрешениями.
Диаграмма прецедентов приведена на рис. 2.8.
Исходя из анализа сценариев взаимодействия ИС УГП и пользователя-участника проектной деятельности определен следующий состав модулей:
· Единое веб-приложение.
· Модуль организации рабочих областей объектов управления.
· Личный кабинет пользователя.
· Модуль паспортизации.
· Модуль календарного планирования.
· Модуль управления рисками.
· Модуль отчетности и мониторинга.
· Модуль хранения файлов документов.
· Реестр пользователей.
· Модуль исполнения процессов жизненного цикла проектов.
· Технические и обеспечивающие модули:
Рисунок 2.7 Диаграмма прецедентов
o Интерфейс администрирования
o Журналирование изменений данных ИС УГП
o Нотификация пользователей
o Интеграция с внешними системами
Перечисленные модули представлены в виде схемы функциональной структуры ИС УГП на рис. 2.8.
Рисунок 2.8 Общая функциональная структура ИС УГП
информационный проектный государственный управление
Требования к модулю реализации рабочего пространства объекта управления
Отображение данных о любом объекте управления ИС УГП должно быть реализовано в виде страницы рабочего пространства объекта управления, предоставляющего пользователям следующие возможности:
· Отображение сводной информации по объекту управления.
· Отображение сведений об объекте управления в зависимости от его типа.
· Отображение плана-графика объекта управления.
· Отображение данных о жизненном цикле объекта управления.
· Отображение реестра рисков объекта управления.
· Отображение связанных с объектом документов.
· Отображение участников объекта управления и их ролей.
· Отображение списка процессов изменений по проекту.
· Механизм сравнения версий проектов.
· Формирования печатной формы паспорта объекта управления.
На странице объекта управления должна размещаться информация о режиме объекта управления - извлечен проект на редактирование или открыт в режиме просмотра. Если просматриваемый проект извлечен для редактирования на странице объекта управления должно быть отображено фамилия, имя и отчество пользователя, извлекшего проект.
Также необходимо разместить на странице объекта управления дату и время его последней публикации.
Необходимо реализовать выбор режима просмотра объекта управления: только чтение или редактирование. При попытке открыть объект на редактирование должна осуществляться проверка на наличие прав на редактирование. Если у пользователя таких прав нет, должно выводиться сообщение об этом.
Пользователь должен иметь возможность выбора версии объекта управления: рабочей или опубликованной. Просмотр рабочей версии объекта управления должен быть доступен участникам объекта управления и исполнителю задачи по согласованию объекта управления или по согласованию внесенных изменений.
Требования к модулю паспортизации объектов управления
При наличии соответствующих прав пользователям должно быть доступно редактирование данных объекта управления.
Модуль паспортизации должен обеспечивать возможность создания, хранения, просмотра и редактирования паспортов объектов управления. При этом пользователю должны быть предоставлены возможности ввода и просмотра следующей информации:
· Номер и наименование объекта.
· Цели объекта управления с возможностью ручного ввода. Должна быть реализована возможность указания нескольких целей для всех типов проектов.
· Задачи объекта управления с возможностью ручного ввода каждой задачи. Должна быть реализована возможность ввода нескольких задач для всех типов проектов.
· Сведения о Заказчике.
· Данные об ответственном исполнителе объекта управления.
· Сведения о руководителе и администраторе.
· Соисполнители объекта управления - структурные подразделения, задействованные в реализации объекта управления.
· Состав рабочей группы - участники объекта управления, задействованные в реализации, руководители и специалисты структурных подразделений организации.
· Реестр рисков объекта управления.
· План-график объекта управления в виде иерархического перечня работ, мероприятий и вех.
Отображение и редактирование информации паспорта объекта управления должно быть реализовано в виде страницы веб-приложения, в которой информация для любого типа объекта управления должна быть организована в виде основных логических блоков, каждый из которых должен быть размещен на отдельной вкладке страницы.
Отображение количества блоков на странице объекта управления должно зависеть от его типа.
Требования к паспортизации государственных программ и подпрограмм
Функциональные возможности страницы паспортизации объекта управления типа «Государственная программа» (далее - Программа) должны обеспечивать следующую дополнительную логику ввода и хранения данных, сгруппированных по блокам:
· В рамках блока «Основные сведения»:
o Необходимо обеспечить возможность ввода текстового описания программно-целевых инструментов.
o Необходимо обеспечить возможность ввода текстового описания ожидаемых результатов реализации Программы.
· Для отображения подпрограмм госпрограмм необходимо реализовать раздел, содержащий перечень входящих в госпрограмму подпрограмм с указанием наименований. Список должен позволять открыть паспорт выбранной подпрограммы или инициировать добавление новой подпрограммы в программу.
· Раздел «Цели и Задачи» Программы должен содержать цели Программы и список ее задач, которые являются целями, входящих в Программу Подпрограмм. Пользователь должен иметь возможность указать в качестве цели Программы одно из значений справочника кодификатора целей и задач социально-экономического развития. Если в кодификаторе отсутствует значение, соответствующее цели программы, пользователю должна быть предоставлена возможность ручного ввода в поле «Цель Программы».
· Дополнительный блок «Мероприятия» должен отображаться вместо блока «План» и содержать перечень основных мероприятий и мероприятий Подпрограмм, входящих в Программу. Мероприятия должны быть сгруппированы по основным мероприятиям. Основные мероприятия должны быть сгруппированы по Подпрограммам.
· Блок «Показатели» должен содержать редактируемый перечень целевых показателей Программы и список для просмотра целевых показателей Подпрограмм, входящих в Программу. Целевые показатели должны содержать информацию о наименовании, единице измерения, периоде, плановом и фактическом значении. При формировании перечня целевых показателей Программы необходимо предоставить пользователю возможность связать целевой показатель со значением справочника целевых показателей ИС УГП. Целевые показатели подпрограмм должны отображаться с привязкой к мероприятиям и основным мероприятиям в группировке по Подпрограммам.
· Блок «Финансирование» должен содержать плановые данные о финансировании Программы в разрезе источников финансирования и годов реализации объекта управления. Данные о финансировании программы, должны формироваться на основе суммирования данных о финансировании входящих в нее подпрограмм.
Необходимо реализовать инструмент отслеживания иерархической структуры кодификатора целей и задач, в котором должны быть промаркированы пункты, удовлетворяющие условиям:
· Пункты, вошедшие в паспорта программ.
· Пункты, добавленные пользователем вручную при заполнении атрибутов программы или подпрограммы и требующие добавления в кодификатор.
Страница программы должна содержать ссылку на реализованный инструмент отслеживания иерархической структуры кодификатора целей и задач.
Функциональные возможности страницы паспортизации объекта управления типа «Подпрограмма государственной программы» должны обеспечивать дополнительную логику ввода и хранения данных, сгруппированных по блокам:
· В рамках блока «Основные сведения»:
o Необходимо обеспечить возможность указания наименования Государственной программы, к которой относится Подпрограмма. Наименование выбирается из перечня Государственных программ ИС УГП.
o Пользователь должен иметь возможность указать в качестве цели одно из значений справочника кодификатора целей и задач социально-экономического развития. При указании цели подпрограммы пользователь должен иметь возможность ввести ее вручную или связать ее с пунктом справочника Кодификатора целей и задач социально-экономического развития. Для отмены соответствия и изменения цели Подпрограммы необходимо выбрать другое значение кодификатора.
· Дополнительный блок «Мероприятия» должен содержать перечень мероприятий и основных мероприятий подпрограммы.
· Блок «Показатели» должен содержать перечень целевых показателей реализации Подпрограммы. При формировании перечня целевых показателей необходимо предоставить пользователю возможность выбрать показатель из значений справочника целевых показателей ИС УГП.
Для объектов управления с типом «Государственная программа» и «Подпрограмма государственной программы» должна быть реализована возможность маркировки значений целей, задач, мероприятий в случае, если значения, выбранные из справочника кодификатора для целей, задач, мероприятий программы и подпрограммы, не имеют связи ни с одним из пунктов справочника кодификатора.
Требования к паспортизации объектов управления типа «Дорожная карта», «Проект» и «Непроектное мероприятие»
Функциональные возможности страницы паспортизации объектов управления типа «Дорожная карта», «Проект» и «Непроектное мероприятие» должны обеспечивать следующую дополнительную логику ввода и хранения данных, сгруппированных по блокам:
· В рамках блока «Основные сведения»:
o При указании цели и задач объекта управления пользователь должен иметь возможность ввести их вручную или связать их с пунктом справочника Кодификатора целей и задач социально-экономического развития Пермского края.
o Необходимо обеспечить возможность формирования перечня соисполнителей.
o Необходимо обеспечить возможность ввода текстового описания правового обоснования.
o Необходимо обеспечить возможность ввода текстового описания ожидаемого конечного результата.
o Необходимо обеспечить возможность выбора перечня значений из справочника Стратегии СЭР.
o Необходимо обеспечить возможность выбора перечня значений из справочника кодификатора целей и задач социально-экономического развития Пермского края.
o Необходимо обеспечить возможность выбора перечня значений из справочника посланий Президента Российской Федерации.
o Необходимо обеспечить возможность выбора Указа Президента РФ из справочника Указов Президента РФ,
o Необходимо обеспечить возможность выбора перечня значений из справочника докладов губернатора Пермского края.
o Необходимо обеспечить возможность выбора уровня контроля, который должен выбираться из справочника уровней контроля Проектов.
· Блок «Показатели» должен содержать перечень целевых показателей реализации объекта управления. Целевые показатели должны содержать информацию о наименовании, единице измерения, годе, плановом и фактическом значении. При формировании перечня целевых показателей необходимо предоставить пользователю возможность выбрать целевой показатель из значений справочника целевых показателей ИС УГП.
· Блок «Финансирование» должен содержать плановые данные о финансировании в разрезе источников финансирования и годов реализации объекта управления.
Требования к паспортизации проектов типа «Непроектное мероприятие по привлечению федеральных финансовых средств»
Функциональные возможности страницы паспортизации проектов типа «Непроектное мероприятие по привлечению федеральных финансовых средств» (далее - ФФС) должен обеспечивать возможность просмотра и ввода следующей информации:
· Блок «Сводная информация», содержащий сводку по проекту:
o Номер и наименование ФФС.
o Сроки реализации - даты начала и окончания.
o Наименование ИОГВ, ответственного за реализацию ФФС.
· Блок «Основные сведения», содержащий сведения:
o Полное и краткое наименование ФФС и его номер.
o Наименование ИОГВ, ответственного за реализацию ФФС.
o Фамилия, имя и отчество сотрудника, заносящего данные в ИС УГП.
· Блок «План», содержащий План-график в виде иерархической структуры мероприятий, работ и вех объекта управления, формируемый с использованием модуля календарного планирования.
· Блок «Участники объекта управления», содержащий сведения о составе рабочей группы объекта управления и соисполнителей. Рабочая группа представляет собой перечень пользователей, задействованных в реализации объекта управления с указанием их фамилия, имя и отчество и проектной роли.
· Блок «Документы» должен содержать структуру файлов и папок, сопоставленных с объектом управления и формируемую с помощью модуля хранения файлов документов.
· Блок «Процессы», содержащий сведения о текущем состоянии жизненного цикла, а также процессах выполняемых или завершенных по соответствующему проекту, формируемый с помощью модуля исполнения бизнес-процессов.
Требования к модулю календарного планирования
Для блока календарного планирования должен быть разработан веб-интерфейс для работы с иерархической структурой работ объекта управления.
Функциональные возможности модуля должны обеспечивать формирование и отслеживание детального плана реализации объекта управления, в т.ч.:
· Работу с отдельными элементами плана объекта.
· Ввод и хранение атрибутов элементов плана:
o Наименование.
o Идентификатор.
o Статус.
o Порядковый номер в структуре плана.
o Плановые даты начала и окончания.
o Фактические даты начала и окончания.
o Процент завершения.
o Перечень исполнителей из числа участников объекта управления.
o Ответственный исполнитель, выбираемый из справочника организаций, список которых должен быть отфильтрован значениями, указанными в качестве участников объекта.
o Признак вехи объекта.
o Уровень вехи.
o Признак суммарного элемента плана.
o Комментарий.
o Перечень портфелей направлений деятельности организаций для отслеживания хода выполнения работ, выбираемый из соответствующего справочника.
· При вводе данных должен обеспечиваться контроль обязательности отдельных атрибутов и форматно-логический контроль вводимых данных.
· Создание структурной декомпозиции элементов плана. Определение связей между элементами плана типа родитель-потомок.
· Определение последовательности выполнения элементов плана, создание связей между элементами плана типа предшественник-последователь.
· Сохранение базового плана объекта управления.
· Отображение диаграммы Ганта, и анализ выполнения плана на основе заданных базовых значений.
· Формирование плана по шаблону, включающего в себя структурированный перечень работ.
Модуль должен обеспечивать сохранение базового плана как всего календарного плана объекта управления, так и его отдельных задач.
Сохранение базового плана в процессе изменений должно осуществляться только по незавершенным задачам календарного плана и не должно касаться завершенных задач. Это обусловлено тем, что при сохранении базового плана, плановые значения элементов плана копируются в базовые и таким образом происходит сдвиг базовых сроков завершения задач, что недопустимо, т.к. сроки утверждаются соответствующими нормативными документами.
Компонент календарного плана должен обеспечивать возможность настройки дополнительных атрибутов элементов календарного плана и отображения индикаторов элементов плана в соответствии с определенной логикой: просроченные, завершенные, задачи будущих периодов.
Также необходимо обеспечить отображение состояний вех:
· Просрочена - недостигнутая веха.
· В процессе утверждения - по вехе запущен процесс отчетности по исполнению.
· Достигнута - утверждение вехи в процессе отчетности по исполнению завершено и данные актуализированы в проекте.
· Веха будущего периода.
Компонент должен предоставлять возможность настройки отображения календарного плана для режимов ввода и отслеживания данных.
Требования к модулю управления рисками
Модуль должен обеспечивать возможность создавать и отслеживать реестры рисков в рамках блока «Риски» страницы паспортизации и рабочей области объекта управления.
Реестр рисков должен быть организован в виде списка и обеспечивать следующие функции:
· Поиск, фильтрация и сортировка рисков по отображаемым атрибутам
· Регистрация нового риска (создание карточки риска).
· Просмотр карточки риска и изменение атрибутов риска.
Модуль должен обеспечивать возможность просмотра и ввода следующих данных о рисках:
· Наименование риска и его описание.
· Категория риска.
· Ответственный за снятие/минимизацию риска, выбираемый из списка рабочей группы объекта управления.
· Оценка в процентах вероятности возникновения и влияния риска.
· Текстовое описание действий по снятию риска.
· Прикрепление файлов документов к карточке риска.
· Выбор перечня задач плана-графика объекта управления, связанных с риском.
· Признак актуальности риска.
· Признак осуществления риска.
При вводе данных должен обеспечиваться контроль обязательности отдельных атрибутов и форматно-логический контроль вводимых данных.
Возможность добавления, удаления или редактирования рисков должна быть предоставлена пользователям, наделенным правом извлекать и вносить изменения в объект управления.
Требования к модулю хранения файлов документов
Модуль должен обеспечивать хранение, структурирование и сопоставление с данными ИС УГП файлов, загружаемых пользователями в рамках участия в проектной деятельности.
Модуль должен обеспечивать:
· Загрузку файлов в Систему через соответствующий визуальный интерфейс в браузере.
· Централизованное хранение файлов, загружаемых в Систему.
· Сопоставление загруженных файлов с отдельными элементами ИС УГП
· Отображение файлов в настраиваемой структуре папок в следующих разделах ИС УГП:
o Центр документов, отображающий файлы, не сопоставленные с конкретными элементами ИС УГП
o Блок «Документы» паспорта объекта управления, отображающий файлы, сопоставленные с элементами соответствующего объекта управления.
· Поиск и сортировка файлов в списках по отображаемым атрибутам.
· Выгрузка файлов по запросу пользователя.
Требования к реализации личного кабинета пользователя
Пользователи ИС УГП должны получить возможность просмотра сводной информации, касающейся своего участия в проектной деятельности.
Интерфейс личного кабинета должен быть реализован в виде страницы веб-приложения, обеспечивающей персонифицированное представление информации для пользователей разных категорий и предоставляющей следующие возможности, сгруппированные по блокам:
· В правом верхнем углу страницы Личного кабинета должны располагаться фамилия, имя и отчество авторизованного пользователя, его проектная роль, кнопка выхода из системы, статус пользователя - доступен/оформлено замещение.
· Блок статистической информации о количестве назначенных пользователю задач процессов, задач (работ) и вех календарного плана, активных рисков. Информация должна быть представлена в виде визуальных элементов - круговых или секторных диаграмм количества элементов блоков и являться ссылкой на соответствующий блок Личного кабинета.
Перечень блоков Личного кабинета:
o Мои объекты.
o Мои вехи.
o Вехи на контроле.
o Вехи моих объектов.
o Мои задачи.
o Мои риски.
o Замещение.
o Оперативное планирование.
· Блок «Мои объекты», отображающий перечень доступных пользователю объектов управления, участником которых он является, с указанием наименования и роли, а также возможностью открыть страницу паспорта объекта управления.
· Блок «Мои вехи», отображающий перечень вех, на которые пользователь назначен исполнителем, с указанием сроков выполнения и возможностью открыть карточки соответствующих элементов.
Для каждой вехи объекта управления любого типа в перечне должна отображаться следующая информация:
o Наименование вехи.
o Срок исполнения.
o Комментарий.
В перечне вех должна быть реализована возможность маркировки достигнутых вовремя, достигнутых с нарушением сроков и просроченных вех.
Необходимо реализовать возможность оформления отчетности об исполнении вех из этого блока с указанием процента завершения, комментария, возможностью прикрепления документа, указания прогнозных значений и отправки на согласование.
Блок «Вехи на контроле», содержащий перечень вех, ответственным исполнителем которых является орган власти, в котором авторизованный пользователь является руководителем или ответственным за проектное управление. Для каждой вехи перечня должна быть указана следующая информация:
o Наименование вехи.
o Срок исполнения.
o Фактическая дата исполнения.
o Фамилия, имя и отчество ответственного.
o Комментарий.
В перечне вех должна быть реализована возможность маркировки достигнутых вовремя, достигнутых с нарушением сроков и просроченных вех. Вехи должны быть сгруппированы по объектам управления.
Блок должен отображаться только для пользователей, определенных руководителями структурных единиц (ФЦБ, ИОГВ, ФО/ФП) или ответственными за проектное управление в них. Если пользователь одновременно является руководителем двух структурных единиц разных уровней необходимо отображать информацию по организации более высокого уровня. Например, если пользователь одновременно руководитель ФЦБ и руководитель ИОГВ должны отображаться вехи проектов, ответственные исполнители которых включены в это ФЦБ.
· Блок «Вехи моих объектов» - блок, содержащий перечень вех объектов управления в которых авторизованный пользователь является Руководителем или Администратором.
Для каждой вехи перечня должна быть указана следующая информация:
o Наименование вехи.
o Срок исполнения.
o Фактическая дата исполнения.
o Фамилия, имя и отчество ответственного.
o Комментарий.
В перечне вех должна быть реализована возможность маркировки достигнутых вовремя, достигнутых с нарушением сроков и просроченных вех. Вехи должны быть сгруппированы по объектам управления.
· Блок «Мои задачи», в котором приводится перечень поступивших задач процессов с возможностью открыть форму выбранной задачи. Список поступивших пользователю задач должен содержать следующую информацию:
o Наименование задачи.
o Автор задачи.
o Дата поступления задачи.
o Срок исполнения задачи.
Задачи в списке должны быть отсортированы по дате поступления от старых к новым.
· Блок «Мои риски», содержащий перечень назначенных активных рисков с возможностью открыть карточки соответствующих элементов. Список рисков должен содержать следующую информацию:
o Наименование риска.
o Содержание риска.
o Дата наступления риска.
Риски в списке должны быть отсортированы по дате наступления от старых к новым.
· Блок оформления замещения, в котором должна размещаться информация о всех оформленных ранее замещениях пользователя с возможностью оформить новое замещение с использованием модуля оформления замещений.
· Блок «Оперативное планирование» - блок отображения информация о необходимости и сроках формировании документов оперативного планирования с указанием наименования периода, типа документа (Отчет за период, План на период), дат начала и окончания периода, даты закрытия периода, результата формирования отчета.
Каждый блок должен отображать весь список записей списков и иметь вертикальную полосу прокрутки справа.
В каждом блоке должна быть реализована возможность фильтрации записей с использованием фильтра в виде выпадающего списка.
Требования к модулю исполнения процессов жизненного цикла объектов управления
Один из модулей проектируемой системы является модуль исполнения процессов жизненного цикла объектов управления. Этот модуль должен обеспечивать функционирование бизнес-процессов, выполняемых на отдельных этапах жизненного цикла объекта управления.
На протяжении всего жизненного цикла объект управления должен проходить ряд последовательных этапов от инициации до полного завершения:
· Инициация.
· Планирование.
· Исполнение.
· Завершение.
На этапе инициации должны определяться основные параметры объекта управления: наименование, тип объекта управления и его руководитель.
На этапе планирования должны формироваться Паспорт, план-график объекта управления, назначаться ответственные за реализацию мероприятий, выстраиваться иерархическая структура работ, определяться риски, связи и зависимостей между задачами плана-графика.
На этапе исполнения участники проектной деятельности должны реализовывать запланированные мероприятия по достижению вех и отчитываться о достигнутых результатах.
На этапе исполнения также должно осуществляться согласование возможности изменения объекта управления, внесение изменений и согласование внесенных изменений.
На этапе завершения должна осуществляться приемка конечного результата объекта управления либо его прекращение или приостановление. Приостановление объекта управления означает его досрочное завершение с возможностью последующего возобновления. Прекращение объекта управления означает его досрочное завершение без возможности возобновления. Причинами для прекращения или приостановления служат ситуации, возникающие в ходе реализации объекта управления, в результате которых он не может продолжаться.
Модуль должен обеспечивать исполнение бизнес-процессов, соответствующих этапам жизненного цикла объектов управления:
· Разработка.
· Внесение изменений.
· Отчетность по исполнению
В целях обеспечения преемственности и сохранения существующего опыта в сфере проектного управления должны быть использованы существующие в ИАС УП технологические решения по автоматизации исполнения процессов жизненного цикла объектов управления.
Необходимо использовать и модифицировать следующие существующие процессы жизненного цикла объекта управления:
· Процесс разработки объекта управления.
· Процесс отчетности по исполнению.
· Процесс изменения объекта управления.
В каждом процессе должно быть реализовано автоматическое формирование и назначение задач процесса пользователю. О поступлении задачи процесса пользователь должен получать извещения по электронной почте на адрес, указанный в учетных данных пользователя. Список обязательных согласующих, которым в ходе процессов должны назначаться задачи по согласованию должен формироваться в зависимости от органа государственной власти, который является ответственным исполнителем данного объекта управления.
Исполнитель задачи процесса должен иметь возможность перенаправления назначенной ему задачи другому исполнителю из списка пользователей ИС УГП.
Требования к модулю отчетности и мониторинга
Модуль должен обеспечивать формирование аналитической и регламентной отчетности на основе внесенных данных.
Модуль отчетности должен обеспечить возможность автоматизации операции по формированию отчетов «План на период» и «Отчет за период» за каждый отчетный период и размещения сформированных документов в соответствующих папках блока «Документы» страницы паспортизации объекта управления. Автоматизированное формирование Отчетов за период и Планов на период должно осуществляться по объектам управления с типом «дорожная карта», «проект», «непроектное мероприятие», «подпрограмма государственной программы» и быть доступен только Руководителю и Администратору объекта управления.
Периодами оперативного планирования должны являться:
· Для проектов и непроектных мероприятий (кроме непроектных мероприятий по привлечению федеральных финансовых средств): календарная неделя, месяц, квартал, год.
· Для «дорожных карт»: месяц, квартал, год.
· Для подпрограмм государственных программ: квартал, полугодие, год.
По каждому периоду Руководитель или Администратор объекта управления должен иметь возможность сформировать «План на период» и «Отчет за период» нажатием кнопки «Сформировать».
Сформированный документ должен автоматически размещаться в папке с планами и отчетами в рабочей области объекта управления.
Требования к модулю перенаправления задач процессов другим пользователям на период отсутствия исполнителя
С целью своевременного исполнения задач процессов в Системе в период отпусков, временной нетрудоспособности сотрудников органов власти, ответственных за исполнение задач необходимо реализовать механизм замещения пользователей, обеспечивающий автоматическую замену исполнителя задачи процесса на заместителя.
Любое замещение носит временный характер и ограничено датами начала и окончания замещения. Один пользователь может замещать нескольких пользователей. У одного пользователя может быть только один заместитель. В случае создания пользователем, являющимся заместителем, замещения для себя, задачи обоих замещаемых должны поступать пользователю, указанному заместителем заместителя. Пользователь, для которого создано замещение, не может быть указан в качестве заместителя.
Замещение может находиться в одном из трех состояний:
· Запланировано.
· Действующее.
· Завершено.
Созданное замещение считается запланированным, если дата начала замещения еще не наступила. В 00:00:00 даты начала замещение переходит в статус «Действующее». При создании замещения, дата начала которого равна текущей дате, замещение переходит в статус «Действующее» сразу после его сохранения. Действие замещения заканчивается в 23:59:59 даты окончания замещения или в момент принудительной остановки замещения. По окончанию действия завершения оно переходит в статус «Завершенное». Статус присваивается замещению автоматически.
Любой пользователь системы должен иметь возможность создать «Замещение» и назначить заместителя только на себя, а также редактировать замещение только в статусе «Запланированное». Также пользователь может остановить «Действующее» замещение, если он является замещаемым.
· Пользователь, имеющий разрешения для создания замещений для других пользователей, может: Создать замещение и назначить для любого пользователя - любого заместителя, из пользователей ИС УГП.
· Редактировать любое замещение в статусе «Запланированное».
· Редактировать атрибут «Основание» любого замещения в статусе «Действующее» или «Завершённое».
· Остановить любое «Действующее» замещение.
Создание замещения должно происходить при нажатии на кнопку «Оформить замещение» в разделе «Замещение» Личного кабинета.
При нажатии на кнопку «Оформить замещение» должна открываться форма создания замещения.
Поле «Замещаемый» должно заполняться автоматически при создании замещения пользователем, не имеющим специальных разрешений. Пользователь, имеющий разрешения для создания замещений для других пользователей, должен иметь возможность выбрать значение из списка активных пользователей ИС УГП.
· Поле «Заместитель» должно выбираться из списка активных пользователей ИС УГП.
· Поле «Дата начала» должно заполняться пользователем вручную путем ввода значения в поле, либо путем выбора с помощью виджета «Календарь»;
· Поле «Дата окончания» должно заполняться пользователем вручную путем ввода значения в поле, либо путем выбора с помощью виджета «Календарь»;
· Поле «Основание» должно заполняться пользователем вручную путем ввода текста.
После заполнения у пользователя появляется возможность сохранить замещение, нажав кнопку «Сохранить». У пользователя должна быть возможность закрыть форму без сохранения.
Созданное замещение должно быть доступно создавшему его пользователю или пользователю, обладающему специальными разрешениями, для редактирования или удаления до наступления даты начала замещения. После наступления даты начала замещения для редактирования доступно только поле «Основание».
После наступления даты начала замещения все незавершенные задачи процессов, исполнителем которых является замещаемый пользователь, поступают на исполнение его заместителю. Перевод задачи на исполнение другому пользователю не является основанием для продления срока исполнения задачи. Запуск процессов реализации по вехам доступен исполнителю только лично и не может быть совершен его заместителем.
После наступления даты окончания замещения или выборе действия «Остановить замещение», вводе информации о причине остановки замещения и подтверждения остановки процесса активные задачи замещаемого пользователя должны быть автоматически возвращены ему на исполнение.
Требования к техническим и обеспечивающим модулям
К техническим и обеспечивающим модулям относятся:
· Модуль ведения реестра участников проектной деятельности.
· Модуль администрирования.
· Модуль журналирования изменений данных ИС УГП.
· Модуль нотификации пользователей ИС УГП.
Требования к модулю ведения реестра участников проектной деятельности
Модуль предназначен для создания, хранения и редактирования реестра участников проектной деятельности ИС УГП и должен обеспечивать возможность ввода и просмотра следующей информации:
· Сопоставление с пользователем ИС УГП, содержащее следующую информацию, не подлежащую изменению:
o Фамилия, имя и отчество пользователя.
o Логин пользователя.
· Отметка активного статуса участника проектной деятельности в Системе.
· Адрес электронной почты.
· Место работы и должность.
· Группа безопасности в системе в соответствии с заданным уровнем полномочий.
Для каждого участника проектной деятельности должна сохраняться информация о дате и времени последнего подключения к системе.
Изменение данных в реестре участников проектной деятельности должно быть доступно только администраторам системы.
Требования к модулю администрирования
Модуль должен обеспечивать выполнение следующих функций:
· Управление реестром участников проектной деятельности: создание и редактирование карточки участника проектной деятельности в Системе.
· Разграничение прав доступа к данным и функциям ИС УГП.
· Ведение и актуализация справочников и классификаторов.
· Просмотр журналов изменений.
· Просмотр, отслеживание, прекращение запущенных пользователями процессов.
Функции администрирования ИС УГП должны быть доступны только участникам проектной деятельности, входящим в группу полномочий администраторов ИС УГП.
Требования к модулю журналирования изменений данных ИС УГП
Модуль должен обеспечивать контроль и фиксацию изменений в Системе, выполняемых пользователями, хранение информации по изменениям и регламентированный доступ к ней.
Модуль должен обеспечивать выполнение следующих функций:
· Фиксация факта внесения изменений в данные ИС УГП.
· Сохранение данных о наименования измененного объекта, пользователя, вносившего изменения, даты и времени внесения изменений.
· Возможность просмотра журналов изменений в виде списка.
· Поиск и сортировка данных по отображаемым списке атрибутам.
Требования к модулю нотификации пользователей
Модуль должен обеспечивать своевременное извещение пользователей о необходимости выполнения действий в системе с использованием электронной почты.
Модуль должен обеспечивать выполнение следующих функций:
· Извещение пользователей о поступлении задачи процесса по электронной почте в утвержденной форме.
· Извещение пользователей по электронной почте по адресу о приближении срока занесения информации о выполнении вехи. Должно формироваться уведомление в виде электронного письма с вложением в формате pdf. В файле вложения должна содержаться информация о предстоящем исполнении вех и о недостигнутых вехах прошлых периодов. Содержание присылаемой информации должно зависеть от проектной роли:
o Исполнители должны получать уведомления о вехах, находящихся на исполнении в ближайшие дни.
o Руководителям и администраторам должны приходить уведомления о вехах, запланированных на данный период по объектам управления, руководителем или администратором которых они являются.
o Руководители организаций должны получать уведомления о вехах объектов управления, исполнителями которых являются их учреждения.
2.9 Требования к структуре базы данных
На основе сформулированных функциональных требований были разработаны требования к структуре базы данных системы и описаны с использованием диаграмм классов.
Для моделирования структуры данных использовалась платформа Flexberry.
Ниже приведен перечень таблиц базы данных. Подробное описание и атрибутный состав каждой таблицы приведено в Приложении Б.
· Project - таблица, хранящая данные об объекте управления.
· ProjectGoal - таблица, содержащая сведения о целях объекта управления. Связана с Project отношением 1:N.
· ProjectObjective - таблица для хранения данных о задачах объекта управления. Связана с Project отношением 1:N.
· ProjectStakeholder - для хранения данных о заинтересованных сторонах объекта управления. Связана с Project отношением 1:N.
· ProjectResources - таблица, предназначенный для хранения данных об участниках рабочей группы объекта управления. Связана с Project отношением 1:N.
· ProjectFinance - таблица для хранения сведений о финансировании объекта управления. Связана с Project отношением 1:N.
· ProjectKPI - для хранения данных о показателях достижения целей и задач объекта управления. Связана с Project отношением 1:N.
· Task - таблица, содержащая сведения о задаче календарного плана объекта управления. Этот таблица является дочерней по отношению к «Project».
· Assignment - таблица для хранения данных о назначениях по каждому элементу календарного плана. Каждой записи сопоставлена запись «Task».
· ProgressReport - таблица для хранения данных о результатах сформированных отчетах об исполнении задач календарного плана. Каждой записи сопоставлена запись Assignment. Т.е по каждому назначению предполагается формирование минимум одного отчета.
· ProgressApproval - таблица, предназначенная для хранения данных о результатах согласования каждого отчета об исполнении. Ссылается на ProgressReport.
· TaskLink - таблица для хранения данных о связях между задачами календарного плана.
· ProjectRisk - таблица для хранения сведений о рисках объекта управления. Ссылается на Project.
· TaskRisk - таблица для хранения данных о связях риска объекта управления с задачей календарного плана и степени влияния на нее. Ссылается на ProjectRisk и Task.
· User - класс для хранения учетных данных о пользователе: его логин, фамилия, имя, отчество.
· Person - класс для хранения сведений об участниках проектной деятельности. Ссылается на User.
· Resource - сведения о ресурсах, используемых в проектной деятельности. Ссылается на Person.
· OrganizationUnit, содержащий данные об органах власти, задействованных в проектной деятельности.
· Substitution - таблица, содержащая данные о замещениях участника проектной деятельности.
· ProjectType - таблица, содержащая перечень типов объектов управления. Справочник.
· TaskType - таблица-справочник с перечнем типов задач календарного плана.
· ProjectStatus - таблица-справочник с перечнем статусов, который приобретает объект управления в ходе своего жизненного цикла.
· ProjectStage - таблица-справочник с перечнем стадий, которая присваивается объекту управления в ходе процессов жизненного цикла.
· КодификаторЦелейИЗадач - иерархический справочник, содержащий структуру целей и задач социально-экономического развития Пермского края.
· СтратегияСЭР - иерархический справочник, содержащий структуру Стратегии социально-экономического развития Пермского края.
· УказыПрезидентаРФ -справочник, содержащий перечень указов Президента РФ.
· ПосланиеПрезидента - иерархический справочник, содержащий структуру посланий президента РФ.
· ДокладыГубернатораПк - справочник, содержащий иерархическую структуру докладов губернатора Пермского края.
Выводы по второй главе
В ходе анализа бизнес-процессов управления проектами, действующими в ИАС УП, были разработаны их модели AS IS, которые были проанализированы. Были сформулированы рекомендации по их модернизации. На основе проведенного анализа были разработаны модели процессов TO BE с учетом рекомендаций.
Разработаны требования к реализации процесса разработки объекта управления, процессу внесения изменений в объект, процессу отчетности об исполнении с учетом исправления «узких мест», обнаруженных на этапе анализа.
В ходе сбора и систематизации требований были сформулированы функциональные требования, предъявляемые к Системе, которые были описаны с использованием диаграммы прецедентов.
На основе этих требований разработаны требования к структуре базы данных и описаны с использованием диаграмм классов.
Подобные документы
Автоматизация ряда бизнес-процессов библиотеки Арбитражного суда Пермского края с использованием технологии "клиент-сервер". Проектирование пользовательского интерфейса, диаграммы прецедентов. Разработка серверной части, создание и заполнение БД.
курсовая работа [2,9 M], добавлен 27.02.2016Моделирование бизнес-процессов как средство поиска путей оптимизации деятельности компании. Методология SADT (структурный анализ и проектирование), семейство стандартов IDEF и алгоритмические языки в основе методологий моделирования бизнес-процессов.
реферат [21,7 K], добавлен 14.12.2011Администрация Бодайбинского городского поселения как объект исследования, ее структура и направления деятельности. Описание унифицированного языка моделирования UML, разработка бизнес-процессов в его диаграммах. Описание и главные функции GRM-систем.
курсовая работа [1,1 M], добавлен 02.06.2015Анализ деятельности компании в целом и отдела продаж в частности. Описание состояния информационной системы предприятия. Декомпозиция бизнес-процессов, протекающих в отделе продаж. Проектирование информационной системы, ее программное обеспечение.
дипломная работа [2,4 M], добавлен 29.08.2014Создание модели бизнес-процессов "Распродажа" в ВPwin. Цели и правила распродажи. Прогнозирование бизнес-процессов ППП "Statistica". Методы анализа, моделирования, прогноза деятельности в предметной области "Распродажа", изучение ППП VIP Enterprise.
курсовая работа [2,4 M], добавлен 18.02.2012Современное состояние создание отчетов на предприятиях. Обоснование создания системы. Анализ предметной области, системный и структурный анализ. Существующие формы отчетности в УВО. Разработка инфологической и концептуальной схемы БД.
дипломная работа [70,4 K], добавлен 19.06.2006Анализ организационной структуры и деятельности предприятия. Разработка диаграмм бизнес-процессов AS-IS, TO-BE. Характеристика этапов пакетов работ для внедрения автоматизированной информационной системы. Определение состава участников проекта и их задач.
курсовая работа [3,3 M], добавлен 21.01.2015Архитектура интегрированных информационных систем ARIS как методология моделирования бизнес-процессов, преимущества и недостатки использования. Выбор бизнес-процесса для моделирования и его содержательное описание, табличный формат его описания.
курсовая работа [2,2 M], добавлен 19.06.2015Сущность, значение и методика проведения моделирования бизнес-процессов. История развития методологий моделирования. Систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме для аналитической обработки полученной информации.
реферат [409,3 K], добавлен 29.04.2009Информационной обеспечение и информатизация бизнес-процессов предприятия ОАО "Управляющая компания крупнопанельное домостроение". Анализ оснащенности организации вычислительной техникой, программным обеспечением. Состояние информационной безопасности.
отчет по практике [712,3 K], добавлен 18.01.2014