Система управления электронной почтой

Термины, определения и сокращения

Задание

1. Общие сведения о системе управления электронной почтой. Техническое задание

1.1 Наименование системы

1.2 Заказчик и Разработчик системы

1.3 Основание для разработки

1.4 Плановые сроки начала и окончания работы по разработке проекта

1.5 Сведения об источниках и порядке финансирования работ

1.6 Порядок оформления и предъявления Заказчику результатов работ

2. Назначение и цели создания системы

2.1 Назначение системы

2.2 Цели создания системы

3. Характеристика объектов автоматизации

3.1 Объекты автоматизации

3.2 Концептуальная модель предметной области

4. Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

4.1.2 Показатели назначения

4.1.3 Требования к надежности

4.1.4 Требования безопасности

4.1.5 Требования к эргономике и технической эстетике

4.1.6 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

4.1.7 Требования к защите информации от несанкционированного доступа

4.1.8 Требования по сохранности информации при авариях

4.1.9 Требования к защите от влияния внешних воздействий

4.1.10 Требования к патентной чистоте

4.1.11 Требования по стандартизации и унификации

4.1.12 Дополнительные требования

4.2 Требования к функциям, выполняемым системой

4.2.1 Модель вариантов использования итерации 1

4.2.2 Спецификация вариантов использования итерации 1

4.2.3 Временной регламент выполнения функций

4.3 Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению

4.3.2 Требования к информационному обеспечению

4.3.3 Требования к лингвистическому обеспечению

4.3.4 Требования к программному обеспечению

4.3.5 Требования к техническому обеспечению

4.3.6 Требования к метрологическому обеспечению

4.3.7 Требования к организационному обеспечению

4.3.8 Требования к методическому обеспечению

5. Состав и содержание работ по созданию системы

6. Порядок контроля и приемки системы

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

8. Требования к документированию

8.1 Требования к составу документов

8.2 Требования к оформлению документов

8.2.1 Эскизный проект

8.2.2 Технический проект

9. Источники разработки

Термины, определения и сокращения

В настоящем документе использованы термины и определения, предусмотренные ГОСТ 34.003−90. Кроме того, использован ряд терминов и определений, не предусмотренных указанным ГОСТ:

Ниже приводятся сокращения, использованные в Документе:

Задание

по курсовой работе студента Иванова Ивана Ивановича

1. Тема: Система управления электронной почтой

2. Срок сдачи студентом работы: 25 декабря 2013 г.

3. Исходные данные:

Необходимо разработать проект системы управления электронной почтой AEM-организации (Advertising Expenditure Measurement), которая специализируется в оценке расходов на рекламу.

Необходимо автоматизировать подготовку и отправку сообщений деловым партнёрам по электронной почте. Эти сообщения называются исходящими сообщениями. Исходящие сообщения — это вопросы к деловым партнерам, просьбы о встречах и т. д. Рассматриваются только формальные деловые сообщения АЕМ-партнерам (клиентам, поставщикам, служащим организаций и т. д.).

Служащие организации (Employees) готовят сообщения для рассылки в процессе проведения ежедневных бизнес-транзакций.

Отправку этих сообщений выполняют служащие отдела работы с клиентами (Customer Department Employees). Обычно эти действия выполняются во время сбора и проверки данных о рекламных операциях и при подготовке сообщений об операциях для клиентов.

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

4. Дата выдачи задания: 23 сентября 2013 г.

Задание выдал: доц. каф. ПОКС __________________ Игнатьев Е.Б.

Задание принял к исполнению: студент гр. 3−41 _______ Иванов И.И.

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

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

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

Специфика разработки проекта заключается в её итерационном характере.

Итерация 1 основана на простом консольном приложении, которое обеспечивает доступ к БД. В ответ на регистрационное имя, посланное к БД электронной почты, приложение может извлечь из БД и показать список исходящих сообщений, которые могут быть отправлены деловым партнерам. После этого пользователь (служащий) может запросить автоматическую отправку выбранного исходящего сообщения. Когда сообщение будет успешно отправлено, БД соответствующим образом обновляется. Сообщения предназначенные для отправки уже помещены в БД.

Итерация 2 позволяет вводить новые исходящие сообщения в БД через GUI или другой допустимый в веб-технологии интерфейс. Она поддерживает также рассмотрение исходящих сообщений, основанное на различных фильтрах и критериях поиска. Сообщения кроме текста могут содержать добавленные неструктурированные (мультимедиа) документы, которые должны быть посланы.

Итерация 3 перемещает основной акцент логики приложений на БД и задает дополнительные бизнес-правила в БД, которым должно подчиняться приложение.

1. Общие сведения о системе управления электронной почтой. Техническое задание

1.1 Наименование системы

Полное наименование системы — «Система управления электронной почтой».

Условное обозначение системы — «ЕМ» (Email Management).

1.2 Заказчик и Разработчик системы

Заказчик системы: Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ивановский государственный энергетический университет имени В.И. Ленина» (ИГЭУ); 153 003, г. Иваново, ул. Рабфаковская, д. 34.

Разработчик системы: Иванов Иван Иванович, студент группы 3−41.

1.3 Основание для разработки

Разработка ведется на основании задания на курсовую работу по дисциплине «Проектирование программного обеспечения».

Задание утверждено на заседании кафедры ПОКС 26.08.2013 и выдано преподавателем кафедры Игнатьевым Е.Б.

1.4 Плановые сроки начала и окончания работы по разработке проекта

Начало: 23 сентября 2013 г.

Окончание: 25 декабря 2013 г.

1.5 Сведения об источниках и порядке финансирования работ

Финансирование работ отсутствует.

1.6 Порядок оформления и предъявления Заказчику результатов работ

Разработчик оформляет результаты работ над проектом в два этапа, в виде эскизного проекта и технического проекта; и передает их Заказчику.

2. Назначение и цели создания системы

2.1 Назначение системы

ЕМ-система предназначена для управления документами электронной почты в организации, специализирующейся в оценке расходов на рекламу.

2.2 Цели создания системы

Основными целями создания системы являются:

— сокращение времени затрачиваемого на подготовку и отсылку сообщений деловым партнёрам в 2 раза.

— повышение управляемости за счет возможности проведения анализа данных о рассылке сообщений, сохраняемых в БД и автоматического формирования отчётов.

3. Характеристика объектов автоматизации

3.1 Объекты автоматизации

Объектами автоматизации являются процессы подготовки и отправки сообщений деловым партнёрам по электронной почте в AEM-организации (Advertising Expenditure Measurement), которая специализируется в оценке расходов на рекламу.

Эти сообщения называются исходящими сообщениями. Исходящие сообщения — это вопросы к деловым партнерам, просьбы о встречах и т. д. Рассматриваются только формальные деловые сообщения АЕМ-партнерам (клиентам, поставщикам, служащим организаций и т. д.).

Служащие организации (Employees) готовят сообщения для рассылки в процессе проведения ежедневных бизнес-транзакций.

Отправку этих сообщений выполняют служащие отдела работы с клиентами (Customer Department Employees). Обычно эти действия выполняются во время сбора и проверки данных о рекламных операциях и при подготовке сообщений об операциях для клиентов.

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

3.2 Концептуальная модель предметной области

В результате обследования предметной области была разработана модель объектов предметной области (Domain Object Model — DOM), описывающая классы предметной области и связи между ними. Рис. 3.1 представляет диаграмму классов для концептуальных классов, необходимых в итерации 1.

Рис. 3.1? Концептуальная модель предметной области для итерации 1

Диаграмма классов содержит три класса: Сотрудник, Деловой_партнёр и Исходящее_сообщение. В таблицах 3.1−3.3 перечислены свойства атрибутов.

Таблица 3.1 — Атрибуты класса «Сотрудник» (Employee)

Таблица 3.2 — Атрибуты класса «Деловой_партнёр» (Contact)

Таблица 3.3 — Атрибуты класса «Исходящее_сообщение» (OutMessage)

Ассоциации названы отправитель (sender), разработчик (creator) и для (for). Имеется точно один Contact для каждого OutMessage. Contact может быть связан с нулем или несколькими OutMessage. Ассоциация по имени creator связывает OutMessage с Employee, кто создавал это OutMessage в БД. Ассоциация по имени sender идентифицирует Employee, который будет отправлять по электронной почте OutMessage. Эта ассоциация связана с нулем Employee, если отправитель для OutMessage еще не намечен.

4. Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

Архитектура системы

Система EM должна иметь двухуровневую клиент-серверную архитектуру:

На уровне хранения данных размещается сервер БД, а на прикладном уровне насыщенное клиентское приложение.

Информационный обмен между компонентами системы

Входящие в состав EM подсистемы в процессе функционирования должны обмениваться информацией на основе открытых форматов обмена данными по протоколам на основе TCP/IP.

Взаимосвязи со смежными системами

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

Перспективы развития, модернизации системы

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

Также необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования.

Управление электронной почтой может иметь более широкое применение как система для маркетинга с помощью электронной почты (Email Marketing). Маркетинг с помощью электронной почты — нечто вроде предоставления по электронной почте деловым партнерам (потенциальным клиентам) маркетинговой информации относительно изделий или услуг. Как и в системе ЕМ, маркетинг электронной почты хранит информацию в БД относительно деловых партнеров и их электронных адресов, форматирует исходящие сообщения, основанные на информации, также хранящейся в БД, автоматически посылает по электронной почте эти сообщения и соответственно корректирует БД.

Требования к численности и квалификации персонала системы и режиму его работы

Для эксплуатации АС Склад должны быть предусмотрены следующие роли пользователей:

1) Администратор;

2) Сотрудник;

3) Служащий отдела работы с клиентами.

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

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

Рекомендуемая численность для эксплуатации системы EM:

— Администратор — 1 штатная единица;

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

4.1.2 Показатели назначения

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

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

4.1.3 Требования к надежности

Система должна быть доступна 24 часа каждый день недели. Не должно быть никакого связанного с БД времени простоя. О любых запланированных простоях почтового сервера из-за профилактик ЕМ-пользователи электронной почты должны быть уведомлены, по крайней мере, за 24 часа.

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

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

— при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезагрузки ОС и запуска Системы;

— при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функций системы возлагается на ОС;

— при ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

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

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

4.1.4 Требования безопасности

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

4.1.5 Требования к эргономике и технической эстетике

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

4.1.6 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

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

4.1.7 Требования к защите информации от несанкционированного доступа

ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего РД Гостехкомиссии России.

Разрабатываемая система должна обеспечивать разграничение доступа на уровне отдельных программных модулей и структур данных. Компоненты подсистемы защиты от НСД должны обеспечивать:

— идентификацию пользователя;

— проверку полномочий пользователя при работе с системой;

— разграничение доступа пользователей на уровне задач и информационных массивов.

Разрабатываемая система должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов).

4.1.8 Требования по сохранности информации при авариях

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

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

4.1.9 Требования к защите от влияния внешних воздействий

Требования к защите от влияния внешних воздействий не предъявляются.

4.1.10 Требования к патентной чистоте

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

4.1.11 Требования по стандартизации и унификации

Система должна обеспечивать работу с почтовыми серверами, работающими по протоколу SMTP.

4.1.12 Дополнительные требования

Специальные требования не предъявляются.

4.2 Требования к функциям, выполняемым системой

Функции, подлежащие автоматизации перечислены в модели вариантов использования. Итерация 1 основана на простом консольном приложении, которое обеспечивает доступ к БД. В ответ на регистрационное имя, посланное к БД электронной почты, приложение может извлечь из БД и показать список исходящих сообщений, которые могут быть отправлены деловым партнерам. После этого пользователь (служащий) может запросить автоматическую отправку выбранного исходящего сообщения. Когда сообщение будет успешно отправлено, БД соответствующим образом обновляется.

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

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

Итерация 3 перемещает основной акцент логики приложений на БД и задает дополнительные бизнес-правила в БД, которым должно подчиняться приложение.

4.2.1 Модель вариантов использования итерации 1

Итерация 1 предполагает, что сообщения к деловым партнерам уже размещены в БД ЕМ. Итерация 1 системы предназначена для создания и передачи по электронной почте сообщений и для обновления БД данных после успешной передачи.

Рис. 4.1 представляет диаграмму вариантов использования, предназначенную для представления цели, намеченных функциональных возможностей, предположений и упрощений итерации 1. Сценарий использования Store Messages to Contacts (размещение сообщений для деловых партнеров) — вне возможностей итерации 1.

Рис. 4.1? Диаграмма вариантов использования для первой итерации

Цель Store Messages to Contacts (размещение сообщений для деловых партнеров) — разместить в Production Database (БД производства) тему и текст сообщений по электронной почте к деловым партнерам и поручить отправку этих сообщений соответствующим Customer Department Employee (служащим отдела работы с клиентами). Обычно этот сценарий использования активизируется во время сбора и проверки данных о рекламных операциях и при подготовке сообщений об операциях для клиентов. Итерация 1 предполагает, что такие сообщения уже существуют в Production Database.

View Unsent Messages (просмотр непосланных сообщений) отвечает за показ списка, содержащего основную информацию о сообщениях, сохраняемых в Production Database и запланированных для отправки по электронной почте из Customer Department Employee. Customer Department Employee может пожелать отобразить полный текст сообщения (Display Message Text — отображение текста сообщения) перед принятием решения послать его по электронной почте (Email Message — сообщение электронной почты).

Как только сообщение будет успешно послано, Email Message устанавливает флаг, что это произошло. Данное действие не очевидно в диаграмме сценариев использования, потому что модель сама не фиксирует, как и где будет установлен «флаг отсылки». Возможно, например, что Production Database используется только сценарием использования View Unsent Messages, который читает сообщения и загружает их в БД, внутреннюю по отношению к ЕМ. Внутренняя БД не может быть актёром в ЕМ-модели.

4.2.2 Спецификация вариантов использования итерации 1

Краткое описание, предусловия и постусловия

Итерация 1 сценария использования Manage Email позволяет служащему отображать и посылать сообщения деловым партнерам по электронной почте. Она имеет дело только с сообщениями, уже размещенными в БД. Одновременно может быть передано по электронной почте только одно сообщение.

Предусловия

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

БД ЕМ содержит сообщения, которые нужно послать деловым партнерам по электронной почте.

Служащий связан с сервером электронной почты и уполномочен быть пользователем БД.

Постусловия

Программа обновила БД ЕМ, чтобы отразить любую успешную передачу сообщений электронной почты.

БД ЕМ осталась в неповрежденном состоянии, если произошли какое-либо исключение или ошибка.

Как только служащий покинет приложение, консольное окно закрывается.

Основной поток

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

Система отображает информационное сообщение и запрашивает у служащего имя пользователя (username) и пароль (password) (Рис. 4.2).

Рис. 4.2? Эскиз 1 интерфейса пользователь-компьютер

· Система пытается соединить служащего с БД ЕМ.

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

1. Просмотреть непосланные сообщения (View Unsent Messages) деловым партнерам (см. ниже «SI — View Unsent Messages»);

2. Отобразить текст сообщения (Display Text of a Message), далее задается идентификатор сообщения (message id) (см. ниже «S2 — Display Text of a Message»);

Рис. 4.3? Эскиз 2 интерфейса пользователь-компьютер

3. Переслать сообщение по электронной почте (Email a Message), заданное идентификатором message_id (см. ниже «S3 — Email a Message»);

4. Завершить программу (Quit this Program).

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

Подпоток S1 — View Unsent Messages (просмотр непосланных сообщений)

Информация, показанная в консольном окне, аналогична примеру на Рис. 4.4. Список меню представляется после того, как будет показано последнее непосланное сообщение.

Рис. 4.4? Эскиз 3 интерфейса пользователь-компьютер

Подпоток S2 — Display Text of a Message (отображение текста сообщения)

Служащий должен ввести message_id перед тем, как будет показан текст этого сообщения. Текст сообщения отображается так, как приведено на Рис. 4.5. Список меню заново показывается ниже текста сообщения.

Подпоток S3 — Email a Message (передача сообщения по электронной почте)

Служащий должен определить, с каким message_id должно быть передано сообщение по электронной почте. Он печатает message_id сообщения, которое посылается по электронной почте, после чего БД обновляется. Информационное сообщение отображается в консольном окне после его успешной передачи, как показано на Рис. 4.6. Список меню заново показывается после того, как сообщение было послано.

Рис. 4.5? Эскиз 4 интерфейса пользователь-компьютер

Рис. 4.6? Эскиз 5 интерфейса пользователь-компьютер

Поток исключений E1 — Incorrect username or password (неправильное имя пользователя или неправильный пароль)

Если в основном потоке актёр вводит неправильное имя пользователя или неправильный пароль (рис. 4.4), система выводит сообщение об ошибке. Система разрешает актёру повторно ввести имя пользователя и пароль, либо покинуть приложение. Актёру дают три возможности, чтобы ввести правильные имя пользователя и пароль. Если все три раза будут неудачны, система отменяет регистрацию, и сценарий использования заканчивается.

Поток исключений Е2 — Incorrect option (неправильная опция)

Если в основном потоке актёр выберет неправильную опцию (рис. 4.5), система игнорирует введенное значение и заново показывает список опций. Если будут подряд три неудачных выбора, система прекращает работу с актёром и повторно начинает сценарий использования (запрашивая регистрационное имя — рис. 4.4).

Поток исключений ЕЗ — Too many messages (слишком много сообщений)

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

Поток исключений Е4 — Email could not be sent (сообщение электронной почты не может быть послано)

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

4.2.3 Временной регламент выполнения функций

Время отклика для подпотоков S1 и S2 должно быть меньше 5 секунд с 90_процентной вероятностью.

Время отклика для подпотока S3 должно быть меньше 10 секунд с 90-процентной вероятностью для сообщений электронной почты, не превышающих 1 мегабайт в размере (включая любые приложенные документы).

4.3 Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению

Требования к математическому обеспечению не предъявляются.

4.3.2 Требования к информационному обеспечению

Уровень хранения данных в Системе должен быть построен на платформе реляционной СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.

База данных предназначена для хранения:

· сведений о сотрудниках организации,

· сведения о деловых партнёрах, и

· исходящие сообщения, предназначенные для отсылки (см. п. 3.2).

4.3.3 Требования к лингвистическому обеспечению

Программное обеспечение системы должно быть разработано на языке программирования Java 6.0.

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

4.3.4 Требования к программному обеспечению

Проект должен использовать СУБД Oracle 11g, но он должен быть легко перестраиваемым для других реляционных БД.

Итерация 1 должна использовать Java и JDBC для доступа из программы к БД.

Структурное проектирование системы должно соответствовать PCMEF-структуре, чтобы обеспечить надлежащее удобство сопровождения и масштабируемость.

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

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

Серверная группа

ПО, устанавливаемое на компьютеры серверной группы:

1. Базовая ОС — Microsoft Windows 2003 Server.

2. Средство для web-публикации локальных информационных ресурсов — Internet Information Server (Входит в состав базовой операционной системы).

3. Система управления базами данных — Oracle 11g.

4. Firewall для защиты внутренних ресурсов системы, при наличии подключения к транзитным провайдерам услуг передачи данных — Microsoft ISA Server.

5. Почтовый сервер MS Exchange 2000.

Рабочие станции

Типовое программное обеспечение, устанавливаемое на рабочие станции:

1. Базовая операционная система: Windows 7 Professional (SP1).

2. Средства доступа к информационным ресурсам: Браузер IE 10 (входит в состав базовой операционной системы).

4.3.5 Требования к техническому обеспечению

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

В состав комплекса должны входить следующие технические средства:

1) сервер БД;

2) персональные компьютеры (ПК) пользователей.

Минимальные требования к характеристикам компонентов технического обеспечения, при которых значения временных параметров Системы должны соответствовать предъявленным в ТЗ требованиям (п. 4.2.3):

1) для сервера БД:

— процессор — 2 х Intel Xeon 3 ГГц;

— объем оперативной памяти — 16 Гб;

— дисковая подсистема — 4×146 Гб;

— устройство чтения компакт-дисков (DVD-ROM);

— сетевой адаптер — 100 Мбит/с.

2) для ПК пользователя:

— процессор — Intel Pentium 1.5 ГГц;

— объем оперативной памяти — 256 Мб;

— дисковая память — 40 Гб;

— сетевой адаптер — 100 Мбит/с.

4.3.6 Требования к метрологическому обеспечению

Требования к метрологическому обеспечению не предъявляются.

4.3.7 Требования к организационному обеспечению

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

Заказчиком должны быть подготовлены изменения в положения о структурных подразделениях, в которых будет эксплуатироваться система EM.

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

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

1). Основными обязанностями Администратора являются:

— модернизация, настройка и мониторинг работоспособности комплекса технических средств (серверов, рабочих станций);

— установка, модернизация, настройка и мониторинг работоспособности системного и базового программного обеспечения;

— установка, настройка и мониторинг прикладного программного обеспечения;

— ведение учетных записей пользователей системы.

— установка, модернизация, настройка параметров программного обеспечения СУБД;

— оптимизация прикладных баз данных по времени отклика, скорости доступа к данным;

— разработка, управление и реализация эффективной политики доступа к информации, хранящейся в прикладных базах данных.

2). В обязанности Сотрудника должны войти:

— подготовка исходящих сообщений и помещение их в БД;

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

3). Служащий отдела работы с клиентами обязан:

— просмотр и контроль исходящих сообщений;

— отправка исходящих сообщений по электронной почте.

Заказчиком должен быть подготовлен приказ о приёмке системы EM и вводе её в эксплуатацию с указанием ответственных за эксплуатацию системы.

4.3.8 Требования к методическому обеспечению

Требования к методическому обеспечению не предъявляются.

5. Состав и содержание работ по созданию системы

Разработка и сдача проекта должна вестись по этапам (Таблица 5.1).

Таблица 5.1? Этапы работ над проектом

6. Порядок контроля и приемки системы

автоматизация сообщение электронная почта

По окончании работ проект принимается Приёмной комиссией.

Заседание комиссии проводится в конце 5-го семестра перед зачётной неделей.

Проект подлежит защите. Защита проекта проводится Разработчиком перед членами Приёмной комиссии.

Приёмная комиссия назначается из числа преподавателей кафедры ПОКС.

Комиссии предоставляется полностью оформленная и подписанная пояснительная записка и презентация.

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Для ввода Системы в действие необходимо:

1) подготовить у Заказчика всё необходимое техническое обеспечение;

2) установить на сервер и клиентские ПК системное, базовое и прикладное ПО;

3) установить на сервер БД;

4) ввести данные в справочники БД:

— сведения о Сотрудниках,

— сведения о деловых партнёрах;

5) подготовить организационное обеспечение;

6) провести обучение персонала;

7) провести испытания системы.

8. Требования к документированию

8.1 Требования к составу документов

По окончании работ над проектом все разработанные документы объединяются в Пояснительную записку. Она должна содержать:

1) титульный лист,

2) аннотацию,

3) оглавление,

4) термины, определения и сокращения, использованные в Пояснительной записке,

5) Задание,

6) введение,

7) Техническое задание,

8) Эскизный проект,

9) Технический проект;

10) список литературы.

Заказчику предоставляются:

1) Пояснительная записка в формате MS Word 2010;

2) Пояснительная записка, распечатанная на бумаге формата А4 — 1 экземпляр;

3) Презентация (в формате MS PowerPoint), демонстрирующая основные проектные решения.

8.2 Требования к оформлению документов

Техническое задание, Эскизный проект и Технический проект оформляются в соответствии с ГОСТ 34.201−89 [2], ГОСТ 34.602−89 и РД 50−34.698.90.

8.2.1 Эскизный проект

Эскизный проект должен содержать следующие разделы:

1) общие положения;

2) описание процесса деятельности;

3) основные технические решения;

4) мероприятия по подготовке объекта автоматизации к вводу системы в действие.

8.2.2 Технический проект

Технический проект должен содержать следующие разделы:

1) общие положения;

2) описание процесса деятельности;

3) основные технические решения;

4) мероприятия по подготовке объекта автоматизации к вводу системы в действие;

5) схема функциональной структуры;

6) описание автоматизируемых функций;

7) описание комплекса технических средств;

8) описание программного обеспечения;

9) описание информационного обеспечения;

10) описание организационной структуры.

9. Источники разработки

При разработке ТЗ использовались следующие источники:

1) ГОСТ 34.003−90. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.

2) ГОСТ 34.201−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

3) ГОСТ 34.601−90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

4) ГОСТ 34.602−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

5) РД 50−34.698.90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

6) РД Гостехкомиссии России. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий.- 2002 г.

7) Практическая программная инженерия на основе учебного примера / Л. А. Мацяшек, Б. Л. Лионг. — М.: БИНОМ. Лаборатория знаний, 2009. — 956 с.

1. ГОСТ 34.003−90. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.

2. ГОСТ 34.201−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

3. ГОСТ 34.601−90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

4. ГОСТ 34.602−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

5. РД 50−34.698.90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

6. РД Гостехкомиссии России. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий.? 2002.

7. Практическая программная инженерия на основе учебного примера / Л. А. Мацяшек, Б. Л. Лионг. — М.: БИНОМ. Лаборатория знаний, 2009. — 956 с.