3. Характеристика объектов автоматизацииГлавное назначение раздела 3 — формализация результатов обследования заказчика. Согласно ГОСТ в разделе «Характеристики объекта автоматизации» приводят: краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды. Хочу прекратить теологическую полемику по поводу определения объекта автоматизации!Объект автоматизации — организация, компания, предприятие. Процесс или деятельность не является объектом автоматизации. Исходя из этого, в разделе 3 мы описываем самого заказчика (информацию берем из открытых источников, из ФЗ о деятельности госоргана и т.п., из положений о департаментах и т.п.), его автоматизированные системы (особенно, если эти системы являются источником или потребителем нашей информации, информацию запрашиваем у заказчика) и уже потом описываем бизнес-процессы заказчика, просто как результат нашего обследования. В разделе 3 мы описываем область деятельности заказчика и описываем границы нашей системы. Ну и самое главное! С помощью раздела 3 мы можем раздуть безнаказанно ТЗ до невообразимых размеров. Напоминаю, что в разделе 3 можно размещать схемы. Пример не буду приводить, обычно раздел 3 содержит много букв.
- Характеристика объекта автоматизации
- Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды
- Выбор PCI платы для подсистемы интерактивного меню
- Характеристика объектов автоматизации
- Требования к документированию
- Стадии и этапы разработки
- Сведения об условиях эксплуатации объекта автоматизация и характеристиках окружающей среды
- Требования к системе
Характеристика объекта автоматизации
Объектом автоматизации является комплекс для работы сотрудников компании по продаже и доставке бутилированной воды конечному клиенту.
В компании имеются:
Компьютеры, телефоны, мини-АТС.
Все компьютеры в компании соединены в локальную сеть по топологии «звезда». На сервере локальной сети установлено программное обеспечение 1С предприятие версии 7.7 и база данных FireBird.
В настоящий момент реализовано программное обеспечение на базе FireBird.
Цель проекта состоит в том, чтобы сотрудники компании работали с клиентами, принимали заявки, расширяли клиентскую базу, формировали различные отчеты. Также стоит цель автоматического принятия заявок при занятости диспетчера.
Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды
Система должна сохранять работоспособность в диапазоне температур окружающей среды от 0° до +50°С.
Выбор PCI платы для подсистемы интерактивного меню
Asterisk не требует никакого специального оборудования для Voice over IP. Почти все устройства различных производителей VoIP оборудования можно подключить без особых проблем. Для использования цифрового и аналогового телефонного оборудования Asterisk поддерживает широкий спектр оборудования, в котором особое место занимают PCI платы Digium, содателя Asterisk. Были рассмотрены несколько PCI плат:
Базовая плата AX-400P представляет собой аналог Digium TDM400P. На плату можно установить до 4 модулей FXO (ATCOM AX-110X) для подключения к аналоговой телефонной сети общего пользования (ТфОП) или FXS (ATCOM AX-110S) для подключения стандартных телефонных аппаратов или факсов.
Плата Digium TDM400P — полуразмерная плата для шины PCI 2.2, поддерживающая порты FXS и FXO для организации аналоговых телефонных линий.
Для обеспечения работоспособности модулей FXS, установленных на плату, требуется один свободный 12в разъём от БП. Для работы платы, содержащей только FXO-модули, дополнительное питание не нужно.
Это все платы четырех портовые, нам же достаточно будет одно портовая плата.
Плата AX-100P является полноценным аналогом снятой с производства Digium X100P. Плата содержит 1 порт FXO, предназначенный для подключения сервера на базе Asterisk к аналоговой телефонной линии.
Данная плата нам полностью подходит. Для ее установки потребуется драйвера идущие в комплекте с платой.
Характеристика объектов автоматизации
В качестве объекта автоматизации выступает процесс, связанный с изготовлением корпусной мебели. Автоматизации подлежит процесс раскроя листа материала по заданным характеристикам деталей.
Данная система будет установлена в производственных и офисных помещениях.
Требования к документированию
Для системы на различных стадиях создания должны быть выпущены следующие документы:
— Схема организационной структуры;
— Схема функциональной структуры;
— Перечень входных сигналов и данных;
— Перечень выходных сигналов (документов);
— Пояснительная записка к техническому проекту;
— Описание автоматизируемых функций;
— Описание постановки задач (комплекса задач);
— Описание организации информационной базы;
— Описание массива информации;
— Описание программного обеспечения;
— Руководство пользователя.
Стадии и этапы разработки
Разработка должна быть проведена в 6 стадий:
1. Разработка технического задания
2. Разработка проектной документации
3. Создание эскизного проекта
4. Рабочее проектирование
5. Ввод в действие
6. Сопровождение и модернизация
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии разработки проектной документации должен быть выполнен этап разработки проектной документации.
На стадии создания эскизного проекта должен быть выполнен эскизный проект для предварительного предоставления заказчику.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
1) разработка информационной системы;
2) разработка документации.
На стадии внедрения должны быть выполнены подготовка и передача программы заказчику.
На стадии сопровождения и модернизации должны выполняться работы по усовершенствованию текущей версии информационной системы.
Содержание работ по этапам
На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1) постановка задачи;
2) определение и уточнение требований к техническим средствам;
3) определение требований к информационной системе;
4) определение стадий, этапов и сроков разработки информационной системы и документации на неё;
5) обоснование и выбор инструментария;
6) согласование и утверждение технического задания.
На этапе разработки проектной документации должны быть выполнены перечисленные ниже работы:
1) определение основных бизнес-процессов (в виде диаграмм IDEF0);
2) определение основных вариантов использования Системы для трех категорий пользователей (Гость, Авторизованный пользователь, Администратор) в виде UML диаграмм вариантов использования;
3) проектирование структуры базы данных в виде (ER диаграммы);
4) проектирование основных компонентов и алгоритмов Системы в виде соответствующих UML диаграмм;
5) проектирование структуры пользовательского интерфейса;
6) согласование и утверждение проектной документации.
На этапе разработки должна быть выполнена работа по разработке информационной системы на основе проектной документации, кодированию и отладке.
На этапе разработки документации должна быть выполнена разработка программных документов в соответствии с требованиями. « Предварительный состав программной документации» настоящего технического задания.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию.
На этапе усовершенствования текущей версии системы должны проводиться работы по созданию новых версий системы и добавлению новых функций в старую версию.
1. Анализ требований к ИС
2. Согласование требований с заказчиком
3. Выбор и разработка варианта концепции системы
4. Разработка технического задания и проекта
5. Согласование и утверждение технического задания и проекта
6. Составление плана по проведению работ
7. Подготовка аппаратного обеспечения
8. Разработка ПО
9. Проверка на совместимость аппаратного и программного обеспечения
10. Интеграция и тестирование программного и аппаратного обеспечения
11. Внесение изменений
12. Разработка инструкций по эксплуатации ИС
13. Оформление полной документации на ИС
14. Сдача ИС заказчику
Таблица 1 — Исходные данные для расчета
Рисунок 1 — Постановка задач
Рисунок 2 — Диаграмма Ганта
Рисунок 3 — Сетевой график выполнения работ
Критический путь сетевого графика будет следующим: 0 1 2 3 4 5 6891011121314
Таблица 2 — Временные параметры событий
Таблица 3 — Расчет полного и свободного резервов времени
8. Порядок контроля и приемки системы
Виды, состав, объем и методы испытаний системы и ее составных частей
Испытание системы производится путем введения большого количества данных, введения одинаковых сведений, сведений другого типа данных, данных большего диапазона. Производится проверка соответствия экранных форм описанию в руководстве для пользователя (тестирование интерфейса).
Общие требования к приемке работ по стадиям
Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.
Все создаваемые в рамках настоящей работы программные изделия передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (на компакт-диске).
Статус приемочной комиссии (государственная, межведомственная, ведомственная)
Статус приемочной комиссии определяется Заказчиком до проведения испытаний.
Объектами автоматизации являются процессы осуществляемые Фондом, описанные в пункте 2.1. данного ТЗ.
Сведения об условиях эксплуатации объекта автоматизация и характеристиках окружающей среды
Процессы, описанные ранее, осуществляются специалистами Фонда, в соответствии с его уставными документами.
Существующее программное обеспечение:
· Операционная система Windows XP;
· Интернет-браузер Internet Explorer 7;
Существующее техническое обеспечение:
· Три персональных компьютера, не соединенных сетью, а так же без доступа к сети Интернет.
Существующее нормативно-правовое обеспечение:
· Конституция Российской Федерации;
· Гражданский кодекс Российской федерации;
· Федеральный закон от 11 августа 1995 г. №135-ФЗ. О благотворительной деятельности и благотворительных организациях;
· Устав ЧОБО фонд помощи детям-сиротам домов ребенка «Надежда».
Требования к системе
Общими для системы в целом являются следующие требования:
· Система должна содержать необходимый объем информации, механизм своевременной актуализации содержания и базовый набор сервисов работы с информацией, обеспечивающий требуемую полноту информационных и иных услуг, предоставляемых пользователю;
· Структура представления информационных ресурсов и пользовательские интерфейсы по доступу к ресурсам и сервисам должны быть интуитивно понятны широкому кругу пользователей;
· предоставляемые услуги и сервисы должны иметь очевидную ценность для пользователей Системы;
· пользовательский интерфейс должен обеспечивать выбор типового профиля в соответствии с группами пользователей.
При разработке Системы должны предусматриваться:
· Разработка стандартов представления данных и метаданных описания информации в составе Системы;
· Разработка стандартных процедур информационного взаимодействия при управлении инфраструктурой и информационным наполнением Системы.
Требования к структуре и функционированию системы
Перечень подсистем, их назначение и основные характеристики
В состав WS Hope должны входить следующие компоненты:
· Подсистема регистрации пользователей сайта;
· Подсистема разграничения прав доступа;
· Подсистема авторизации пользователей;
· Подсистема навигации по сайту;
· Подсистема отображения динамического контента;
· Подсистема отображения публикаций;
· Подсистема сбора и отображения статистической информации;
· Подсистема поиска по сайту;
· Подсистема коммуникации с пользователями;
· Подсистема сбора и отображения новостных анонсов с других Интернет-ресурсов;
· Подсистема управления сайтом.
Предназначена для разграничения прав доступа, между пользователями исходя из присвоенных им ролей. Призвана ограничить возможные действия пользователя в системе из соображений безопасности.
Обеспечивает удобный механизм навигации по сайту, в виде разного рода меню, карты сайта, панели визуализации переходов по ссылкам.
Подсистема предназначена для отображения на сайте динамического контента, такого как блок динамически меняющихся фотографий, блок динамически отображаемого текста (высказывания великих людей, пропаганда благотворительной деятельности, перечисление достижений фонда и т.д.), с возможностью администрирования.
Предназначена для динамического отображения публикация и всех сопутствующих данных (раздел размещения, дата публикации, дата последнего редактирования, автора публикации, версия для печати и т.д.).
Предназначена для сбора статистической информации по сайту, и отображения её пользователю в установленном месте на сайте с учетом прав доступа пользователя.
Призвана обеспечить удобный пользовательский интерфейс поиска по сайту, с возможностью настройки поиска, как для обычного пользователя, так и для администратора сайта.
Должна предоставлять пользователям сайта, разного вида способы коммуникации с администрацией сайта (отправка сообщений на email, отправка сообщений непосредственно на сайте (с возможностью увидеть ответ), комментирование/обсуждение публикаций, где предоставлена такая возможность), по различным вопросам.
Предназначена для отображения анонсов новостей сходной тематики (тематика сайта), с различных новостных ресурсов, с возможностью настройки.
Предназначена предоставить пользователям с правами администратора, полный набор настроек сайта, в виде удобного, динамического, интуитивно понятного интерфейса. Призвана отделить все виды настроек, доступные только пользователям с правами администратора от прочих, и собрать их в одном месте. Должна быть организована с учетом возможности расширения функционала сайта. Доступ к подсистеме должен осуществляться с учетом требований безопасности системы.
Требования к способам и средствам связи для информационного обмена между компонентами системы
Для обеспечения информационного обмена компоненты Системы должны работать как один слаженный механизм. Должны быть сформулированы запросы, обращенные к фрагментам БД, созданным для нужд отдельных компонентов, с целью получения данных необходимых для правильного функционирования данных компонентов. Для передачи запросов к БД, должен использоваться язык My SQL. В качестве базового протокола сетевого и межсетевого взаимодействия должен использоваться TCP/IP.
Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
В Системе должен быть реализован способ установления взаимосвязей со смежными системами, с помощью подсистемы обмена данными с целью трансляции их содержания в Системе и обратной трансляции в смежных системах.
Требования к режимам функционирования системы
Система должна функционировать непрерывно и круглосуточно без вмешательства технических администраторов при условии соблюдения соответствующих административных и иных регламентов.
Для Системы должны быть реализованы три режима функционирования:
· Режим эксплуатации, в котором Система должна обеспечивать решение задач, определенных в п. 4.2. настоящего ТЗ;
· Режим редактирования, в котором Система подвергается настройке, либо изменению со стороны пользователя (Администратора).
· Технологический режим, в котором должны обрабатываться штатные и нештатные ситуации, требующие вмешательства обслуживающего персонала в работу Системы, выполнение операций по обеспечению её работоспособности, в том числе и профилактика технических средств.
Требования по диагностированию системы
Диагностирование программных и аппаратных средств Системы должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций.
Диагностирование Системы должно обеспечивать выявление её неработоспособности, осуществляться в технологическом режиме с использованием специально разработанных тестов, которые должны быть определены на стадии «Рабочая документация» и оформлены документом, входящим в состав технической документации.
Перспективы развития, модернизации системы
Система должна создаваться с учетом дальнейшей модернизации, отдельных компонентов и с учетом добавления новых.
Процесс модернизации не должен осложняться переработкой имеющегося кода системы, Система должна принимать нововведения как отдельные компоненты, подключаемые к ней.
Требования к численности и квалификации персонала
Для поддержки функционирования Системы и осуществления её развития (если такая необходимость существует), должен иметься специалист обладающий знаниями в области информационных и сетевых платформ, на которых будет реализована Система, а также опытом администрирования баз данных.
Для осуществления наполнения контентом и его редактирования, а так же осуществления базовых настроек Системы, не должно возникать необходимости привлечения специалиста обладающего вышеуказанными знаниями.
Показателями назначения Системы являются показатели обеспечения информационного взаимодействия и удовлетворения информационных потребностей пользователей в сфере благотворительной деятельности.
В результате внедрения Системы должно быть достигнуто следующее:
· В части показателей информационного взаимодействия — обеспечена возможность выполнения операций организации информационного взаимодействия (публикации, модификации, поиска и предоставления документов), установленные настоящим ТЗ;
· В части показателей удовлетворения информационных потребностей пользователей — обеспечена полнота, достаточность, актуальность и достоверность информации, необходимой пользователям в сфере благотворительной деятельности.
Требования к надежности
Система должна обеспечивать восстановление информации при программно-аппаратных сбоях (отключения энергопитания, отказах носителей информации, вирусах и т.д.), стабильность работы в многопользовательском режиме и живучесть Системы при выходе из строя отдельных её компонентов.
Перечень аварийных ситуаций
После сбоя серверной операционной системы или СУБД, в процессе выполнения пользовательских задач должно быть обеспечено восстановление данных в базе данных, для чего должны быть разработаны соответствующие инструменты.
Требования к надежности технических средств и программного обеспечения
Для функционирования Системы должны использоваться технические и программные средства повышенной отказоустойчивости.
Что достигается за счет выбора хостинга для размещения системы в сети Интернет с высоким уровнем отказоустойчивости и грамотным персоналом технической поддержки.
Требования к методам оценки контроля показателей надежности
Оценка и контроль показателей надёжности и устойчивости функционирования Системы должны проводиться путём фиксации числа отказов технических и программных средств за месяц работы Системы.
Требования к безопасности
Система должна обеспечивать корректное разделение прав пользователей. Базовое программное обеспечение Системы должно быть проверено на отсутствие известных уязвимостей к атакам на отказ и на несанкционированный доступ.
При регистрации пользователей должна использоваться защита от ботов.
Требования к эргономике и технической эстетике
Дизайн Системы должен удовлетворять следующим требованиям по эргономике и технической эстетике:
· Адекватно отображаться в зависимости от типа подключения пользователя;
· Обеспечивать как можно большую скорость загрузки страниц;
· Обеспечивать легкую идентификацию раздела сайта, в котором находится пользователь;
· Обеспечить минимум усилий и затрат пользователя на навигацию по страницам портала;
· Обладать развитой системой поиска информации, как контекстного, так и древовидных списков документов;
· Обеспечить приемлемый результат при распечатке публикаций на принтере;
· Корректно отображать информацию на компьютерах с отключенной поддержкой скриптов;
· Обладать системой подсказок на страницах, где у пользователя могут возникнуть затруднения.
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы
Система должна быть рассчитана на эксплуатацию на базе программно-технических средств Заказчика. Периодически должно проводиться техническое обслуживание Системы, квалифицированными специалистами.
В состав работ по техническому обслуживанию должны входить следующие действия:
· Проверка Log-файлов генерируемых Системой на наличие сообщений об ошибках;
· Проверка БД Системы на наличие ненужных, неверных, или устаревших данных;
· Обновление или удаление устаревших данных;
· Модерирование тех разделов Системы, в которых пользователи со стороны могут вносить в Систему данные (сообщения, вопросы, предложения);
· Резервное копирование Системы.
Все пользователи Системы должны соблюдать правила эксплуатации электронной и вычислительной техники.
Требования к защите информации от НСД
Информация, размещаемая в рамках Системы, является открытой (общедоступной), из этого следует, что в рамках Системы не должна размещаться конфиденциальная информация о Заказчике или иных лицах. Так же не должна размещаться любая другая информация, способная навредить Заказчику или иным лицам, порочащая кого либо, или способствующая разжиганию межнациональной и межрелигиозной розни.
Уровень защиты от несанкционированного доступа, должен соответствовать классу защищённости 1Д по классификации Гостехкомиссии РФ.
Компоненты защиты от НСД должны обеспечивать:
· Идентификацию пользователя;
· Разграничение прав доступа к информации и к инструментам её модификации;
· Средства контроля, управления и идентификации при удаленном доступе к Системе;
· Средства экранирования Системы;
· Средства мониторинга доступа к Системе;
· Средства антивирусной защиты.
Защищенная часть Системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).
Защищенная часть Системы должна автоматически блокировать сессии пользователей и приложений по заранее заданным промежуткам времени отсутствия активности со стороны пользователей и приложений.
Требования по сохранности информации при авариях
Должна быть предусмотрена возможность автоматического или ручного резервного копирования данных Системы средствами системного или базового ПО (ОС, СУБД), входящего в состав программно-технического комплекса Заказчика.
В комплекте с системой резервного копирования должна быть предусмотрена система восстановления данных из ранее созданных резервных копий.
Требования к защите от влияния внешних воздействий
Требования к радиоэлектронной защите средств Системы, требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения) — не предъявляются.
Требования к патентной чистоте
Разработка и установка как Системы в целом, так и отдельных частей Системы не должны требовать покупки лицензий на ПО сторонних производителей. В случае если при разработке или установке Системы необходимо использовать ПО сторонних производителей, то должно использоваться ПО распространяемое на бесплатной основе. При интеграции в систему такого ПО должны быть выполнены все требования к патентной чистоте обозначенные производителем данного ПО.
Требования по стандартизации и унификации
Техническая документация должна оформляться в соответствии с ГОСТ 34 серии. Алгоритмы, реализуемые программными модулями, должны разрабатываться в соответствии с требованиями Заказчика.
Система должна обмениваться данными с агентом пользователя (браузером) в соответствии со стандартами, принятыми консорциумом W3C. Основным языком разработки принимается язык программирования PHP.
