Версия для печати - Техническое задание по разработке информационной системы.

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

Общая информация:

1) Информационная система (далее ИС) должна иметь возможность использования на следующих программных платформах (операционных системах):

Microsoft Windows NT4/2000/XP/Vista/Seven (7);
Ubuntu Linux версии 8.04 и выше;
Arta Linux 1.0;
Поддержка мобильной платформы JavaME рекомендуется к реализации, в случае ее отсутствия, необходимо предусмотреть возможность дальнейшей доработки;

1.1) Поддержка ОС реализуется без использования дополнительного ПО, в частности: эмуляторов, виртуальных машин, трансляторов бинарного кода. Данное ограничение необходимо для обеспечения полной и предсказуемой работоспособности. Пункт не распространяется на версию для JavaME в виду технических ограничений;

1.2) Разработка веб-части ИС производится на основе разметки и дизайна существующего сайта lis-edu.kz;

2) Для передачи сообщений и файлов, во избежание утечек и усложнения процедуры декодирования со стороны, рекомендуется использовать внутренний закрытый протокол;

3) ИС должна иметь возможность разграничения прав пользователей по уровням доступа, а также учитывать расположение и «привязку» пользователя к определенной организации;

4) Система не должна использовать внешний трафик пользователя во время работы: все ее части должны быть расположены внутри казахстанского сегмента сети Интернет, за исключением тех случаев, когда пользователь находится за пределами страны;

5) Все функции и обязанности по регистрации домена и хостинга, а также поддержания его на весь период обслуживания берет на себя исполнитель;

6) Объем хранимых в системе видеофайлов должен учитывать временные объемы, не менее 24 часов общего времени;

7) Внедрение ИС подразумевает ее использование на компьютерах средних учебных учреждений города и поддержку ИС в данных организациях без дополнительной оплаты;

8) Функциональность ИС обеспечивается следующими блоками (модулями):

Модуль порталов;
Модуль БД;
Модуль контроля успеваемости;
Клиентская “stand-alone” часть;
Модуль социальной сети;
Модуль дополнительных серверов.

Описание модуля порталов:

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

Написание и редактирование статей, новостей, комментариев и иных многострочных текстов на портале должно позволять использование WYSIWYG-технологии, во избежание необходимости изучения HTML-тегов или BB-кодов пользователями. Поле для ввода должно быть максимально понятно и привычно, за «эталон» рекомендуется принять интерфейс программы «Microsoft Word» версий 97-2003.

Основной список требований к функции редактирования:

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

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

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

Подписчик/гость может/не может:

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

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

Описание модуля БД:

Модуль базы данных должен иметь возможность хранить в себе данные о педагогах. Необходимо предусмотреть возможность выборки информации по таким критериям (либо их частям): адрес проживания, Ф.И.О., дата рождения, телефон и любым иным полям, предусмотренным шаблоном.

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

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

Описание модуля контроля успеваемости:

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

На основе собранной информации должна быть возможность прослеживания тенденций как для отдельного учащегося, так и для произвольно выбираемой группы (например: класс, школа, все мальчики/девочки, учащиеся 7-х классов с фамилией Иванов) на основе фильтра.

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

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

Описание клиентской части:

Клиентская часть представляет собой приложение, которое должно отвечать следующим требованиям:

• В качестве самостоятельного приложения: работа под ОС Windows NT4/2000/XP/Vista/Seven (7);
• В качестве веб-приложения, на ОС Linux;
• Возможность обмена сообщениями в режиме, близком к реальному времени;
• Возможность доступа к прочим функциям системы из единого настраиваемого меню;
• Возможность передачи файлов: прямой (Windows), либо через сервера ИС (Windows, Linux);
• Возможность расширения интерфейса без обновления клиентской части (интеграция веб-приложений) (Windows);
• Возможность автоматического обновления (Windows);
• Возможность получения информации о запущенных приложениях и открытых окнах (Windows);
• Базовые возможности удаленного администрирования (Windows: просмотр удаленного рабочего стола, снятие/запуск процессов на удаленном ПК);
• Сбор и передача на сервер данных о занятости рабочей станции (общее время работы, данные о рабочих промежутках, статистика использования приложений) (Windows);
• Сбор и передача на сервер базовой технической характеристики клиентского ПК (Windows).

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

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

Описание модуля социальной сети.

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

Основные характеристики:

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

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

Все взаимодействие пользователей должно иметь возможность подвергаться модерации, либо премодерации.

Модуль дополнительных серверов.

Модуль дополнительных серверов: приложении, способное работать на ОС Windows, либо Linux. Предназначено для сохранения частичной работоспособности системы в случае недоступности основного сервера. Частным примером использования является сервер в организации, который маршрутизирует передачу сообщений и файлов внутри данной организации без помощи основного сервера системы. На случай отказа линий связи данный модуль должен предусматривать кэш данных авторизации данного учреждения для сохранения работоспособности внутренних коммуникационных функций.

Дополнительные условия:

Узлы системы должны быть способны работать на существующей конфигурации сети, в качестве примера следует использовать следующую конфигурацию: Сервер HP Proliant Intel Xeon Dual-Core 2.4GHz, 4Gb RAM, RAID 2xHDD(320Gb), локальная сеть со скорость 10/100Мбод, связь с сетью интернет (и остальными узлами) по каналу 512Кбит/сек. В сети используются коммутаторы cisco, tp-link и d-link.

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