Методические указания по подготовке выпускной квалификационной работы для направления подготовки Информационные системы и технологии (бакалавриат)
 Скачать 4.02 Mb.
|
2.3 Структура второй главыПроектная часть выпускной квалификационной работы является описанием решений, принятых по всей вертикали проектирования. Глава должна быть основана на информации, представленной в аналитической части, обобщать ее. По сути, проектная часть является решением проблематики, изложенной в аналитической части, на языке информационных технологий. Поэтому недопустимо, если при проектировании используется информация об объекте управления, не описанная в первой главе. II Проектная часть Разработка проекта автоматизации Этапы жизненного цикла проекта автоматизации Ожидаемые риски на этапах жизненного цикла и их описание Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации Информационное обеспечение задачи Информационная модель и её описание Характеристика нормативно-справочной, входной и оперативной информации Характеристика результатной информации Программное обеспечение задачи Общие положения (дерево функций и сценарий диалога) Характеристика базы данных Структурная схема пакета (дерево вызова программных модулей) Описание программных модулей Контрольный пример реализации проекта и его описание II Проектная часть Разработка проекта автоматизации 2.1.1 Этапы жизненного цикла проекта автоматизации Целью данного пункта является выбор и краткое описание всего жизненного цикла проекта автоматизации, сущности и взаимосвязи его этапов. Наиболее оптимальным вариантом является: выбор и обоснование одного из общеизвестных стандартов жизненного цикла ИС (ГОСТ 34, ISO 12207, ISO 15288, MSF, RUP, COBIT, Oracle CDM, XP); краткое рассмотрение ключевых положений по каждому из этапов: цель этапа; ключевые участники; требования к входной информации; получаемые результаты. Важно отметить, что данное описание должно относится непосредственно к автоматизируемой задаче, т.е. раскрывать последовательность разработки, внедрения и эксплуатации информационной системы, представленной к защите в рамках выпускной квалификационной работы. Для этапа внедрения обязательно: выбрать и обосновать стратегию внедрения предлагаемого решения; детально расписать все работы и их характеристики, которые планируется проводить на этапе внедрения разрабатываемого проектного решения в их логической последовательности; описать роли участников процесса внедрения и их участие в каждой из работ. Для этапа эксплуатации обязательно: детально расписать все работы и их характеристики, которые необходимо производить на этапе эксплуатации разрабатываемого проектного решения в их логической последовательности; описать роли участников процесса эксплуатации и их участие в каждой из работ. Такое резюме по каждому из этапов должно дать возможность понимания заложенной логики построения проекта автоматизации и взаимосвязи выделяемых работ. 2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание В разделе необходимо рассмотреть наиболее существенные риски проекта в разрезе их типов. Необходимо описать возможные риски вообще (применительно к каждому этапу ЖЦ ИС) и актуальные для разрабатываемого проекта в частности. Помимо краткого описаниях их сущности, необходимо описать те шаги, которые планируется предпринять для уменьшения величины каждого конкретного риска. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации В данном разделе необходимо дать полную и обоснованную характеристику проектируемым для решения задач средствам обеспечения ИБ и ЗИ. При этом необходимо отразить следующие аспекты. 1. Защита от внутренних угроз (разработка внутренней политики безопасности, разграничение прав доступа к информации и так далее). Для этого необходимо определить группы пользователей разрабатываемой системы и назначить им соответствующие права доступа к папкам и модулям системы, определить требования к паролям и частоте их смены, а также другие параметры использования ИС. Данные рекомендуется представить в форме таблиц. Пример такой обобщенной таблицы приведен ниже. Разграничение прав пользователей.
2. Защита от внешних угроз (безопасность каналов, протоколы, аутентификация, шифрование, безопасная пересылку ключей и т.д.). Состав проектируемых программных и аппаратных средств может быть оформлен в виде таблицы с содержанием граф: нормативно-правовые акты организации, стандарты (международные и отечественные); антивирусные и антишпионские средства; проактивная защита от внешних угроз и защита внешнего периметра; защита от сетевых угроз; защита от инсайдерских угроз и защита информационных ресурсов; физическая защита информации. 3. Обоснование выбора политики безопасности, а также тех или иных программных и аппаратных средств, где должно быть: обоснование организационно-правовым методам и программно-аппаратным средствам (средства должны быть конкретные, лицензионные, с требованиями соответствующих стандартов); обоснование различным аспектам защиты системы: защита базы, резервное копирование, защита от хищения данных, защита от порчи данных, защита от инсайдерских угроз, уровни или сферы защиты (обоснование разрабатываемого решения на предмет уязвимостей, в том числе ошибки кода, ошибочные действия пользователя «защита от дурака»). Информационное обеспечение задачи 2.2.1 Информационная модель и её описание Методика разработки информационной моделипредполагает моделирование нового варианта организации информационной системы предметной области («КАК ДОЛЖНО БЫТЬ»), а именно: полного состава информации, необходимой для решения комплекса задач данного АРМа; отражение этой информации на всех типах носителей; отражение процесса преобразования информации, начиная от получения первичной переменной и условно-постоянной информации, загрузки ее в файлы с и заканчивая получением файлов с результатной информацией и выдачей ее пользователю; состава исходных первичных документов и распределение их по задачам; источники и способы получения первичной информации; состава файлов с первичной, условно-постоянной, промежуточной и результатной информацией; информационную потребность для каждой задачи комплекса; адресатов выдачи и получения результатной информации. В описании информационной модели необходимо объяснить, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов. Информационная модель представляет собой схему, отражающую преобразование информационных реквизитов от источников информации до её получателей или, иными словами, процесс обработки информации в информационной системе. При построении модели следует однозначно понимать физические основы работы информационной системы и технологии её взаимодействия с внешними ИС и пользователями моделируемой ИС. Перед тем, как рассмотреть возможное содержание самой модели, остановимся на некоторых общих правилах, которые помогу сделать интерпретацию обозначений на модели однозначной. Правило 1 Модель читается исключительно сверху вниз  Правило 2 У каждого элемента на модели должен быть как вход, так и выход. Это правило не относится к источникам и получателям информации для моделируемой ИС, так как у них бывает либо выход (у источников), либо вход (у получателей). Правило 3 Вход обозначается в центре верхней части элемента, а выход – в центре нижней части. Вход и выход у элемента должен быть только 1.  Правило 4 Каждая связь, подходящая на вход элемента, должна подразумевать под собой передачу как минимум одного реквизита информации. Совокупность всех реквизитов информации, передаваемая всеми входящими связями должна давать возможность сделать экземпляр обозначенного объекта (файл, записать в таблице и др.). Правило 5 Если в рамках работы информационной системы происходит изменение состояния объекта (файла, таблицы, справочника), то это должно быть обозначено любым из символов ( «`», «!», «@», «#», «^», «&», «*» ). Под изменением, например, могут пониматься добавление записи в таблицу (insert), изменение записи в таблице (update), изменение любого байта в уже существующем файле.  При работе ИС все внешние источники и получатели информации (обозначаются символом «Terminator»  ) можно условно разделить на следующие группы, с каждой из которых наша ИС может взаимодействовать различными способами:внешние информационные системы или технические средства сигналы от любых датчиков или любого оборудования («Direct data»  )файлы, которые были экспортированы какой-то ИС (модулем нашей ИС) и которые мы будем импортировать (  )мы напрямую получаем доступ к таблицам БД внешней ИС (  )мы получаем доступ к файловому хранилищу ИС, работающей в рамках архитектуры файл-сервер ( )взаимодействие по какому-либо прикладному протоколу по сети (  , где название – это название или код сообщения в соответствии с прикладным протоколом)пользователь (человек) вводит какой-либо документ, регламентируемый законодательством РФ, международным законодательством, внутренней учётной политикой в целях бухгалтерского и налогового учёта (НК РФ, ПБУ, 129-ФЗ «О бухгалтерском учёте»), иной внутрикорпоративной документацией («Document»  )вводит данные во внутреннюю экранную форму, не являющуюся формой ввода документа из п. 1 («Display»  )собственно сама моделируемая ИС или её модули (в случае если информационная модель строится отдельно для подсистем ИС работающих по отдельности) получает доступ к своим таблицам ( ), справочникам ( ), файлам ( ).При построении модели в рамках неё можно выделить семь логических уровней (присутствие всех из них одновременно не обязательно и зависит от содержания процесса обработки информации): источники информации ;первичные документы или файлы ;таблицы с первичными документами ;таблицы с промежуточной информацией ;таблицы с результатной информацией ;результатные документы или файлы ;получатели информации .Далее приведён условный пример части информационной модели задачи по приёму оплаты за мобильную связь кассиром \ операционистом банка.  Область 1 отображает процесс конфигурирования ИС в части ввода пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно было зафиксировать информацию о принявшем платёж сотруднике. Форма «Управление пользователями» предполагает выполнение двух видов операций: редактирование справочника прав пользователей (ролей); редактирование справочника пользователей. При этом, в ИС предполагается, что каждый пользователь может иметь строго одну роль, что отображено входящей связью из «Спр* «Права польз.»« в «Спр* «Пользователи»«. Область 2 отображает то, что из базы ИС в рамках моделируемой задачи используются два справочника и три таблицы. (Под справочником мы понимаем обычную таблицу, которая содержит условно-постоянную информацию). Область 3 отображает собственно процесс ввода платежа. Проектировщики предполагают, что ввод будет состоять из следующих этапов: сначала делается запись (либо производится обновление записи) в справочнике клиентов. Под клиентом понимается ФИО плательщика и какие-либо его данные (например паспортные данные). затем делается запись, отражающая факт совершения платежа. В рамках задачи предполагается два варианта его совершения: платёж принимается без открытия счёта; платёж выполняется с какого-либо счёта; (связь со справочником лицевых счетов при изменении «Т* «Проводки»«); в любом случае платёж должен поступить какому-либо оператору, что отражается связью со справочником «Спр «ОператорыМобСв»«, откуда получается номер его счёта. третьим этапов будет изменение остатков по лицевым счетам по факту выполнения проводки. (данное действие как раз отображает пример логического уровня 4 из информационной модели). Область 4 отображает то, что моделируема ИС предоставляет на выходе: клиент получает результатный документ, содержащий параметры совершённого платежа и являющийся его подтверждением. Из справочника «Спр «Клиенты»« используем текстовое наименование клиента; Из справочника «Спр «ОператорыМобСв»« получаем текстовое наименование оператора-получателя Из таблицы «Т «Проводки»« остальные реквизиты платежа. клиент (в случае, если у него открыт счёт) может получить выписку по нему: «Т «Остатки по л\счетам»« необходим, чтобы привести входящий и исходящий остатки на период выписки «Спр «Лицевые счета»« - получение наименование счёта и срока его действия «Т «Проводки»« - собственно операции оператор мобильной связи по окончании какого-либо периода получает от банка файл(реестр) платежей. Его, в целом, интересует только сумма платежа и номер за которой он осуществлён. из «Спр «ОператорыМобСв»« получаем номер счёта оператора; из «Т «Проводки»« - собственно операции 2.2.2. Характеристика нормативно-справочной, входной и оперативной информации Пункт представляет собой описание состава входных документов, входных файлов и справочников, соответствующих им экранных форм размещения данных. При этом следует уделять внимание следующим вопросам: при описании входных документов необходимо: привести в приложении формы(макеты) документов и экранные формы для их ввода в систему; привести перечень содержащихся в них первичных показателей; привести источник получения документа; описать структуру документа, число строк, объемные данные, частоту возникновения документа; при описании входных файлов необходимо: привести перечень содержащихся в них первичных показателей; привести источник получения файла; описать структуру файла, объемные данные, частоту поступления файла; описание экранной формы входного документа должно содержать макет экранной формы, особенностей организации рабочей и служебной зон макета, состав и содержание подсказок, необходимых пользователю для заполнения макета, перечень справочников, автоматически подключаемых при заполнении этого макета; при описании справочников необходимо: построить сводную таблицу, содержащую: название справочника; ответственного за его ведение; средний объём справочника в записях; среднюю частоту актуализации; средний объем актуализации (в записях или в процентах); по каждому справочнику необходимо описать его реквизитный состав. 2.2.4 Характеристика результатной информации В этом подразделе должны быть описаны таблицы (или файлы) с перечнем полей, полученных при выполнении запросов. При этом здесь следует указать на основе каких таблиц с переменной или условно-постоянной информацией базы данных были получены таблицы с результатной информацией и какой документ получается в итоге. Далее должны быть приведены основные параметры каждой таблицы с указанием, подлежит ли она дальнейшему хранению или нет. Характеристика результатных документов является одним из важных пунктов всей проектной части и представляет собой обзор результатов решения поставленных в аналитической части задач с точки зрения предметной технологии. Если решение представляет собой формирование ведомостей (в виде экранных или печатных форм), каждую ведомость необходимо описать отдельно (в приложении следует привести заполненные экземпляры ведомостей и экранных форм документов). В частности, какое место занимает ведомость в информационных потоках предприятия (служит для оперативного управления или для отчетности), является уточняющей или обобщающей и т. д.). Каждая ведомость должна иметь итоги, не включать избыточной информации, быть универсальной. Далее приводится описание печатных форм, экранных макетов с перечислением и краткой характеристикой содержащихся показателей для каждого документа указывается, на основе каких таблиц получается этот документ. Если результатная информация предоставляется не в виде ведомостей (например, при проектировании подсистемы распределенной обработки данных), необходимо подробно описать структуру сообщения и его дальнейший путь, основываясь на имеющейся организации многопользовательской ИС. Для результатных файлов описывается: их структура и реквизитный состав; частота их формирования; на основе каких таблиц они формируются; каким способом доставляются до ИС – получателя файла. 2.3.1.Общие положения (дерево функций и сценарий диалога) В данном пункте следует привести иерархию функций управления и обработки данных, которые призван автоматизировать разрабатываемый программный продукт. При этом можно выделить и детализировать два подмножества функций: реализующих служебные функции (например, проверки пароля, ведения календаря, архивации баз данных, тьютора и др.) и реализующих основные функции управления и обработки данных: ввода первичной информации, обработки, ведения справочников, ответов на запросы и др. Выявление состава функций, их иерархии и выбор языка общения (например, языка типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность. При разработке структуры диалога необходимо предусмотреть возможность работы с экранными формами входных документов, формирование выходных документов, корректировки вводимых данных, просмотра введенной информации, работу с таблицами нормативно-справочной информации, протоколирования действий пользователя, а также помощь на всех этапах работы.  Пример фрагмента дерева функций В этом пункте следует выбрать способ описания диалога. Как правило, применяется два способа описания диалога. Первый предполагает использование табличной формы описания. Второй использует представление структуры диалога в виде орграфа, вершины которого перенумерованы, а описание его содержания в соответствии с нумерацией вершин, либо в виде экранов, если сообщения относительно просты, либо в виде таблицы. Диалог в ИС не всегда можно формализовать в структурной форме. Как правило, диалог в явном виде реализован в тех ИС, которые жестко привязаны к исполнению предметной технологии. В некоторых сложных ИС (например, в экспертных системах) диалог не формализуется в структурной форме и тогда данный пункт может не содержать описанных схем. Описание диалога, реализованного с использованием контекстно-зависимого меню не требует нестандартного подхода. Необходимо лишь однозначно определить все уровни, на которых пользователь принимает решение относительно следующего действия, а также обосновать решение об использовании именно этой технологии (описать дополнительные функции, контекстные подсказки и т.д.) . Схема, описывающая дерево диалога, должна обязательно сопровождаться пояснениями по действиям, выполняемым в каждом пункте меню.  Пример фрагмента сценария диалога 2.3.2. Характеристика базы данных ER модель предполагает определение состава и взаимосвязей таблиц, отражающих содержание информационной модели в терминах конкретной СУБД, выбранной в п.1.4. Описание каждой таблицы должно содержать (необходимо выполнять в виде таблиц) наименование полей, идентификатор каждого поля, его шаблон, тип данных, длину поля и описание поля. По каждой таблице должна быть информация о ключевом поле, длине одной записи, числе записей в таблице, частоте создания таблицы (в случае применения динамических или временных таблиц), длительности хранения, возможности индексирования. Пример фрагмента описания структуры записей таблицы «Контрагенты»
Необходимо отметить соответствие проектируемых таблиц входным документам или справочникам. В случае, когда ER модель получена путем конвертации из инфологической модели с помощью CASE – средств, она должна отражать полный состав сущностей и связей инфологической модели. Если информационная база организована в форме корпоративной базы данных, то приводится описание и других её элементов: распределение прав доступа, бизнес-правил, триггеров и др.  Пример фрагмента ER модели 2.3.3 Структурная схема пакета (дерево вызова процедур и программ) На основе результатов, полученных в предыдущем пункте, строится дерево программных модулей, отражающих структурную схему пакета, содержащей программные модули различных классов: выполняющие служебные функции; управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю; модули, связанные с вводом, хранением, обработкой и выдачей информации. В данном пункте необходимо для каждого модуля указать идентификатор и выполняемые функции. Эти данные должны быть представлены в форме таблицы. Пример фрагмента таблицы описания функций модулей
Если проектирование ведется с помощью языков четвертого поколения, например генераторов экранных форм, отчетов, то эту схему следует преобразовать в схему настройки, отражающей виды и состав используемых объектов проектирования по каждому виду, применяемых в этих средствах: «Форм», «Отчетов», «Запросов» и «Кнопочная форма». Описание программных модулей Описание программных модулей должно включать блок-схемы (возможно привести блок-схему одного из расчётных модулей) и описание блок-схем алгоритмов основных расчетных модулей (объемом не менее 500 операторов) или настройки программных модулей (при внедрении типовых информационных систем). Контрольный пример реализации проекта и его описание Контрольный пример включает описание: тестовых данных, которые необходимы для проверки работоспособности основных функций реализованного проекта (данные для заполнения справочников, данные для заполнения файлов оперативной информации). Приведенные тестовые данные должны быть введены в соответствующие поля форм ввода и могут быть показаны в приложениях (экранные формы с тестовыми данными); процесса обработки тестовых данных (различные сообщения и другие элементы диалога, который возникает в процессе обработки). Данное описание также может быть показано в приложениях; результатов обработки тестовых данных (рассчитанные показатели, сформированные ведомости, отчеты и т.п.). Результаты так же могут быть отображены в соответствующих приложениях. Особое внимание следует обратить на целостность контрольного примера и правильность полученных результатов обработки тестовых данных, а именно – полученные данные должны быть проверены на правильность расчета по приведенным формулам в разделе формализации расчетов. Тестовые данные, экранные формы, результаты обработки обязательно должны соответствовать поставленной задаче и отражать процесс ее решения. Наиболее простым вариантом представления контрольного примера является демонстрация алгоритма работы системы в виде документов и экранных форм с соответствующими комментариями. Для наглядной демонстрации количество экранных форм и документов должно быть не менее 10. Например, для задачи «автоматизация расчета себестоимости изделий» алгоритм может быть следующим: экранная форма входа в систему; экранная форма входа в меню расчета; экранные формы ввода нормативно-справочной информации (номеклатура изделий, ставки оплаты труда, учетные цены на материалы, перечень производственных работ, нормы накладных расходов и так далее); формы документов, необходимые для расчета (технологическая карта изделия, технологическая комплектация изделия); экранные формы ввода данных из вышеуказанных форм; экранная форма введенных данных для расчета себестоимости (трудоемкость изготовления и нормы расхода материалов); экранная форма запуска расчета себестоимости; экранная форма с результатами расчета; форма документа «Себестоимость изделия» |