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

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

Оглавление

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.5 Классы Project Server

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

Выводы

Заключение

Библиографический список

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

Приложение Б. Диаграмма вариантов использования

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

Приложение Г. Техническое задание

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ходе проектирования системы создаются модели представления системы. Различают функциональные модели и объектно-ориентированные модели. Функциональные модели создаются в виде диаграмм методологий 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).

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

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

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

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

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

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

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

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

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

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

.        Система должна поддерживать инкрементные (итерационные) модели жизненного цикла (ОТр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

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

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

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

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

Таблица 1.2

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

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

Таблица 1.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1.4

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