ВР.pdf. Реферат Магистерская
 Скачать 3.61 Mb.
|
|
Реферат Магистерская диссертация 66 с., 41 рис., 2 приложения, 15 источников. ОЦЕНКА 360 ГРАДУСОВ, SCALA, PLAY, ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ, АНАЛИЗ ТРЕБОВАНИЙ Цель работы — разработать программную систему для оценки персонала по методу «360 градусов». Результат работы — разработана и внедрена система для оценки персонала по методу «360 градусов» 2 Содержание Введение 4 Глоссарий 6 1 Определение и фиксация требований 7 1.1 Нефункциональные требования 7 1.2 Функциональные требования 8 1.3 Формализация и анализ требований 9 2 Проектирование 15 2.1 Диаграмма предметной области 15 2.2 Контекст системы 19 2.3 Разбиение на подсистемы 20 2.4 Схема база данных 22 2.5 API-Приложение 23 2.6 Исполнитель задач 30 3 Процесс разработки 50 3.1 Документирование API 50 3.2 Особенности тестирования 52 3.3 Непрерывная интеграция и доставка 54 Заключение 59 Литература 60 Приложение А. Скриншоты интерфейса 62 Приложение Б. Скриншоты отчета 64 3 Введение В сознании большинства людей каждый человек обладает некоторым набором качеств, которые и определяют его индивидуальность. Сейчас распространен другой подход: здесь более важным считается не обладание качеством, а профессиональная эффективность. Важно, чтобы, помимо обладания качествами, способностями, умениями и навыками, человек умел направить их на решение задач, стоящих перед компанией. Именно в этом контексте используются все современные способы оценки персонала. Оценить навыки можно множеством разных способов: тестовыми методиками, интервью, деловыми играми, наблюдением за работой человека в течение нескольких рабочих дней. Помимо этого существует метод 360 градусов, который был предложен Питером Уордом в 1987 году. Первое определение, которое он дал этому методу: «Оценка 360 градусов» — это систематический сбор информации о работе индивидуума (или группы), получаемой от некоторого числа лиц, заинтересованных в его работе, и обратная связь по ней. Изначально процесс оценки был построен на бумажных анкетах, составляемых вручную и раздаваемых сотрудникам, но в настоящее время существует более удобный и быстрый способ проведения оценки, с помощью автоматизированных компьютерных систем. Этот способ пользуется популярностью в настоящее время, более 90% компаний из Fortune Global 500 пользуются этим методом. Но его используют 1 не только крупнейшие компании, фирмы малого и среднего размера также заинтересованы в данном способе оценивания. Одна из местных фирм решила внедрить эту методику в свой рабочий процесс. Существующие программные решения не подошли либо из-за 1 Fortune 500 — рейтинг 500 крупнейших мировых компаний, критерием составления которого служит выручка компании 4 отсутствия необходимого функционала, либо из-за высокой стоимости проведения исследования. В связи с этим было решено разрабатывать свою систему оценки, которая должна полностью удовлетворить все нужды и быть достаточно гибкой, для того чтобы её можно было использовать и в других организациях. В связи с этим можно сформулировать цель работы — разработать программную систему для оценки персонала по методу «360 градусов». Из цели вытекают следующие задачи: ● составить диаграмму предметной области; ● проанализировать варианты использования; ● спроектировать систему; ● реализовать систему; ● подготовить документацию; ● настроить непрерывную интеграцию и доставку. 5 Глоссарий Компетенция — умение, качество или способность человека, существенно влияющее на его эффективность в работе. Пользователь — это участник системы, которому доступны события оценки, способный оценивать других пользователей в рамках события оценки, и являющийся объектом оценки для других. Администратор — это пользователь, наделенный правами для управления системой. Группа — это логическое объединение пользователей по какому-либо признаку. Форма — это список вопросов. Событие оценки — это множество проектов, назначенных для оценки на определенный период времени, в котором участники (пользователи) дают ответы на вопросы о сотрудниках и в общем о событиях в компании. Проект — это совокупность объединений типа «оценивающая группа — форма вопросов — оцениваемая группа». Каждое такое объединение — это отношение проекта. Отношение проекта — это смысловая основа события оценки. Оно определяет, кто кого по какой форме вопросов оценивает. 6 1 Определение и фиксация требований Данная глава посвящена сбору и формализации требований. Так как разрабатываемая система имеет конкретного заказчика, то работы по сбору требований велись именно с ним. Представленные ниже требования разбиты на функциональные и нефункциональные. Изначально требования представляются в том виде, в котором их указал заказчик. Далее же требования были обработаны, переформулированы и формализованы в виде диаграмм и сценариев вариантов использования. 1.1 Нефункциональные требования ● Реализовать систему в виде веб приложения. ● Реализовать серверную часть системы с использованием языка программирования Scala. ● Построить приложение с использованием Play Framework в качестве каркаса. ● Использовать PostgreSQL в качестве СУБД. ● Для аутентификации использовать учетную запись Google с помощью OAuth2 . 2 ● Производить развертывание используя Docker . 3 ● Иметь документацию API. ● Покрыть систему модульными тестами. ● Реализовать систему в общем виде, без привязки к конкретным организационным ограничениям, для возможности внедрения в других компаниях. 2 OAuth — открытый протокол авторизации 3 Docker — программное обеспечение для автоматизации развёртывания и управления приложениями 7 1.2 Функциональные требования В данном разделе представлены функциональные требования к разрабатываемой системе, разбитые по актерам. Первым делом рассмотрим функциональные возможности актера Пользователь. Пользователь — это участник системы являющийся объектом оценивания, либо выполняющий оценку других пользователей в качестве субъекта. Система должна поддерживать следующий функционал для него: ● возможность внести информацию о себе; ● возможность прикрепить своё изображение; ● возможность просмотреть список событий оценки, прошедшие, будущие и текущие, в которых Пользователь является субъектом оценивания; ● возможность произвести оценку коллег по предложенным формам в текущем событии; ● возможность посмотреть свои ответы в прошедших событиях; ● возможность увидеть список всех пользователей в системе. Следующий актер — это Администратор. Администратор — это пользователь, наделенный дополнительными правами для управления сущностями в системе. Функционал выглядит следующим образом: ● возможность пригласить Пользователя в систему; ● возможность читать, создавать, обновлять и удалять следующие типы объектов: ○ пользователь; ○ группа; ○ проект; ○ форма; ○ прочее. 8 Следующий актер взаимодействующий с системой — это Аудитор. Аудитор — это лицо, получающее доступ к результатам оценки, для их анализа и совершения необходимых организационных действий. Возможности аудитора: ● просмотреть результат оценки в агрегированном виде; ● просмотреть результат оценки в детальном виде. Для этого результаты оценивания должны экспортироваться в формате электронной таблицы и быть загружены на Google Drive. Доступ к этим файлам для аудитора должен быть предоставлен автоматически. 1.3 Формализация и анализ требований После того, как требования, предоставленные заказчиком, были собраны и обработаны, была проведена работа по их формализации, приведению к стандарту представления — вариантам использования. На рисунке 1.3.1 представлена диаграмма вариантов использования актёра пользователь. Основным вариантом использования является «Произвести оценку коллег». Рисунок 1.3.1 — Диаграмма вариантов использования актера Пользователь 9 Далее будут рассмотрены сценарии архитектурно значимых вариантов использования для актёра Пользователь в форме текстовой спецификации Алистера Кобёрна. Таблица 1.3.1 — Описание и сценарий варианта использования «Внести информацию о себе» Название ВИ Внести информацию о себе Цель Заполнить профиль Пользователя информацией Актер Пользователь Предусловия 1. Пользователь авторизован. 2. Пользователь находится на странице деталей своего профиля. Сценарий 1. Пользователь нажимает на кнопку «Редактировать». 2. Система открывает страницу редактирования профиля. 3. Пользователь вносит изменения: a. имя; b. email; c. пол; d. часовой пояс. 4. Пользователь нажимает на кнопку «Загрузить изображение профиля» 5. Система открывает диалоговое окно для загрузки изображения с компьютера. 6. Пользователь выбирает новый файл и подтверждает действие. 7. Система закрывает диалоговое окно. 8. Пользователь нажимает на кнопку «Сохранить изменения» 9. Система выполняет верификацию данных. 10. Система сохраняет информацию в БД. Расширения 8.1. Введенные пользователем данные не прошли валидацию. 8.1.1 Система отмечает, какие поля введены некорректно или были пропущены. 8.1.2 Пользователь исправляет введенные данные. 10 Таблица 1.3.2 — Описание и сценарий варианта использования «Произвести оценку коллег» Название ВИ Произвести оценку коллег Цель Отправить свою оценку в систему Актер Пользователь Предусловия 1. Пользователь авторизован. 2. Пользователь состоит хотя бы в одном из событий оценки, которое находится в статусе «В процессе». 3. Пользователь находится в разделе «События оценки». Сценарий 1. Пользователь нажал на кнопку «Начать оценку» напротив выбранного события оценки. 2. Пользователь выбирает пользователя в списке оцениваемых. 3. Пользователь выбирает вкладку с проектом. 4. Система открывает список пользователей требующих оценки. 5. Пользователь выбирает пользователя в списке оцениваемых. 6. Система открывает форму с вопросами. 7. Пользователь вводит все необходимые ответы. 8. Пользователь нажимает на кнопку «Сохранить и перейти к следующей форме». 9. Система открывает следующую форму для пользователя. Расширения 7.1. Пользователь на заполнил одно из обязательных полей. 7.1.1. Система подсвечивает поле красным, кнопка «Сохранить и перейти к следующей форме» неактивна. 8.2. Пользователь находится на последней форме проекта. 8.2.1 Система открывает первую форму для первого пользователя в следующем проекте. 8.3 Пользователь находится на последней форме последнего проекта. 8.3.1 Система отображает кнопку «Сохранить и завершить оценку». 8.3.2 Пользователь нажимает на кнопку. 8.3.3 Система открывает раздел «События оценки» 11 Рассмотрим варианты использования актёра Администратор. Рисунок 1.3.2 — Диаграмма вариантов использования актера Администратор Администратор может пользоваться всеми вариантам использования Пользователя, но помимо этого имеет доступ к управлению объектами в системе. Диаграмма изображена на рисунке 1.3.2. В таблице 1.3.3 приведен сценарий варианта использования «Пригласить пользователя в систему». Таблица 1.3.3 — Сценарий варианта использования «Пригласить Пользователя в систему» Название ВИ Пригласить пользователя в систему Цель Пригласить пользователя в систему Актер Администратор Предусловия 1. Пользователь с ролью «Администратор» авторизован в системе. 2. Администратор находится на странице «Приглашения» Сценарий 1. Администратор нажимает на кнопку «Пригласить пользователей». 2. Система открывает страницу «Отправить приглашения». 12 3. Администратор заполняет поля a. email; b. группы. 4. Администратор нажимает на кнопку «Отправить приглашения». 5. Система отправляет приглашение на введенный адрес. 6. Система открывает страницу «Приглашения» Альтернативный сценарий 1 1. Администратор переходит на страницу деталей группы. 2. Администратор нажимает на кнопку «Пригласить Пользователей» в секции «Пользователи, состоящие в группе» 3. Система открывает страницу «Отправить приглашения» 4. Администратор заполняет поле email. 5. Администратор нажимает на кнопку «Отправить приглашения». 6. Система отправляет приглашение на введенный адрес. 7. Система открывает страницу деталей группы. 13 На рисунке 1.3.3 представлена диаграмма вариантов использования актёра Аудитор. Аудитор не взаимодействует с системой напрямую, просмотр отчета производится на стороннем сервисе, в который система должна предварительно загрузить результат. Рисунок 1.3.3 — Диаграмма вариантов использования актера Аудитор 14 2 Проектирование 2.1 Диаграмма предметной области На основании построенных диаграмм вариантов использования была спроектирована и зафиксирована диаграмма предметной области в форме диаграммы классов. Данная диаграмма фиксирует предметную область разрабатываемой системы и не привязана к классам реализации. Рисунок 2.1.1 — Диаграмма классов модели предметной области Рассмотрим рисунок 2.1.1 подробнее. Класс Пользователь хранит информацию о зарегистрированных в системе пользователях. Пользователи являются как субъектами, так и объектами оценивания. Класс имеет следующие атрибуты: ● почта — email, используемый для отправки уведомлений; ● имя — ФИО, отображаемое в процессе оценки и в отчетах; ● пол — мужской, женский; ● роль — Пользователь, Администратор; 15 ● статус — Новый, Активный. Новых пользователей нельзя добавить в событие оценки, требуется предварительная активация; ● часовой пояс — используется для отображения дат и времени в локальном часовом поясе пользователя; ● аватар — идентификатор загруженного файла с изображением. Пользователи могут быть включены в одну или несколько Групп. Группа — это логическое объединение пользователей по какому-либо признаку. Группы имеют название и могут вкладываться друг в друга, образуя древовидную иерархию. Событие оценки определяется названием и датой/времени начала и окончания. Пока Событие оценки активно, пользователи имеют возможность отвечать на вопросы о коллегах. В Событие оценки должны быть включены Проекты. Проект — это набор информации о том, по каким формам группы оценивают друг друга, и разрешена ли самооценка пользователя, в случае если он находится и в оцениваемой, и в оценивающей группах. Атрибут «анонимные ответы» у Проекта определяет, есть ли у пользователя в этом проекте возможность произвести оценку анонимно. К событию оценки могут быть привязаны уведомления, отправляемые в определенное время, содержащие текст и получателя (Пользователь или Аудитор). Форма — это набор вопросов. Она имеет название и состоит из различных типов вопросов (Открытый, Альтернативный). Каждый вопрос имеет текст и подсказку, используемую как пояснение для отвечающего. Открытый вопрос имеет атрибут «многострочность», используемый для определения внешнего вида текстового поля. Альтернативный вопрос может иметь вид Радиокнопок или Флажков. Помимо этого для Альтернативного вопроса можно задать Компетенцию и набор Альтернатив, каждая из которых содержит текст и числовое значение Компетенции. Это значение используется 16 для расчета среднего значения по каждой Компетенции при генерации отчета для пользователя. Приглашение хранит в себе информацию о почте, на которую оно было отправлено, а также код, содержащийся в ссылке в письме, по которому регистрируемый пользователь будет идентифицирован. Каждое приглашение может быть связано с несколькими группами, пользователь, который активировал приглашение, будет добавлен в них автоматически. После активации текущая дата должна быть записана в атрибут «дата активации». 17 Для описания семантики сущностей на рисунке 2.1.2 приведена диаграмма объектов. Рисунок 2.1.2 — Пример диаграммы объектов На рисунке 2.1.2 представлены пользователи, трое из которых состоят в проекте под названием «Отдел разработки». Двое из них являются разработчиками, один — менеджер. Помимо этого в системе присутствует пользователь с ролью «Администратор», имеющие права на создание групп, проектов, событий оценки. Администратор создает создает событие оценки, в которое включает проект «Отдел разработки». В проекте заранее было создано отношение «Менеджеры» оценивают «Разработчиков» по форме «Оценка сотрудников менеджерами». Форма состоит из двух вопросов, первый подразумевает выбор одного варианта из предложенных, ответ на второй является простым текстом, вводимым в текстовое поле. К первому вопросу привязана компетенция «Инициативность», а, соответственно, к альтернативам — численные значения этой компетенции. 18 2.2 Контекст системы Разрабатываемая программа должна взаимодействовать с двумя внешними системами: ● сервис e-mail рассылок — для отправки писем; ● Google Диск/Таблицы — для загрузки и хранения отчетов. Согласно требованиям существуют три Актера: ● Пользователь; ● Администратор; ● Аудитор. Для определения того, как актеры взаимодействуют с системой, и как разрабатываемый инструмент взаимодействует с внешними системами на рисунке 2.2.1 приведена диаграмма, демонстрирующая контекст. Рисунок 2.2.1 — Диаграмма контекста системы 19 2.3 Разбиение на подсистемы Рассмотрим составляющие системы оценки (см. рисунок 2.2.1) подробнее. Для реализации была выбрана архитектура с одностраничным приложением, предоставляющим пользовательский интерфейс, API приложением содержащим в себе бизнес логику и имеющим REST интерфейс, 4 который используется одностраничным приложением. Помимо этого выделена отдельная подсистема, которая выполняет фоновые задачи при наступлении определенных событий. Для взаимодействия между приложениями используется шина сообщений, для сохранения состояния используется реляционная база данных. На рисунке 2.3.1 приведена диаграмма, показывающая выделенные подсистемы, вместе с языками и технологиями, применяемыми для реализации. Помимо этого там представлены виды взаимодействий между подсистемами, с указанием протокола. Контекст разрабатываемой системы выделен пунктирным прямоугольником. Одностраничное приложение разрабатывалось другой командой, и его реализация не рассматривается в данной работе. 4 REST — архитектурный стиль взаимодействия компонентов распределенного приложения в сети 20 Рисунок 2.3.1 — Диаграмма подсистем 21 |