Для реализации поставленных целей информационная система должна отвечать следующим функциональным требованиям:
- централизация данных в едином хранилище - базе данных;
- автоматизация процесса тестирования и выдачи результатов;
- удобство в построении графиков на основе статистики;
- автоматизация сбора внутренней статистики;
- разграничение ролей и доступа для пользователей системы; - взаимодействие интерфейсов с базой данных системы.
1.4.2 Требования к надежности
Информационная система должна отвечать требованиям безопасности и надежности. Эти требования должны достигаться за счет заранее продуманных и разработанных прав доступа (ролей), разграничивающих доступ пользователей к информации. Пользователям группы «Гость» должны предоставляться возможности просмотра имеющейся статистики и возможность прохождения тестирования, но доступ к статистике, собираемой приложением, должен быть строго запрещен. Пользователям групп «Администратор» должен быть обеспечен доступ ко всей информации, такой, как справочники, константы или перечисления.
На основании созданных ролей должны быть построены графические интерфейсы пользователей, с одной стороны, способствующие достижению безопасности и надежности, с другой стороны, облегчающие работу пользователей.
1.4.3 Требования к информационной и программной совместимости
Информационная система должна обеспечивать информационную совместимость с основными приложениями под управлением операционной системы Windows (Word, Excel, Access). Программная совместимость обеспечивается автоматически в связи с использованием программных средств, совместимость которых обеспечена конструктивно (на этапе их создания) - платформа Borland C++ Builder. Система реализуется для операционной системы Windows.
1.4.4 Требования к техническому и программному обеспечению
Информационная система ориентирована для использования на персональных компьютерах класса IBM PC, начиная с Pentium II, объем оперативной памяти 1 Гб и свободного места на жестком диске 200Мб.
Программные требования: Windows ХР, Vista, 7, 8, 8.1.
Основное программное требование серверной части подсистемы является наличие программных продуктов: Borland C++ Builder, IBExpert.
1.5 Анализ существующих информационных систем
Для разработки наиболее адекватной информационной системы не следует пренебрегать опытом и достижениями других разработчиков в рамках данной области, так как разработка системы, которая не сможет конкурировать с имеющимися на рынке - обречена на провал. Поэтому следует досконально изучить подобные информационные системы и выявить их преимущества и недостатки.
В процессе подробного изучения предметной области были рассмотрены следующие сайты, предлагающие свои услуги в сфере профессиональной ориентации:
- Профориентация - сайт, на котором возможно пройти тест на профориентацию. Тестирование происходит в режиме онлайн. Данный сайт ориентирован, прежде всего, на школьников, которые хотят оценить свои профессиональные предпочтения.
Ресурс предлагает пользователю тест: Опросник профессиональной готовности [33].
- ПрофГид - также представляет собой веб-сайт, с расположенными на нем методиками тестирования: карта интересов, методика профессионального самоопределения Дж. Голланда, тест Климова [34].
- Учеба.ру - на основе ответов на вопросы ресурс определяет сферы интересов, личные и профессиональные особенности и предлагает список наиболее подходящих профессий [42].
Ресурс предлагает пользователю такие тесты как: карта интересов, мотивация.
- Новосибирский государственный педагогический университет, Институт рекламы и связи с общественностью - ресурс предлагает абитуриентам прохождение тестирования «Профориентационный тест», основу которого составляет тест направленности личности [28].
- Тест на профориентацию - на данном сайте можно пройти комплексное онлайн-тестирование, направленное на определение профессиональных предпочтений. Тест будет интересен всем желающим, которые хотят узнать, к каким профессиям они испытывают наибольшую склонность.
Комплекс включает в себя следующие тесты: дифференциальнодиагностический опросник(тест Климова), опросник профессиональной готовности, опросник профессиональной направленности Д. Голанда [39].
Основываясь на полученной в процессе анализа информации, можно с уверенностью сказать, что существующие ресурсы для профессиональной ориентации не могут конкурировать с разработанной информационной системой, ввиду того, что данная система предназначена для использования конкретным вузом, а имеющиеся системы имеют более широкую направленность
В итоге, первая глава посвящена общей характеристике предметной области. В ней также проведен анализ предприятия и были построены диаграммы «КАК ЕСТЬ». В данной главе рассматривается структура университета в целом, и устанавливаются общие требования к будущему программному средству.
2. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ
2.1 Выбор методологии проектирования
В основе проектирования для любой информационной системы лежат технологии, методологии и инструментальные средства проектирования. Методология реализуется посредством конкретных технологий и поддерживающих их стандарты, методики и инструментальные средства. Ими обеспечивается выполнение процессов проектирования. Таким образом, правильный выбор методологи крайне важен для дальнейшей разработки.
- Методология Microsoft Solutions Framework. Данная методология разработки была предложена корпорацией Microsoft.
Основные этапы MSF:
- формулирование,
- планирование,
- разработка,
- стабилизация, - внедрение.
Фаза внедрения продолжается вплоть до момента, когда продукт становится прибыльным. Для каждой из фаз задаются результаты и зоны ответственности. К процессу разработки предлагается интерактивный подход. Пока не внедрено решение, оно не будет считаться законченным. Для стратегии версионирования предполагается первоначально реализация основного функционала, и только потом доработка дополнений в новых версиях.
Проектная группа включает в себя шесть ролевых кластеров, каждый из которых обладает личной зоной ответственности: разработка, тестирование, удовлетворение заказчика, управление программой, управление выпуском, управление продуктом. Команда насчитывает от трех до десяти человек. В проекте отсутствует должность менеджера проекта, а ответственность распределена на лидеров каждой из ролей [11].
- Dynamic Systems Development Method - метод разработки динамических систем (DSDM). В его основе лежит концепция быстрой разработки приложений (RAD). Она представляет из себя инкрементный и итеративный подход, в которых участие пользователя играет важную роль. Как правило, DSDM используется для проектов информационных систем, характеризующимися сжатыми сроками и бюджетами. Основными методиками методологии DSDM:
Тайм-боксинг предполагает подразделение целого проекта на составляющие части, имеющие каждая свой бюджет, требования и срок выполнения, распределенные по принципу MoSCoW. Так как время и бюджет строго регламентированы, то остается возможным только изменение требований. Если возникает ситуация, при которой проект не может уложиться в бюджет или график , то требования, обладающие наименьшим приоритетом опускаются. Что соответствует принципу 20/80.
Метод MoSCoW определяет путь распределения объектов по различным приоритетам. Must - такое требование обязано соответствовать экономическим нуждам. Should - следует ли реализовывать это требование, если успех проекта от него не зависит. Could - необходимо ли оставлять это требование, в случае если оно не имеет влияния на деловую потребность проекта. Would - можно ли перенести выполнение требования, если имеется время.
Прототипирование - это создание прототипов системы в процессе разработки на ранних этапах. Это позволяет определить слабые места в системе и позволит ее тестирование будущими пользователями.
Тестирование - проведение тестов системы для каждой итерации.
Моделирование с целью визуализиования в виде диаграмм той части системы, с которой продолжается работа.
Достоинствами этого метода можно назватьмалый объем
документирования, быстрое получение результата и раннее тестирование. Недостатками же можно назвать невозможность применения DSDM к тем проектам, где нельзя применить принцип 20/80. К таким системам относятся те, в которых более важна безопасность данных. Информационная система вуза необходима для оперирования персональными данными, поэтому вопрос безопасности является одним из актуальных. Таким образом, применение в разработке информационной системе вуза методологии DSDM возможно лишь фрагментарно.
- Экстремальное программирование. Основными идеями экстремального программирования (ХР), в контексте процесса проектирования являются:
Разработка через тестирование. Определяют приемочное тестирование и тестирование модулей. Разработчиком исследуется правильность кода с помощью выполнения для модуля всех тестов, приемочным тестированием является удовлетворение всех требований заказчика. Объектом тестирования при проектировании является модель разрабатываемой системы, такие как: объектная, субъектная, процессная, тестируемые на полноту, непротиворечивость, неизбыточность и адекватность. В отличие от ХР, где сначала пишется тест, а затем составляется по нему код, при проектировании первоначально определяются функциональные требования и информация, характеризующая объект, и затем проектируется удовлетворяющая им модель.
Игра в планирование. Осуществляется разграничение ответственности: то есть, заказчик следит за принятием бизнес-решений, которые фиксируются в виде функциональных требований, а разработчиком принимаются лишь технические решения. Данный подход возможно полностью перенести в процесс проектирования.
Парное программирование. Суть его в том, что код модуля пишется двумя программистами совместно, они заменяют друг друга. После чего пары меняются, поэтому, получается, что каждый разработчик свободно владеет кодом, что позволяет им вносить в него модификации (рефакторинг), таким образом, интеграция осуществляется непрерывно, без видимых затруднений. При применении подхода к проектированию роль кода модуля играет разрабатываемая модель или ее декомпозиция. Под рефакторингом понимается процесс изменения содержания модели без измения ее функций и содержащейся в ней информации. При использовании парного проектирования осуществляется коллективное владение моделями системы и становится возможной выработка стандарта проектирования, т.е. нотации, правила представления информации, внесения изменения, точки зрения проектирования, интерфейсов и т.д.
Частые небольшие релизы. Роль релиза в процессе разработке может играть эскизный проект, предназначенный для конечного пользователя.
Главное отличие XP от других методологий заключается в том, что заказчик обязан находиться постоянно на связи и быть доступным для вопросов при условии взаимозаменяемости членов команды.
Достоинством может считаться совместное владение практически всеми моделями проекта, что крайне важно в процессе проектирования. Правда, недостатком будет являться возможность одного из членов команды вносить изменения в модель без согласования с остальными. Данная проблема в ХР решается путем тестированием, однако, при проектировании выявить ошибки становится намного труднее.
- SCRUM. Другой вариант подобной гибкой методологии для управления процессом разработки информационной системы - это Scrum. Он осуществляется за счет итераций. Итерация в Scrum имеет название сприт. Любые пожелания заказчика или функциональные требования будут хранится в резерве проекта, будучи отсортированными по степени важности. В начале каждого из спринтов выносится на обсуждение список функций и задач, подлежащих реализации, так формируется резерв спринта. В процессе реализации спринта цели и требования спринта не подлежат изменению, однако, если цели потеряли свою актуальность или невозможно их выполнение в срок, то процесс можно остановить.
За счет краткости спринтов достигается гибкость, как правило, проект длится от двух до четырех недель. Сотрудничество с заказчиком осуществляется посредством совещания по выбору списка очередных задач для спринта. В процессе работы по проектированию в Scrum используются несколько типов совещаний для команды разработчиков. Как правило, в начале спринта формируется резерв спринта и определяются технические вопросы по его реализации. Каждый день предоставляется отчет по результатам работы и возникшим в процессе проблемам. На стадии завершении спринта происходит демонстрация результатов и анализируется работа команды.
В Scrum-методологии предусмотрено шесть ролей, разделенных на две группы: пользователи: управляющие персоналом, клиенты, экспертыконсультанты; и разработчики: владелец проекта, скрам-мастер, команда.
Среди достоинств методологии можно выделить быстрые сроки разработки, систему организации труда, тесную и строго определенную работу с заказчиком. К недостаткам можно отнести отсутствие определения общей модели в фазах создания проекта. Это приводит к тому, что при реализации части системы возможен момент, когда будет требоваться изменение наибольшей части из созданных для реализации оставшихся функций.