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

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

Оглавление

• Введение
• Глава 1. Анализ бизнес-процесса управления учебным процессом
• 1.1 Проектирование корпоративных информационных систем
• 1.2 Описание объекта управления
• 1.2.1 Выявление и анализ бизнес-требований
• 1.2.2 Моделирование процесса «AS IS»
• 1.3 Анализ заинтересованных лиц
• 1.3.1 Выявление пользовательских требований
• Выводы по разделу
• 1.4 Формализация выявленных требований
• 1.5 Построение модели процесса управления «TO BE»
• Глава 2. Проектирование информационной системы управления учебным процессом
• 2.1 Выявление системных требований
• 2.2 Описание архитектуры системы
• 2.3 Диаграммы последовательностей проектируемой системы
• 2.4 Диаграмма классов и диаграмма сущность-связь системы
• 2.5 Классы Project Server
• 2.6 Планирование очередности реализации
• Выводы
• Заключение
• Библиографический список
• Приложение А. Анкета для заинтересованных лиц разработки системы
• Приложение Б. Диаграмма вариантов использования
• Приложение В. Описание прецедентов
• Приложение Г. Техническое задание

Введение

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

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

Объект исследования - бизнес-процесс управления учебным процессом на примере дисциплины «Управление программными проектами»

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

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

1. Провести анализ предметной области.

2. Описать объект управления и построить модели учебного процесса «AS IS».

3. Провести анализ заинтересованных сторон.

4. Разработать и формализовать требования к информационной системе.

5. Построить модель учебного процесса «TO BE».

6. Построить модель архитектуры системы.

7. Разработать техническое задание.

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

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

Глава 1. Анализ бизнес-процесса управления учебным процессом

В данной главе будет выполнен анализ предметной области, на основе которого будет построена модель «AS IS» процесса управления дисциплиной. Так же будут выявлены заинтересованные лица разработки информационной системы, интервьюирование и анкетирование которых позволить выявить требования к разрабатываемой информационной системе. Выявленные и формализованные требования позволят построить модель процесса «TO BE».

1.1 Проектированиекорпоративных информационных систем

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

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

Главная задача корпоративной информационной системы - эффективное управление всеми ресурсами. Корпоративные информационные системы отличаются от информационных систем функциональностью и областью автоматизации. В то же время, довольно сложно определить четкую границу между ними. Главная цель корпоративной системы - повышение эффективности работы, для достижения этой цели решаются такие задачи как объединение информации в одном информационном пространстве, повышение оперативности обмена качественной информацией, повышение скорости принятия управленческих решений и снижение рисков за счет обработки достоверной входной информации [8].

Проектирование корпоративной информационной системы включает в себя несколько основных этапов [10]:

1. Анализ предметной области.

2. Определение специфики деятельности в предметной области.

3. Выявление бизнес-процессов предметной области.

4. Структурно-логический анализ деятельности.

5. Формирование функциональных требований к системе.

6. Конструирование концептуальной модели системы.

В ходе проектирования системы создаются модели представления системы. Различают функциональные модели и объектно-ориентированные модели. Функциональные модели создаются в виде диаграмм методологий IDEF0, IDEF3 и DFD. В данной работе функциональные модели нотации IDEF0 используются для представления процессов управления дисциплиной «AS IS». Объектно-ориентированный подход описывает систему в терминах объектов и связей между этими объектами, а поведение системы - это обмен сообщениями между объектами. Для построения объектно-ориентированных моделей используется язык моделирования UML, который содержит набор диаграмм и нотаций. В данной работе используется диаграмма вариантов использования для моделирования пользовательских требований к системе и диаграмма активности для моделирования сценария использования системы пользователями [6].

Комбинация объектно-ориентированного моделирования и функционального моделирования позволяет взглянуть на разрабатываемую систему с разных подходов и точек зрения.

1.2 Описание объекта управления

По дисциплине «Управление программными проектами» предусмотрена аудиторная работа и самостоятельная работа. Аудиторная работа включает в себя лекции и практические занятия, которые проводятся в форме, предполагающей активное участие студентов в работе, обсуждении и анализе предлагаемых проблем и решений. На аудиторных занятия проводится командная разработка проекта - работа в группах по 3-4 студента над одним проектом. В процессе изучения дисциплины формируется умение работать в коллективе, способность применять существующие стандарты разработки приложений и оформления документации к ним.

Дисциплина читается на 3 и 4 курсах, включает в себя 396 часов, из которых 286 часов отводится на самостоятельную работу.

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

Основные компетенции, которые формируются в процессе изучения дисциплины - это способность планировать и организовывать проектную деятельность на основе стандартов управления проектами, способность обрабатывать, анализировать и систематизировать информацию, ставить цель и выбирать пути ее достижения, способность знать и уметь использовать инструментальные средства, в частности MS Project 2010, способность работать в кооперации с коллегами, использовать в своей деятельности нормативно-правовую документацию [12].

1.2.1 Выявление и анализ бизнес-требований

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

1. Работа с системой должна стать дополнительной практикой проектной деятельности (БТр1).

2. Система должна быть эффективной, то есть снизить временные затраты как преподавателя, на раздачу и сбор заданий, так и студента на сдачу отчетов, а не увеличить их (БТр2).

3. Процесс сбора отчетов о выполнении лабораторных работ должен происходить в информационной среде близкой к предметной области проектного управления (БТр3).

4. Для развертывания информационной системы необходимо использовать аппаратно-программное обеспечение, существующее в университете (БТр4).

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

Требование БТр1является функциональным требованием. Данное требование носит очень общий характер и нуждается в уточнении.

Требование БТр2 является нефункциональным требованием, - оно относиться к качеству выполнения своих возможностей. Требование должно быть рассмотрено при разработке дополнительных требований к системе.

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

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

1.2.2 Моделирование процесса «AS IS»

Построение модели «AS IS» производится в следующих целях:

· выявление требований;

· преобразование бизнес-требований в пользовательские.

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

Рисунок 1.1 Учебный процесс дисциплины «Управление программными проектами»

Проведение практического занятия можно рассматривать как минимум с двух точек зрения - с точки зрения студента (рис. 1.2) и с точки зрения преподавателя (см. рис. 1.3).

Рисунок 1.2 Практическое занятие с точки зрения студента

Рисунок 1.3 Практическое занятие с точки зрения преподавателя

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

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

В системе LMS размещаются материалы по дисциплине в качестве дистанционной поддержки.

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

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

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

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

1. Система должна содержать функцию создания заданий (ОТр1).

2. Система должна подразумевать, как минимум, два типа пользователей: преподаватели и студенты (ОТр2).

3. Система должна позволять ограничивать функциональные возможности пользователей разных типов (ОТр3).

4. Система должна хранить характеристики заданий (ОТр4).

5. Система должна позволять хранить сопровождающие (методические) материалы дисциплины (ОТр5).

6. Система должна осуществлять сбор выполненных заданийпо правилам проектных форм деятельности (ОТр6).

7. Преподаватель и студент должны иметь возможность обмениваться сообщениями друг с другом через систему (ОТр7).

8. Система должна автоматизировать раздачу и сбор заданий (ОТр8).

9. Система должна поддерживать инкрементные (итерационные) модели жизненного цикла (ОТр9).

Слабыми звеньями процесса «AS IS», по мнению заказчика, являются этапы раздачи заданий и сбора результатов. Поэтому для устранения этих недостатков выдвигаются требования ОТр6, ОТр9.

Требования ОТр1, ОТр2, ОТр4, ОТр5, ОТр7, ОТр8 являются производными от БТр1.

Требования ОТр6, ОТр9 является производным от БТр3.

Требование ОТр3 является нефункциональным. Оно зафиксировано, но рассмотрено будет позднее.

Все эти требования являются слабо детерминированными. Далее они будут разрабатываться подробнее.

1.3 Анализ заинтересованных лиц

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

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

Составим карту заинтересованных сторон (рис. 1.4).

Степень влияния	Поддерживать интерес - Слушатели	Сотрудничать - Слушатели Лектор, Практик
	Наблюдать - Слушатели	Держать в курсе - Слушатели
	Интерес к проекту

Рисунок 1.4 Карта заинтересованных сторон

Каждому сектору карты присвоим ценность мнения для проекта (таблица 1.1). Ценность мнения определяется субъективно, опираясь на экспертное мнение.

Таблица 1.1

Ценность мнений лиц по секторам карты

Сектор	Ценность
Поддерживать интерес	2
Наблюдать	1
Сотрудничать	4
Держать в курсе	3

Классифицируем самую многочисленную группу «Слушатели» относительно оценки по десятибалльной шкале, полученной по курсу (рис. 1.5).

Посещаемость	5-6 Поддерживать интерес	9-10 Сотрудничать
	4 Наблюдать	7-8 Держать в курсе
	Заинтересованность в результатах

Рисунок 1.5 Карта заинтересованных сторон слушателей курса

Каждому сектору карты «Слушатели» присвоим ценность мнения для проекта в баллах (таблица 1.2). Ценность мнения так же определяется субъективно, опираясь на экспертное мнение.

Таблица 1.2

Ценность мнений слушателей курса по секторам карты

Сектор	Ценность
4	0,1
5-6	0,2
7-8	0,3
9-10	0,4

Сопоставим группы слушателей курса по оценкам с группами общей карты заинтересованных сторон и получим итоговую ценность мнений всех заинтересованных лиц (таблица 1.3).

Таблица 1.3

Ценность мнений лиц по группам

Группа заинтересованных лиц	Ценность
Лектор	4
Практик	4
Слушатель, которого необходимо держать в курсе, с оценкой 7-8	0,3*3 = 0,9
Слушатель, чей интерес нужно поддерживать, с оценкой 5-6	0,2*2 = 0,4
Слушатель, за которым необходимо наблюдать, с оценкой 4	0,1*1 = 0,1
Слушатель, с которым необходимо сотрудничать, с оценкой 9-10	0,4*4 = 1,6

1.3.1 Выявление пользовательских требований

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

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

На основе ответов были выявлены следующие пользовательские требования к информационной системе:

1. Работа с системой должна стать дополнительной практикой в освоении проектных форм деятельности (ПТр1).

2. Автоматизировать процесс выдачи заданий на выполнение лабораторных работ (ПТр2).

3. Автоматизировать процесс сбора отчетов о выполнении лабораторных работ слушателями дисциплины (ПТр3).

4. Система должна представлять собой единую информационную среду, в которой могут работать и слушатели, и преподаватели курса (ПТр4).

5. Система должна иметь функцию прикрепления дополнительных учебно-методических материалов к заданию лабораторных работ или к проекту выполнения работ (ПТр5).

6. Каждое задание должно иметь ограниченные сроки на выполнение. Система должна предоставлять возможность автоматически завершать задачи по окончанию определенных сроков (ПТр6).

Уточнение требований БТр1, БТр3, ОТр1-ОТр9, ПТр1-ПТР6 у заинтересованных лиц позволило конкретизировать содержание требований. Требования были переформулированы в терминах управления проектами:

1. Работа с системой должна стать дополнительной практикой в освоении проектных форм деятельности (ПТр1):

1.1 Система должна хранить характеристики заданий (ОТр4): время начала и окончания работ, объем работ (трудозатраты), содержание работ, назначенные трудовые ресурсы, взаимосвязи с другими работами, оценка (ФТр1).

1.2 Система должна хранить завершенные проекты для анализа и сбора статистики (ФТр2).

2. Автоматизировать процесс выдачи заданий на выполнение лабораторных работ (ПТр2):

2.1 С помощью системы можно создать проекты для лабораторных работ по предопределенным шаблонам (ФТр3).

2.2 Задания студенту назначаются преподавателем в форме работы в проекте, на которую студент назначен как трудовой ресурс (ФТр4).

2.3 Для задач должна иметься возможность задавать определенные сроки начала и окончания. Система должна автоматически завершать задачи по окончанию определенных сроков(ФТр5).

3. Автоматизировать процесс сбора отчетов о выполнении лабораторных работ слушателями дисциплины (ПТр3).

3.1 При сдаче работы студентом проставляется отметка о выполнении с прикреплением к ней результатов выполнения (ФТр6).

3.2 Преподаватель должен иметь возможность оценить ход выполнения работ по проекту, как для каждого из студентов, так и для всей группы (ФТр7).

3.3 Преподаватель должен иметь возможность сравнить план выполнения работ с фактическим состоянием проекта (ФТр8).

4. Система должна представлять собой единую информационную среду, в которой могут работать и слушатели, и преподаватели курса (ПТр4).

4.1 Преподаватель в системе выполняет роли руководителя ресурсов и руководителя проектов (ФТр9).

4.2 Студент в системе играет роль трудового ресурса, назначенного на проект (ФТр10).

4.3 Студенты должны быть заранее внесены в списки трудовых ресурсов (ФТр11).

4.4 Преподаватель и студент могут обмениваться друг с другом сообщениями через систему (комментарии к задаче, сообщение на электронной доске объявлений и т.п.) (ФТр12).

5. Система должна позволять хранить сопровождающие (методические) материалы дисциплины (ОТр5):

5.1 Система должна иметь функцию прикрепления дополнительных учебно-методических материалов к заданию лабораторных работ или к проекту выполнения работ (ПТр5).

5.2 Дополнительные методические материалы должно быть можно публиковать в системе (ФТр13).

6. Каждое задание должно иметь ограниченные сроки на выполнение. Система должна предоставлять возможность автоматически завершать задачи по окончанию определенных сроков (ПТр6).

Выводы по разделу

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

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

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

1.4 Формализация выявленных требований

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

Поведение системы с точки зрения пользователя представлено диаграммой вариантов использования (Приложение Б). Данная диаграмма является графическим изображением пользовательских требований к системе. Основные пользователи системы - студенты и преподаватели. Прецеденты делятся на 4 большие группы: работа с теоретическими материалами, работа с оценкой и комментариямик заданиям, автоматизация сбора отчетов и автоматизация выдачи заданий.

Сопоставим функциональные требования к системе с прецедентами (см. табл. 1.4).

Таблица 1.4

Прецеденты и функциональные требования

Требование	Субъект	Прецедент
Задания студенту назначаются в форме работы в проекте, на которую студент назначен как трудовой ресурс (ФТр4)	Преподаватель	Создание заданий на выполнение лабораторных работ
Система должна хранить характеристики заданий: время начала и окончания работ, объем работ (трудозатраты), содержание работ, назначенные трудовые ресурсы, взаимосвязи с другими работами, оценка (ФТр1)	Преподаватель	Описание атрибутов задания
Система должна хранить проекты для анализа и сбора статистики (ФТр2)	Информационная система	Сбор отчетов о выполнении заданий
Для задач должна иметься возможность задавать определенные сроки начала и окончания (ФТр5)	Преподаватель	Определение сроков выполнения
Преподаватель должен иметь возможность оценить ход выполнения работ по проекту, как для каждого из студентов, так и для всей группы (ФТр7)	Преподаватель	Просмотр прогресса выполнения задания
Преподаватель должен иметь сравнить план выполнения работ с фактическим состоянием проекта (ФТр8)	Преподаватель	Просмотр прогресса выполнения задания
С помощью системы можно создать проекты для лабораторных работ по предопределенным шаблонам (ФТр3)	Преподаватель	Создание проекта «Выполнение лабораторных работ»
Дополнительные методические материалы должно быть можно публиковать в системе (ФТр13)	Информационная система	Доступ к материалам
	Преподаватель	Размещение материалов
	Студент	Использование материалов
Задания студенту назначаются преподавателем в форме работы в проекте, на которую студент назначен как трудовой ресурс (ФТр4)	Информационная система	Выдача заданий исполнителям
	Преподаватель	Создание проекта «Выполнение лабораторных работ»
	Студент	Получение задания на выполнение
При сдаче работы студентом проставляется отметка о выполнении с прикреплением к ней результатов выполнения (ФТр6)	Информационная система	Сбор отчетов о выполнении заданий
	Студент	Сдача отчетов о выполнении заданий
Для задач должна иметься возможность задавать определенные сроки начала и окончания. Система должна автоматически завершать задачи по окончанию определенных сроков (ФТр5)	Информационная система	Контроль сроков сдачи отчетов

Подробное описание каждого прецедента представлено в приложении В.

Формализованные требования к системе позволяют провести моделирование процесса «ТО ВЕ». Модель процесса управления дисциплиной «ТО ВЕ», будет получена путем внесения изменений и совершенствования модели «AS IS».

1.5 Построение модели процесса управления «TO BE»

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

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

Опишем работу системы и пользователей с системой с помощью диаграммы активности (см. рис. 1.7).

Рисунок 1.6 Процесс выполнения лабораторной работы в состоянии «как должно быть»

Рисунок 1.7 Диаграмма активности

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

После построения сценария использования системы и определения пользовательских требований к системе необходимо выявить системные требования.

Таким образом, в первой главе работы были выявлены бизнес-требования, которые были проанализированы и стали основой для построения модели процесса управления «AS IS». Бизнес-требования были преобразованы в высокоуровневые пользовательские требования. Затем были выявлены все заинтересованные лица разработки, которые впоследствии были опрошены для дополнения пользовательских требований к системе. Высокоуровневые пользовательские требования к системе позволили определить функциональные требования к системе. Формализованные требования позволили построить модель «TO BE» процесса управления дисциплиной, а так же изобразить алгоритм работы пользователей с системой посредством диаграммы активностей. В процессе работы над главой разрабатывались разделы технического задания на разработку информационной системы (Приложение В).

автоматизация управление учебный лабораторный

Глава 2. Проектирование информационной системы управления учебным процессом

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

2.1 Выявление системных требований

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

Требование БТр4, представленное в форме ограничения, сужает выбор программных средств до имеющихся в распоряжении НИУ ВШЭ систем управления проектами на основе Microsoft Project. В распоряжении университета имеется:

1. Microsoft Project Standard.

2. Microsoft Project Professional.

3. Microsoft Project Server.

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

Таблица 2.1

Анализ ограничений требования БТр4

Критерий сравнения средств	Project Standard	Project Professional	Project Server
Работа с системой должна стать дополнительной практикой в освоении проектных форм деятельности (ПТр1)	Не выполняется	Не выполняется	Выполняется
Система должна хранить характеристики заданий: время начала и окончания работ, объем работ (трудозатраты), содержание работ, назначенные трудовые ресурсы, взаимосвязи с другими работами, оценка (ФТр1)	Выполняется	Выполняется	Выполняется
Система должна хранить завершенные проекты для анализа и сбора статистики (ФТр2)	Не выполняется	Не выполняется	Выполняется
Автоматизировать процесс выдачи заданий на выполнение лабораторных работ (ПТр2)	Не выполняется	Не выполняется	Выполняется
С помощью системы можно создать проекты для лабораторных работ по предопределенным шаблонам (ФТр3)	Выполняется	Выполняется	Выполняется
Задания студенту назначаются преподавателем в форме работы в проекте, на которую студент назначен как трудовой ресурс (ФТр4)	Выполняется	Выполняется	Выполняется
Для задач должна иметься возможность задавать определенные сроки начала и окончания. Система должна автоматически завершать задачи по окончанию определенных сроков (ФТр5)	Выполняется	Выполняется	Выполняется
Автоматизировать процесс сбора отчетов о выполнении лабораторных работ слушателями дисциплины (ПТр3)	Не выполняется	Не выполняется	Выполняется
При сдаче работы студентом проставляется отметка о выполнении с прикреплением к ней результатов выполнения (ФТр6)	Не выполняется	Не выполняется	Выполняется
Преподаватель должен иметь возможность оценить ход выполнения работ по проекту, как для каждого из студентов, так и для всей группы (ФТр7)	Выполняется	Выполняется	Выполняется
Преподаватель должен иметь сравнить план выполнения работ с фактическим состоянием проекта (ФТр8)	Выполняется	Выполняется	Выполняется
Система должна представлять собой единую информационную среду, в которой могут работать и слушатели, и преподаватели курса (ПТр4)	Не выполняется	Выполняется	Выполняется
Преподаватель в системе выполняет роли руководителя ресурсов и руководителя проектов (ФТр9)	Не выполняется	Выполняется	Выполняется
Студент в системе играет роль трудового ресурса, назначенного на проект (ФТр10)	Выполняется	Выполняется	Выполняется
Студенты должны быть заранее внесены в списки трудовых ресурсов (ФТр11)	Не выполняется	Выполняется	Выполняется
Преподаватель и студент могут обмениваться друг с другом сообщениями через систему (комментарии к задаче, сообщение на электронной доске объявлений и т.п.) (ФТр12)	Не выполняется	Не выполняется	Выполняется
Система должна позволять хранить сопровождающие (методические) материалы дисциплины (ОТр5)	Не выполняется	Не выполняется	Выполняется
Дополнительные методические материалы должно быть можно публиковать в системе (ФТр13)	Не выполняется	Не выполняется	Выполняется
Система должна иметь функцию прикрепления дополнительных учебно-методических материалов к заданию лабораторных работ или к проекту выполнения работ (ПТр5)	Не выполняется	Не выполняется	Выполняется
Каждое задание должно иметь ограниченные сроки на выполнение. Система должна предоставлять возможность автоматически завершать задачи по окончанию определенных сроков (ПТр6)	Выполняется	Выполняется	Выполняется
ИТОГО по таблице	Не выполняется	Не выполняется	Выполняется

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

В таблице 2.2 представлены результаты анализа реализуемости системных требований с учетом системных ограничений, выраженных в БТр4.

Таблица 2.2

Анализ ограничений требования БТр4

Входящее функциональное требование	Поддерживающее системное требование
Система должна хранить характеристики заданий: время начала и окончания работ, объем работ (трудозатраты), содержание работ, назначенные трудовые ресурсы, взаимосвязи с другими работами, оценка (ФТр1). Для задач должна иметься возможность задавать определенные сроки начала и окончания. Система должна автоматически завершать задачи по окончанию определенных сроков (ФТр5). При сдаче работы студентом проставляется отметка о выполнении с прикреплением к ней результатов выполнения (ФТр6). Автоматизировать процесс сбора отчетов о выполнении лабораторных работ слушателями дисциплины (ПТр3).	Характеристики задач: время начала и окончания работ, объем работ (трудозатраты), содержание работ, назначенные трудовые ресурсы, взаимосвязи с другими работами, процент выполнения - могут быть сохранены в системе управления проектами (СТр1).
	Оценка выполнения работы, как пользовательский информационный атрибут работы (настраиваемое полое задачи), может быть сохранен системой управления проектами (СТр2).
	КСУП Project Server позволяет реализовать модель управления жизненным циклом проекта, модель внутреннего документооборота проектной команды через механизм внедрения рабочих процессов. Рабочие процессы представляют собой приложение для SharePoint, которое можно разработать c помощью Microsoft Visual Studio (СТр3).
Система должна хранить завершенные проекты для анализа и сбора статистики (ФТр2).	Корпоративное хранилище Project Server позволяет хранить проекты и проводить их анализ на основе OLAP-технологий (СТр4).
С помощью системы можно создать проекты для лабораторных работ по предопределенным шаблонам (ФТр3).	КСУП Project Server позволяет создавать проекты по предопределенным шаблонам, загруженным в базу веб-приложения PWA (СТр5).
Задания студенту назначаются преподавателем в форме работы в проекте, на которую студент назначен как трудовой ресурс (ФТр4). Преподаватель в системе выполняет роли руководителя ресурсов и руководителя проектов (ФТр9). Студент в системе играет роль трудового ресурса, назначенного на проект (ФТр10). Студенты должны быть заранее внесены в списки трудовых ресурсов (ФТр11). Автоматизировать процесс выдачи заданий на выполнение лабораторных работ (ПТр2). Автоматизировать процесс сбора отчетов о выполнении лабораторных работ слушателями дисциплины (ПТр3).	Учетная запись студента может быть загружена в корпоративный пул ресурсов из справочников Active Directory. Затем в общем порядке, как трудовой ресурс, он может быть назначен на любую задачу. Преподавателю может быть назначена роль менеджера ресурсов. После назначения трудового ресурса на задачу ему предоставляется доступ к необходимым инструментам в персонализированной информационной среде (СТр6).
Преподаватель должен иметь возможность оценить ход выполнения работ по проекту, как для каждого из студентов, так и для всей группы (ФТр7). Преподаватель должен иметь сравнить план выполнения работ с фактическим состоянием проекта (ФТр8).	Корпоративное хранилище проектов Project Server и приложение Project Professional позволяют оценить выполнение проектов. Инструменты отслеживания хода исполнения проекта позволяют сравнивать базовый и фактический варианты проекта (СТр7).
Преподаватель и студент могут обмениваться друг с другом сообщениями через систему (комментарии к задаче, сообщение на электронной доске объявлений и т.п.) (ФТр12). Система должна позволять хранить сопровождающие (методические) материалы дисциплины (ОТр5). Дополнительные методические материалы должно быть можно публиковать в системе (ФТр13). Работа с системой должна стать дополнительной практикой в освоении проектных форм деятельности (ПТр1). Система должна представлять собой единую информационную среду, в которой могут работать и слушатели, и преподаватели курса (ПТр4).	Веб-приложение Project Server предоставляет всем участникам проектного процесса доступ к общей информационной среде. Освоение приемов работы в этой среде позволит приобрести навыки работы в проекте (СТр8).

Из таблицы 2.2 видно, что все требования выполняются. Microsoft Project Server может быть использован для разработки системы. Требования, выработанные, в ходе анализа являются системными и могут быть применены далее при проектировании. А так же использование Microsoft Project удовлетворяет требованиям учебного плана дисциплины, в соответствии с которым студенты изучают этот программный продукт на практических занятиях [15].

Системные требования преобразуются в следующую системную спецификацию:

o Оперативная память 24 Гб.

o 64-разрядный 4-х ядерный процессор.

o Место на жестком диске - 80 ГБ для системного диска и 100 ГБ для второго и дополнительных дисков.

o Microsoft Windows Server 2016 Standard.

o Microsoft SQL Server 2014 Enterprise.

o Microsoft SharePoint Server 2016Enterprise.

Начиная с версии 2016-го года Microsoft Project Server входит в состав Microsoft SharePoint Server, как сервисное приложение, доступное в корпоративной редакции продукта.

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

2.1 Описание архитектуры системы

С учетом использования Project Server для реализации управления учебным процессом дисциплины изобразим архитектуру данной системы (см. рис. 2.1).

Система базируется на Windows Server, на котором развертывается SharePoint Server и SQL Server. Работа пользователя с системой осуществляется посредством любого имеющегося браузера.

Рисунок 2.1 Архитектура системы

2.3 Диаграммы последовательностей проектируемой системы

Изобразим использование системы пользователями с помощью диаграммы последовательностей (см. рис. 2.2).

Рисунок 2.2 Диаграмма последовательности

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

Прецедент создания проекта «Выполнение лабораторных работ» состоит из определения сроков проекта, даты начала и окончания проекта, а так же определения задач, которые будут входить в проект (рис. 2.3).

Рисунок 2.3 Диаграмма последовательности создания проекта

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

Рисунок 2.4 Диаграмма последовательности формирования задания

Прецедент «Контролировать сроки выполнения задания» осуществляет постоянное сравнение текущей даты с датой окончания задачи. Если дата окончания не наступила, то система принимает отчеты по выполненным заданиям (рис. 2.5), в противном случае прием отчетов блокируется (см. рис. 2.6).

Рисунок 2.5 Диаграмма последовательности контроля сроков с активным приемом отчетов

Рисунок 2.6 Диаграмма последовательности контроля сроков с блокировкой приема отчетов

2.4 Диаграмма классов и диаграмма сущность-связь системы

Для удовлетворения предъявленных к системе требований составим укрупненную диаграмму классов системы (см. рис. 2.7).

Рисунок 2.7 Диаграмма классов

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

Рисунок 2.8 Диаграмма сущность-связь

Учитывая принятое ранее решение об использовании Project Server для управления проведения практических работ в форме лабораторных работ, необходимо проверить реализованы ли необходимые классы в Project Server.

2.5 Классы Project Server

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

1. Admin. Содержит методы, используемые на страницах администрирования ProjectServer в ProjectWebApp. Определяет финансовый год, управляет параметрами отчетов о состоянии и валют, отчетными периодами, журналом аудита и параметрами для ActiveDirectory.

2. Archive. Содержит методы для управления резервным копированием и восстановлением проектов, категорий безопасности, настраиваемых полей, ресурсов, системных параметров, представлений и корпоративного глобального проекта. Читает и обновляет план архивации. Архивирует все проекты или удаляет указанные архивированные проекты. Сохраняет резервные копии объектов в таблицах архивной базы данных и восстанавливает архивные объекты в таблицах опубликованной базы данных.

3. Calendar. Управляет исключениями корпоративного календаря. Извлекает и возвращает календари ресурсов. Создает, удаляет, перечисляет, обновляет или возвращает исключения календаря.

4. Events. Управляет связями с обработчиками событий. Содержит методы CRUD для связей обработчиков событий Project Server для конкретного события или для всех связей обработчиков событий.

5. LoginForms. Предоставляет методы Login и Logoff с проверкой подлинности на основе форм. Доступ к службе LoginForms возможен только на внутреннем сайте ProjectWebApp.

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

7. PortfolioAnalyses. Содержит методы CRUD для зависимостей проекта, а также для решений по оптимизатору, планировщику и анализу.

8. Project. Управляет проектами. Извлекает, возвращает, создает, удаляет, читает или обновляет проекты в таблицах черновиков или в опубликованных таблицах базы данных Project. Создает или удаляет сущности в проектах (задачи, ресурсы, назначения и т. п.) Извлекает сведения или обновляет группу проекта или адрес сайт проекта. Извлекает состояние проекта, список проектов в таблицах черновиков, все суммарные задачи, задачи, которые можно назначить указанному ресурсу, или все проекты, в которых ресурс имеет назначения. Создает обязательства и управляет ими, создает проектные инициативы и проекты из списков задач SharePoint, а также обнаруживает отношения «проект-главный проект».

9. QueueSystem. Управляет очередью Project Server. Извлекает счетчик заданий, время ожидания задания или группы заданий, состояние всех заданий, указанные задания, задания, принадлежащие вызывающему объекту, или задания для указанных проектов. Управляет корреляцией заданий и настраивает очередь.

10. Resource. Управляет корпоративными ресурсами. Извлекает, возвращает, обновляет или создает ресурсы или пользователей Project Server и их параметры авторизации; обнаруживает ресурсы по имени или GUID; читает данные ресурса или пользователя, а также структурную декомпозицию ресурсов (RBS) и соответствующие сведения о безопасности; извлекает все назначения для ресурса; сбрасывает пароли пользователей. Класс Resource содержит методы CRUD для делегирования пользователей.

11. Statusing. Управляет обновлениями состояния и назначениями. Применяет обновления состояния или утверждения, отправляет обновления состояния, устанавливает сводные сведения для отправленных обновлений, удаляет утвержденные обновления состояния или историю утверждений для конкретного пользователя, а также удаляет все сведения о состоянии для ряда проектов. Создает, извлекает или делегирует назначения; устанавливает длительность работ назначения. Извлекает новые назначения для текущего пользователя; извлекает журнал назначений или транзакций задач, повременные фактические данные или иерархию суммарных задач. Выполняет предварительный просмотр или импорт данных расписания или читает рабочее и нерабочее время пользователя. Находит ожидающие обновления состояния, сведения для отправленных обновлений или запись транзакции изменений в отправленном обновлении. Читает состояние группы.

12. TimeSheet. Управляет расписаниями. Содержит методы CRUD для расписаний и отправляет или отзывает расписания. Находит просроченные или ожидающие утверждения расписания; выполняет поиск расписаний по дате или периоду. Извлекает список утверждающих расписания. Предварительно загружает фактические данные расписания и проверяет строку расписания. Класс Time Sheet содержит методы Read Project Timesheet Lines и Submit Timesheet Lines для чтения и отправки расписаний для другого ресурса без необходимости олицетворения.

13. Workflow. Содержит методы CRUD для типов корпоративных проектов и для управления этапами и стадиями рабочих процессов. Запускает рабочие процессы, устанавливает сведения о состоянии и управляет стадиями страниц сведений о проекте (PDP) в рабочих процессах с управлением запросами. Чтобы разрабатывать рабочие процессы Project Server, разработчики могут использовать Share Point Designer 2013 для декларативных рабочих процессов или использовать Инструменты разработчика Office для VisualStudio 2012 для разработки с помощью.NET Framework 4 и класса Microsoft. ProjectServer. Client. Workflow Activities в CSOM.

14. WssInterop. Управляет сайты проекта. Создает и удаляет сайты проекта. Извлекает сведения о параметрах SharePoint и сайтах администрирования и обновляет их. Синхронизирует и обновляет членства и группы сайт проекта.

2.6 Планирование очередности реализации

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

Вес требования = Ктреб. Ч , где

Ктреб. - Коэффициент требования (табл. 2.3);

- Сумма коэффициентов авторов требования;

- оценка требования по десятибалльной шкале от заинтересованного лица.

Таблица 2.3

Коэффициенты требований по типу

Тип требования	Коэффициент
Пользовательское	3
Общее	4
Функциональное	3

Итоговый вес каждого требования предъявленного к системе представлен в таблице 2.4.

Таблица 2.4

Вес требований к системе

Требование	Коэффициент требования	Оценка требования	Вес автора требования	Итоговый вес требования
ОТр4	4	9	4	144
ФТр1	3	9	4	139,2
		9	0,1
		8	0,4
		7	0,9
ФТр2	3	7	4	84
ФТр3	3	9	4	108
ФТр4	3	8	4	96
ФТр5	3	9	4	108
ПТр3	3	9	4	120,3
		8	0,4
		9	0,1
ФТр6	3	8	4	96
ФТр7	3	9	4	108
ФТр8	3	7	4	84
ПТр4	3	8	4	159,3
		7	1,6
		8	0,1
		7	0,4
		7	0,9
ФТр9	3	6	4	72
ФТр10	3	6	4	72
ФТр11	3	4	4	48
ФТр12	3	4	4	49,5
		5	0,1
ОТр5	4	6	4	130,8
		6	0,4
		7	0,9
ПТр5	3	6	4	98,1
		6	0,4
		7	0,9
ФТр13	3	6	4	98,1
		6	0,4
		7	0,9
ПТр6	3	9	4	108

На основе веса требований выделим две очереди работ: в первую войдут требования с весом более 100 баллов, во вторую остальные требования (табл. 2.5).

Таблица 2.5

Очереди реализации требований

Очередь первая	Очередь вторая
Порядковый номер	Требование	Баллы	Порядковый номер	Требование	Баллы
1	ПТр4	159,3	1	ПТр5, ФТр13	98,1
2	ОТр4	144	2	ФТр4, ФТр6	96
3	ФТр1	139,2	3	ФТр2, ФТр8	84
4	ОТр5	130,8	4	ФТр9, ФТр10	72
5	ПТр3	120,3	5	ФТр12	49,5
6	ФТр7, ФТр5, ФТр3, ПТр6	108	6	ФТр11	48

Полученный порядок очередности реализации служит основой для разработки раздела «Стадии и этапы разработки» ТЗ (Приложение Г).

Выводы

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

С помощью MS Project преподаватель дисциплины составляет корпоративный проект дисциплины «Управление программными проектами». Для создания проекта пользуется заготовленным шаблоном. Прописывает в проекте все задачи, сроки, назначает на задачи ресурсы-студентов групп. Затем публикует созданный проект на Project Server.

Project Server создает сайт проекта. Предоставляет доступ к сайту ресурсам проекта. Сопоставляет список ресурсов с корпоративными пользователями и направляет на их персональные страницы назначенные задания.

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

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

На рисунке 2.9 изображена модель процесса с использованием технологий Project Server. Выдача заданий и сдача отчетов происходит через сайт проекта выполнения лабораторных работ. Обмен сообщениями между преподавателем и студентом так же осуществляется через систему. Процесс выполнения заданий студентами динамически отображается на прогрессе завершения всего проекта.

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

Рисунок 2.9 Модель процесса выполнения и сдачи заданий лабораторной работы

Заключение

В ходе работы был проведен анализ предметной областии описан объект управления. Со стороны заказчика были выявлены бизнес-требования к системе, которые послужили основой для моделирования процесса «AS IS» и, в конечном итоге, основой для составления программы приемо-сдаточных испытаний.