42
разработка программной документации;
испытания системы.
На стадии внедрения должен быть выполнен этап подготовки и
передачи системы.
2.6. Порядок контроля и приемки системы
2.6.1. Виды испытаний
Приемо-сдаточные испытания системы должны проводиться согласно
разработанной Исполнителем и согласованной Заказчиком программы и
методик испытаний. Ход проведения приемо-сдаточных испытаний Заказчик
и Исполнитель документируют в «Протоколе проведения испытаний».
Система подвергается испытаниям следующих видов:
предварительные испытания;
опытная эксплуатация;
приемочные испытания.
2.6.2. Общие требования к приемке работы, статус приемочной
комиссии
Таблица 1 – Виды испытаний
Стадия
испытаний
Участники
испытаний
Место и
срок
проведения
Порядок согласования
документации
Статус
приемочной
комиссии
Предвари-
тельные
испытания
Организа-
ции
Заказчика и
Разработчи-
ка
На
территории
Заказчика,
с
22.12.2016
по
28.12.2016
Проведение предваритель-
ных испытаний.
Фиксирование выявленных
неполадок в Протоколе ис-
пытаний.
Устранение выявленных
неполадок.
Проверка устранения вы-
явленных неполадок.
Экспертная
группа
43
Принятие решения о воз-
можности передачи ИС в
опытную эксплуатацию.
Составление и подписание
Акта приёмки ИС в опыт-
ную эксплуатацию.
Опытная
эксплуата-
ция
Организа-
ции
Заказчика и
Разработчи-
ка
На
территории
Заказчика,
с
09.01.2017
по
15.01.2017
Проведение опытной эксп-
луатации.
Устранение выявленных
неполадок.
Проверка устранения вы-
явленных неполадок.
Принятие решения о готов-
ности ИС к приемочным
испытаниям.
Составление и подписание
Акта о завершении опыт-
ной эксплуатации ИС.
Группа
тестировани
я
Приемоч-
ные
испытания
Организа-
ции
Заказчика и
Разработчи-
ка
На
территории
Заказчика,
с
23.01.2017
по
31.01.2017
Проведение приемочных
испытаний.
Устранение выявленных
неполадок.
Проверка устранения вы-
явленных неполадок.
Принятие решения о воз-
можности передачи ИС в
промышленную эксплуата-
цию.
Составление и подписание
Акта о завершении прие-
Приемочная
комиссия
44
мочных испытаний и пере-
даче ИС в промышленную
эксплуатацию.
Оформление Акта завер-
шения работ.
2.7. Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие
Силами Заказчика в срок должны быть выполнены следующие работы:
осуществлена подготовка помещения для осуществления пуско-
наладочных работ в соответствии с требованиями, приведенными в
настоящем техническом задании;
осуществлена закупка и установка необходимого оборудования;
организовано необходимое сетевое взаимодействие.
Силами Заказчика в срок должны быть решены организационные
вопросы:
организации доступа к базам данных источников;
выделения ответственных специалистов со стороны Заказчика
для взаимодействия с проектной командой по вопросам
взаимодействия с системами-источниками данных.
При необходимости, в срок до начала проведения пусконаладочных
работ должны быть обеспечены условия для проведения инсталляции и
настройки аппаратных и программных средств, необходимых для проведения
пусконаладочных работ.
Установка и настройка программных и аппаратных средств на объектах
автоматизации производится перед проведением испытаний в согласованные
сроки.
2.8. Источники разработки
Техническое задание разработано в соответствии с:
45
ГОСТ 34.602-89 «Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной
системы».
46
ГЛАВА 3: ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОГО
РЕСУРСА
Проeктировaниe информационного ресурса включaeт:
Утвeрждeниe пeрвонaчaльного тeхничeского зaдaния нa
рaзрaботку информационного ресурса.
Проектирование функциональной модели информационного
ресурса;
Проектирование модели данных и внешних источников;
Опрeдeлeниe структуры сервиса – рaсположeниe рaздeлов,
контeнтa и нaвигaции;
Вeб-дизaйн – создaниe грaфичeских элeмeнтов мaкeтa сaйтa,
стилeй и элeмeнтов нaвигaции.
3.1. Функциональная модель информационного ресурса
На начальных этапах создания информационной системы необходимо
понять, как работает организация, которую собираются автоматизировать.
Для описания работы предприятия необходимо построить модель. Такая
модель должна быть адекватна предменной области, следовательно, она
должна содержать в себе знания всех участников бизнес-процессов
организации.
Наиболее удобным языком моделирования бизнес-процессов является
IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и
называвшийся первоначально SADT – Structured Analysis and Design
Technique. В начале 70-х годов вооруженные силы США применили
подмножество SADT, касающееся моделирования процессов, для реализации
проектов в рамках программы ICAM (Integrated Computer-Aided
Manufacturing). В дальнейшем это подмножество SADT было принято в
качестве федерального стандарта США под наименованием IDEF0.
47
В IDEF0 система представляется как совокупность
взаимодействующих работ или функций. Такая чисто функциональная
ориентация является принципиальной – функции системы анализируются
независимо от объектов, которыми они оперируют. Это позволяет более
четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и
графическое), которое должно дать ответ на некоторые заранее
определенные вопросы.
Моделируемая система рассматривается как произвольное
подмножество Вселенной. Произвольное, потому что, во-первых, мы сами
умозрительно определяем, будет ли некий объект компонентом системы, или
мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно
зависит от точки зрения на систему. Система имеет границу, которая
отделяет ее от остальной Вселенной. Взаимодействие системы с
окружающим миром описывается как вход (нечто, что перерабатывается
системой), выход (результат деятельности системы), управление (стратегии и
процедуры, под управлением которых производится работа) и механизм
(ресурсы, необходимые для проведения работы). Находясь под управлением,
система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с
определения контекста, т. е. наиболее абстрактного уровня описания системы
в целом. В контекст входит определение субъекта моделирования, цели и
точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно
установить, что входит в систему, а что лежит за ее пределами, другими
словами, нужно определить, что будет в дальнейшем рассматриваться как
компоненты системы, а что как внешнее воздействие. На определение
субъекта системы будет существенно влиять позиция, с которой
рассматривается система, и цель моделирования – вопросы, на которые
построенная модель должна дать ответ, другими словами, первоначально
48
необходимо определить область моделирования. Описание области как
системы в целом, так и ее компонентов является основой построения модели.
Хотя предполагается, что в течение моделирования область может
корректироваться, она должна быть в основном сформулирована изначально,
поскольку именно область определяет направление моделирования и когда
должна быть закончена модель. При формулировании области необходимо
учитывать два компонента – широту и глубину. Широта подразумевает
определение границ модели – будет определено, что рассматривается внутри
системы, а что снаружи. Глубина определяет, на каком уровне детализации
модель является завершенной. При определении глубины системы
необходимо не забывать об ограничениях времени – трудоемкость
построения модели растет в геометрической прогрессии от глубины
декомпозиции. После определения границ модели предполагается, что новые
объекты не должны вноситься в моделируемую систему; поскольку все
объекты модели взаимосвязаны, внесение нового объекта может быть не
просто арифметической добавкой, но в состоянии изменить существующие
взаимосвязи. Внесение таких изменений в готовую модель является, как
правило, очень трудоемким процессом (так называемая проблема
"плавающей области").
Функциональная модель информационного ресурса находится в
приложении В.
3.2. Модель данных и внешние источники
В результате анализа предметной области определяется спецификация
разрабатываемого программного обеспечения, необходимо построить общую
модель его взаимодействия с пользователями или другими программами и
конкретизировать его основные функции.
Для описания модели данных и внешних источников в системе
применяются диаграммы потоков данных (DFD — Data flow diagrams). DFD
позволяет описать требуемое поведение системы в виде совокупности
процессов, взаимодействующих посредством связывающих их потоков
49
данных. DFD показывает, как каждый из процессов преобразует свои
входные потоки данных в выходные потоки данных и как процессы
взаимодействуют между собой.
В процессе работы информационного ресурса участвуют ее
пользователи – администратор, контент менеджер и гость.
Процесс работы информационного ресурса компании делится на 3
основные части (Приложение Г):
Изменение исходного кода;
Изменение контента;
Просмотр информационного ресурса.
Часть, где можно изменить исходный код, доступна только для
администратора. Для выполнения действий, связанных с изменением
исходного кода, администратор должен ввести логин и пароль. После
успешной аутентификации администратор получает права на изменение
кода. После изменения кода, администратор должен выйти из учетной записи
для безопасности.
Часть с изменением контента доступна контент-менеджеру и
пользователям с такими же или более высокими правами доступа, а именно
администратору. Контент-менеджер так же должен пройти процедуру
аутентификации, после чего он сможет вновить изменения в контент
информационного ресурса.
Часть, в которой можно просматривать информационный ресурс,
доступна абсолютно любому пользователю, у которого есть выход в
интернет, с гостевыми правами доступа.
3.3. Структура сервиса
С самого начала следует упорядочить содержимое проекта. Все
картинки нужно сложить в одну папку, служебные файлы в другую, сами
страницы также можно разделить (например, по разделам). Так будет проще
ориентироваться. Для этого следует определить структуру будущего
информационного ресурса. Существует несколько основных структур:
50
Линейная структура – страницы располагаются в определенном
порядке. Переход с одной страницы на другую строго определен. Такая
структура обоснована, например, при обучении. Располагая страницы в
определенном порядке, вы можете быть уверены, что пользователь не
пропустит нужный материал.
Линейная структура показана на рисунке 2.
Рисунок 2 – Линейная структура
Иерархическая – страницы разбиты по категориям и
подкатегориям. Такая структура наиболее удобна. Иерархическая
структура показана на рисунке 3.
Рисунок 3 – Иерархическая структура
Произвольная – страницы расположены в свободном порядке.
Такая структура оправдана только для небольших сайтов.
Произвольная структура показана на рисунке 4.
51
Рисунок 4 – Произвольная структура
Разрабатываемый информационный ресурс будет иметь иерархическую
структуру. Он будет содержать такие разделы как: «Главная», «Новости»,
«Файлы», «Наши издания», «Полезные ссылки», «О нас», «Контакты»
(Приложение Д).
3.4. Структура навигации
Это очень важная часть планирования ресурса. Способ доступа к
информации на сайте должен быть простым и понятным.
Для решения этих задач используются различные варианты. Например,
можно как-то выделить страницу в меню, на которой сейчас находится
пользователь, а само меню сделать видимым на всех страницах сайта.
Также можно сделать так называемые навигационные ключи, т.е. на
каждой странице (сверху) указать полный путь до этой страницы по схеме:
главная страница – название раздела – название страницы.
Вообще, стоит придерживаться правила трех кликов, которое гласит,
что до любой страницы сайта пользователь должен добраться не более, чем
за три клика (перехода).
3.4.1. Виды навигации
Самый распространенный видом навигации является текстовая. Надо
сказать, что она должна присутствовать даже, если используются другие
системы навигации (так как она самая надежная). В общем случае, такая