Автоматизация. Методические указания по дипломному проектированию Направление подготовки
 Скачать 3.16 Mb.
|
2.3 Структура второй главыПроектная часть дипломного проекта является описанием решений, принятых по всей вертикали проектирования. Глава должна быть основана на информации, представленной в аналитической части, обобщать ее. По сути, проектная часть является решением проблематики, изложенной в аналитической части, на языке информационных технологий. Поэтому недопустимо, если при проектировании используется информация об объекте управления, не описанная в первой главе. 2. Проектная часть Разработка проекта автоматизации Этапы жизненного цикла проекта автоматизации Ожидаемые риски на этапах жизненного цикла и их описание Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации Информационное обеспечение задачи Характеристика нормативно-справочной, входной и оперативной информации Характеристика результатной информации Программное обеспечение задачи Cценарий диалога Характеристика базы данных Структурная схема пакета (дерево вызова программных модулей) Испытания разработанного решения 2.4.1 Перечень объектов и функций, подлежащих испытаниям 2.4.2 Методы проведения испытаний 2.4.3 Проведение проверочных испытаний и их результаты 2. Проектная часть 2.1 Разработка проекта автоматизации 2.1.1 Этапы жизненного цикла проекта автоматизации Целью данного пункта является выбор и краткое описание всего жизненного цикла проекта автоматизации, сущности и взаимосвязи его этапов. Наиболее оптимальным вариантом является: выбор и обоснование одного из общеизвестных стандартов жизненного цикла ИС (ГОСТ 34, ISO 12207, ISO 15288, MSF, RUP, COBIT, Oracle CDM, XP); краткое рассмотрение ключевых положений по каждому из этапов: цель этапа; ключевые участники; требования к входной информации; получаемые результаты. Важно отметить, что данное описание должно относится непосредственно к автоматизируемой задаче, т.е. раскрывать последовательность разработки, внедрения и эксплуатации информационной системы, представленной к защите в рамках дипломного проекта. Для этапа внедрения обязательно: выбрать и обосновать стратегию внедрения предлагаемого решения; детально расписать все работы и их характеристики, которые планируется проводить на этапе внедрения разрабатываемого проектного решения в их логической последовательности; описать роли участников процесса внедрения и их участие в каждой из работ. Для этапа эксплуатации обязательно: детально расписать все работы и их характеристики, которые необходимо производить на этапе эксплуатации разрабатываемого проектного решения в их логической последовательности; описать роли участников процесса эксплуатации и их участие в каждой из работ. Такое резюме по каждому из этапов должно дать возможность понимания заложенной логики построения проекта автоматизации и взаимосвязи выделяемых работ. 2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание В разделе необходимо рассмотреть наиболее существенные риски проекта в разрезе их типов. Необходимо описать возможные риски вообще (применительно к каждому этапу ЖЦ ИС) и актуальные для разрабатываемого проекта в частности. Помимо краткого описаниях их сущности, необходимо описать те шаги, которые планируется предпринять для уменьшения величины каждого конкретного риска. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации В данном разделе необходимо дать полную и обоснованную характеристику проектируемым для решения задач средствам обеспечения ИБ и ЗИ. При этом необходимо отразить следующие аспекты. 1. Защита от внутренних угроз (разработка внутренней политики безопасности, разграничение прав доступа к информации и так далее). Для этого необходимо определить группы пользователей разрабатываемой системы и назначить им соответствующие права доступа к папкам и модулям системы, определить требования к паролям и частоте их смены, а также другие параметры использования ИС. Данные необходимо представить в форме таблиц, пример соответствующей формы представлена в таблице 3. 2. Защита от внешних угроз (безопасность каналов, протоколы, аутентификация, шифрование, безопасная пересылку ключей и т.д.). Состав проектируемых программных и аппаратных средств может быть оформлен в виде таблицы с содержанием граф: нормативно-правовые акты организации, стандарты (международные и отечественные); антивирусные и антишпионские средства; проактивная защита от внешних угроз и защита внешнего периметра; защита от сетевых угроз; защита от инсайдерских угроз и защита информационных ресурсов; физическая защита информации. Таблица 3 Пример разграничения прав пользователей
3. Обоснование выбора политики безопасности, а также тех или иных программных и аппаратных средств, где должно быть: обоснование организационно-правовым методам и программно-аппаратным средствам (средства должны быть конкретные, лицензионные, с требованиями соответствующих стандартов); обоснование различным аспектам защиты системы: защита базы, резервное копирование, защита от хищения данных, защита от порчи данных, защита от инсайдерских угроз, уровни или сферы защиты (обоснование разрабатываемого решения на предмет уязвимостей, в том числе ошибки кода, ошибочные действия пользователя «защита от дурака»). Информационное обеспечение задачи 2.2.1. Характеристика нормативно-справочной, входной и оперативной информации Пункт представляет собой описание состава входных документов, входных файлов и справочников, соответствующих им экранных форм размещения данных. При этом следует уделять внимание следующим вопросам: при описании входных документов необходимо: привести в приложении формы(макеты) документов и экранные формы для их ввода в систему; привести перечень содержащихся в них первичных показателей; привести источник получения документа; описать структуру документа, число строк, объемные данные, частоту возникновения документа; при описании входных файлов необходимо: привести перечень содержащихся в них первичных показателей; привести источник получения файла; описать структуру файла, объемные данные, частоту поступления файла; описание экранной формы входного документа должно содержать макет экранной формы, особенностей организации рабочей и служебной зон макета, состав и содержание подсказок, необходимых пользователю для заполнения макета, перечень справочников, автоматически подключаемых при заполнении этого макета; при описании справочников необходимо: построить сводную таблицу, содержащую: название справочника; ответственного за его ведение; средний объём справочника в записях; среднюю частоту актуализации; средний объем актуализации (в записях или в процентах); по каждому справочнику необходимо описать его реквизитный состав. 2.2.2 Характеристика результатной информации В этом подразделе должны быть описаны таблицы (или файлы) с перечнем полей, полученных при выполнении запросов. При этом здесь следует указать на основе каких таблиц с переменной или условно-постоянной информацией базы данных были получены таблицы с результатной информацией и какой документ получается в итоге. Далее должны быть приведены основные параметры каждой таблицы с указанием, подлежит ли она дальнейшему хранению или нет. Характеристика результатных документов является одним из важных пунктов всей проектной части и представляет собой обзор результатов решения поставленных в аналитической части задач с точки зрения предметной технологии. Если решение представляет собой формирование ведомостей (в виде экранных или печатных форм), каждую ведомость необходимо описать отдельно (в приложении следует привести заполненные экземпляры ведомостей и экранных форм документов). В частности, какое место занимает ведомость в информационных потоках предприятия (служит для оперативного управления или для отчетности), является уточняющей или обобщающей и т. д.). Каждая ведомость должна иметь итоги, не включать избыточной информации, быть универсальной. Далее приводится описание печатных форм, экранных макетов с перечислением и краткой характеристикой содержащихся показателей для каждого документа указывается, на основе каких таблиц получается этот документ. Если результатная информация предоставляется не в виде ведомостей (например, при проектировании подсистемы распределенной обработки данных), необходимо подробно описать структуру сообщения и его дальнейший путь, основываясь на имеющейся организации многопользовательской ИС. Для результатных файлов описывается: их структура и реквизитный состав; частота их формирования; на основе каких таблиц они формируются; каким способом доставляются до ИС – получателя файла. 2.3.1 Сценарий диалога В этом пункте следует выбрать способ описания диалога. Как правило, применяется два способа описания диалога. Первый предполагает использование табличной формы описания. Второй использует представление структуры диалога в виде орграфа, вершины которого перенумерованы, а описание его содержания в соответствии с нумерацией вершин, либо в виде экранов, если сообщения относительно просты, либо в виде таблицы. Диалог в ИС не всегда можно формализовать в структурной форме. Как правило, диалог в явном виде реализован в тех ИС, которые жестко привязаны к исполнению предметной технологии. В некоторых сложных ИС (например, в экспертных системах) диалог не формализуется в структурной форме и тогда данный пункт может не содержать описанных схем. Описание диалога, реализованного с использованием контекстно-зависимого меню не требует нестандартного подхода. Необходимо лишь однозначно определить все уровни, на которых пользователь принимает решение относительно следующего действия, а также обосновать решение об использовании именно этой технологии (описать дополнительные функции, контекстные подсказки и т.д.) . Схема, описывающая дерево диалога, должна обязательно сопровождаться пояснениями по действиям, выполняемым в каждом пункте меню. Пример фрагмента сценария диалога представлен на рисунке 6. 2.3.2. Характеристика базы данных ER модель предполагает определение состава и взаимосвязей таблиц, отражающих содержание информационной модели в терминах конкретной СУБД, выбранной в п.1.4. Описание каждой таблицы должно содержать (необходимо выполнять в виде таблиц) наименование полей, идентификатор каждого поля, его шаблон, тип данных, длину поля и описание поля. По каждой таблице должна быть информация о ключевом поле, длине одной записи, числе записей в таблице, частоте создания таблицы (в случае применения динамических или временных таблиц), длительности хранения, возможности индексирования. Пример фрагмента описания элемента ER модели представлен в таблице 4.  Р исунок 6. Пример фрагмента сценария диалога Таблица 4 Пример фрагмента описания структуры записей таблицы «Контрагенты»
Необходимо отметить соответствие проектируемых таблиц входным документам или справочникам. В случае, когда ER модель получена путем конвертации из инфологической модели с помощью CASE – средств, она должна отражать полный состав сущностей и связей инфологической модели. Если информационная база организована в форме корпоративной базы данных, то приводится описание и других её элементов: распределение прав доступа, бизнес-правил, триггеров и др. Пример фрагмента ER модели представлен на рисунке 7. 2.3.3 Структурная схема пакета (дерево вызова процедур и программ) На основе результатов, полученных в предыдущем пункте, строится дерево программных модулей, отражающих структурную схему пакета, содержащей программные модули различных классов: выполняющие служебные функции; управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю; модули, связанные с вводом, хранением, обработкой и выдачей информации. В данном пункте необходимо для каждого модуля указать идентификатор и выполняемые функции. Эти данные должны быть представлены в форме таблицы (пример – таблица 4).  Рисунок 7. Пример фрагмента ER модели Если проектирование ведется с помощью языков четвертого поколения, например генераторов экранных форм, отчетов, то эту схему следует преобразовать в схему настройки, отражающей виды и состав используемых объектов проектирования по каждому виду, применяемых в этих средствах: «Форм», «Отчетов», «Запросов» и «Кнопочная форма». Таблица 4 Пример фрагмента таблицы описания функций модулей
2.4 Испытания разработанного решения В соответствии с ГОСТ 34-602-92, автоматизированные системы до внедрения в эксплуатацию проходят предварительные испытания. Испытания ИС могут быть двух видов: комплексные и автономные. Автономные испытания предполагают проверку отдельных составных частей (модулей, подпрограмм и т.п.) ИС. Комплексные испытания предполагают совместную проверку всех составных частей и видов обеспечения (программного, технического и т.д.) ИС. Необходимо привести обоснование выбранного вида испытаний разработанной ИС исходя из целей и задач ВКР. Далее, вне зависимости от вида испытаний, должны быть рассмотрены: - перечень объектов и функций, подлежащих испытаниям; - последовательность проведения испытаний; - методы проведения испытаний и обработки результатов испытаний; - критерии приёмки ИС по результатам испытаний; - описание хода проверочных испытаний и достигнутого результата. 2.4.1 Перечень объектов и функций, подлежащих испытаниям Как правило, комплексные испытания ИС предполагают проверку всех функций, описанных в 2.3.3 и 2.3.4. При проведении автономных испытаний набор проверяемых функций может быть ограничен в зависимости от постановки задачи ВКР и использования для реализации тех или иных функций типовых (заимствованных) модулей. В подразделе необходимо привести перечень проверяемых функций ИС (таблица 5) и обосновать отсутствие необходимости проверки иных функций, реализуемых системой. Проверяемые функции необходимо располагать в последовательности проведения их испытаний, т.е. если функция Б проверяется после функции А, то функция Б указывается после функции А Таблица 5. Перечень проверяемых функций
2.4.2 Методы проведения испытаний Для каждой проверяемой функции должен быть приведён перечень проверок (тестов) всех видов с указанием: - объекта проверки (функция, модуль, подпрограмма, экранная форма, отчёт и т.д.); - предмета проверки (правильность функционирования, скорость обработки, точность вычислений и т.д.); - дополнительных программных и технических средств, необходимых для проверки (тестирования); - массива исходных данных и способа его формирования (включая содержимое базы данных, входные массивы, сигналы и т.д.); - вида и мест искажений тестовой информации в массивах исходных данных для проверки корректности обработки нештатных ситуаций; - наблюдаемые параметры (ожидаемая реакция системы) в штатных и нештатных ситуациях; - способ определения ожидаемых результатов (расчётная формула, конкретное значение и т.д.). Описание проверок рекомендуется представлять в виде таблиц. Пример структуры табличного описания приведён в таблице 6. Таблица 6 Описание проверки
Подобное описание производится для каждой проводимой проверки. Для удобства проверки нумеруются в порядке их проведения. Для однотипных проверок, предполагающих сходные действия, допускается формулировка «аналогично проверке N, за исключением…» - с описанием отличий. В случае использования хотя бы для одной проверки дополнительных технических средств, необходимо также привести схему технической архитектуры для проведения испытаний. Для каждой проверки (теста) необходимо привести критериальные параметры, при выполнении которых проверка считается успешной. Для каждой проверки необходимо указать контролируемые параметры и их граничные значения. 2.4.3 Проведение проверочных испытаний и их результаты В этом разделе описывается фактический ход испытаний разработанной ИС в последовательности, соответствующей разделу 2.4.2. Ход каждой проверки необходимо иллюстрировать экранными формами, полученными отчётами, снимками экрана с диалоговыми окнами, служебными сообщениями, графиками и т.д. (не менее 10 иллюстраций, экранные формы не менее 7 обязательно) При описании проведённых проверок необходимо особое внимание уделить соответствию результатов критериям, определённым для каждой проверки в разделе 2.4.2. Результаты испытаний необходимо привести в таблице (аналогично примеру в таблице 7) Таблица 7. Результаты испытаний
В конце раздела необходимо сделать вывод об успешном (или не успешном) прохождении испытаний. |