2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Сам стандарт MSF даёт некую гарантию минимизации рисков, так как весь ЖЦ проекта разделён на этапы, на каждом этапе есть роли, за которыми закреплены цели, которые должны быть достигнуты и всё же на каждой фазе есть некоторые риски:
В фазе выработки концепции могут возникнуть следующие риски: недальновидный анализ сроков проекта и его бюджета.
Для ликвидации такого рода риска нужно более детально прорабатывать задачи и цели проекта, ставить больше контрольных точек.
Неправильно подобранный проектный состав исполнителей может повлечь полное отсутствие командной работы.
Данный риск уменьшается более тщательным подбором специалистов в проектную группу тестированием не только профессиональных навыков но и личностных качеств.
На фазе планирования могут возникнуть следующие риски:
Неправильно или не совсем корректно сформированная архитектура выбираемого решения.
Возможность появления этого риска зависит от компетенции руководителя проекта, на котором лежит принятие решение о выборе архитектуры разрабатываемого решения.
В фазе разработки возможны следующие риски:
Неправильная интерпретация технического задания и как следствие неправильное программирование архитектуры и сдвиг сроков.
Минимизацией данного риска служит более чёткое написание технического задания, понятного программисту.
Еще одним немаловажным риском в данном проекте является отсутствие должной квалификации у программиста в том языке, на котором решено реализовывать программу клиент, которая будет распределять заявки между инженерами.
В случае, если программист не будет укладываться в заданные временные рамки календарного плана проекта, придется использовать внешнего разработчика, так называемый «аутсорсинг» или «фриланс».
В фазе тестирования могут возникнуть следующие риски:
Риски неоконченного тестирования.
Может произойти ситуация что программный продукт будет протестирован не до конца.
Решается путем повторного тестирования на следующей итерации разработки.
В фазе внедрения могут возникнуть следующие риски:
Риски неправильного принятия решения о законченности части проекта.
Возникновение данных рисков ведет за собой проблему незаконченности решения и возможность возникновения нестыковок с другими частями разрабатываемой ИС.
Устраняется путем доработки при следующей итерации. [12]
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализаций информационной безопасности.
Защита от внутренних угроз. Подразумевает разграничение прав пользователей. Подробные права пользователей описаны в таблице 2.7
Таблица № 2.7
Разграничение прав пользователей.
Также предприятие использует простой идентификатор пользователя / пароля. Оказывается, эту однофакторную аутентификацию чрезвычайно легко взломать. Надлежащая политика паролей должна быть введена в действие, чтобы гарантировать, что пароли не могут быть скомпрометированы. Ниже приведены некоторая политика предприятия, которые организация применяет.В компании ООО «Техторг» используются все возможные методы защиты информации, так как нет уникального одного метода, который смог бы обеспечить полную информационную безопасность, а сочетание всех методов позволяет реализовать максимальную информационную безопасность.
Требует сложные пароли. Одна из причин взлома паролей заключается в том, что их легко угадать. Недавнее исследование показало, что тремя основными паролями, которые люди использовали в 2012 году, были пароли, 123456 и 12345678 . [13] Пароль не должен быть простым словом, которое можно найти в словаре. В первую очередь хакер попытается взломать пароль, проверив каждый термин в словаре. Вместо этого, хорошая политика паролей — это политика, которая требует использования как минимум восьми символов и как минимум одной заглавной буквы, одного специального символа и одного числа.
Меняйте пароли регулярно. Важно, чтобы пользователи регулярно меняли свои пароли. Пользователи должны менять свои пароли каждые шестьдесят или девяносто дней, гарантируя, что любые пароли, которые могли быть украдены или угаданы, не смогут быть использованы против компании.
Обучать сотрудников не выдавать пароли. Один из основных методов, которые используются для кражи паролей, просто выяснить их, спросив пользователей или администраторов. Данный метод называется «Социальная инженерия», происходит, когда злоумышленник вызывает службу поддержки или администратора безопасности и притворяется, что он является конкретным авторизованным пользователем, испытывающим трудности при входе в систему. Затем, предоставив некоторую личную информацию об авторизованном пользователе, злоумышленник убеждает сотрудника по безопасности сбросить пароль и сказать ему новый. Другой способ, с помощью которого сотрудники могут обмануть пароли, — это «Фишинг» по электронной почте. Фишинг возникает, когда пользователь получает электронное письмо, которое выглядит так, как будто оно поступило из надежного источника, такого как его банк или работодатель. В электронном письме пользователю предлагается щелкнуть ссылку и войти на веб-сайт, который имитирует подлинный веб-сайт, и ввести свой идентификатор и пароль. [13]
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
На рис. 2.6 приведена информационная модель в виде схемы.
Рисунок 2.6 – Информационная модель
Данная информационная модель включает некоторые источники. Основной базой данных является созданная база данных Техторг. В ней находятся информация о работнике, информация о клиенте, информация о филиале, информация о заказе, информация по ремонту.
Для того чтобы войти в систему пользователь вводит логин и пароль, после логин и пароль проверяется в самой базе, затем осуществляется вход в систему. После чего пользователь имеет доступ к такому функционалу:
- просмотреть все заказы и вывести все на печать;
- просмотреть сотрудников и их работу;
- просмотреть работу по филиалам;
- просмотреть ремонт техники.
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В данной выпускной работе автоматизируется документооборот предприятия, это та работа, которая вводится вручную. Сценарий просмотра, сколько сотрудник выполнил работы в этом месяце на рис. 2.7
Рисунок 2.7 – сценария просмотра сотрудников
Программа согласно заложенной в неё логике обрабатывает всю информацию по заказам, зарплате и ремонтах.
Любой функционал программы можно разделить на основной, с помощью которой достигается основная цель алгоритма программы и дополнительный (служебный) это то, что можно настроить изменить, прояснить. Дерево функций как раз наглядно демонстрирует разделение данных функций. Дерево функций изображено на рисунке 2.8
Рисунок 2.8 – Дерево функций
2.3.2. Характеристика базы данных
Разработка концептуальной модели предметной области.
В результате анализа требований пользователя и структур данных, описывающих деятельность, обработка документооборота, определены как сущности следующие объекты:
- Филиалы (Код_филиала – первичный ключ)
- Города (Код_города – первичный ключ)
- Клиенты (Код_клиента – первичный ключ)
- Поставщики (Код_поставщика – первичный ключ)
- Ремонт (Код_ремонта – первичный ключ)
- Работники (Код_работника – первичный ключ)
Первичный вариант концептуальной модели данных предметной области представляем в виде диаграммы «сущностей-связей» (ER-диаграммы), разработанной в программе yEd, показано на рисунке 2.16
При этом минимальная информация, изображаемая на диаграмме, должна содержать следующие пять элементов данных:
- сущности, изображаемые в виде прямоугольников произвольного размера;
- ключи сущностей, изображаемые в виде подчеркнутых надписей рядом с прямоугольником с любой стороны;
- связи, изображаемые в виде ромбов произвольного размера и соединенных прямыми линиями с соответствующими сущностями, эти линии могут быть произвольного наклона и, по возможности, без пересечений;
- степень участия в связи для каждой сущности, изображаемая в виде числа или буквы около соответствующего прямоугольника-сущности и линии связи;
- полнота участия в связи для каждой сущности, изображаемая в виде точки перед символом-степенью участия, при этом наличие точки означает полное участие в связи данной сущности, т.е. значение обязательный.
Каких-либо строгих правил для изображения диаграммы ER-типов не существует. В различных коммерческих системах (CASE средствах) проектирования БД используется и другая нотация для изображения ER-диаграмм, наиболее известными из них являются нотация «куриных лапок» и нотация стандарта IDEF1X. Однако, для обсуждения результатов проектирования с будущими пользователями БД удобнее всего представить диаграмму ER-типов в нотации, предложенной впервые П. Ченом, т.е. в виде прямоугольников и ромбов. [14]
В процессе документооборота сущности взаимодействуют друг с другом. В концептуальной модели взаимодействие между сущностями выражается с помощью связей [14], основными из которых являются следующие.
В связи Филиалы — Города (М: М) независимо от класса принадлежности сущностей формируются три отношения, два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений. Связь изображена на рисунке 2.9
Рисунок 2.9 – Сущность связь (филиалы и города)
В связи Филиалы — Техника (М: М) независимо от класса принадлежности сущностей формируются три отношения, два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений. Связь изображена на рисунке 2.10
Рисунок 2.10 – Сущность связь (филиалы и техника)
В связи Заказы — Техника (М: М) независимо от класса принадлежности сущностей формируются три отношения, два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений. Связь изображена на рисунке 2.11
Рисунок 2.11 – Сущность связь (заказы и техника)
В связи Города — Филиалы (1: М) класс принадлежности сущности Филиалы будет обязательным. Согласно правилу 3, первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит внешним ключом. И строится 2 таблицы.
Рисунок 2.12 – Сущность связь (города и филиалы)
В связи Сотрудники — Ремонт (1: М) класс принадлежности сущности Ремонт будет обязательным. Согласно правилу 3, первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит внешним ключом. И строится 2 таблицы.
Рисунок 2.13 – Сущность связь (сотрудники и ремонт)
В связи Сотрудники — Ремонт (1: М) класс принадлежности сущности Ремонт будет обязательным. Согласно правилу 3, первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит внешним ключом. И строится 2 таблицы.
Рисунок 2.14 – Сущность связь (клиенты и ремонт)
В связи Сотрудники — Заказы (1: М) класс принадлежности сущности заказы будет обязательным. Согласно правилу 3, первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит внешним ключом. И строится 2 таблицы.
Рисунок 2.15 – Сущность связь (сотрудники и заказы)
Рисунок 2.16 – ERD-модель
Логическая модель. Разработка логической модели базы данных.
После того, как концептуальная модель одобрена, можно перейти к этапу логического проектирования БД. При этом исходными данными для проектирования являются диаграмма ER-типов концептуальной модели предметной области и логическая модель данных, используемая для реализации будущей БД и поддерживаемая какой-либо коммерческой СУБД. [15]
В качестве логической модели данных выбираем реляционную модель когда, как наиболее распространенную в большинстве современных СУБД. [16] Теперь следует преобразовать концептуальную модель в соответствии с требованиями реляционной модели данных.
Таким образом, формально этап логического проектирования БД может в проекте отсутствовать, но при этом следует иметь в виду, что при выполнении преобразования диаграммы ER-типов в схему БД с помощью выше изложенных правил 1-8, мы, фактически и выполняем логическое проектирование БД с использованием реляционной логической модели данных. И в любом случае получаем логическую модель, в которой все объекты представлены как сущности (сильные или слабые) и связи один ко многим и один к одному (сильные или слабые).
Еще одним ограничением реляционной модели данных является требование нормализации всех сущностей-отношений. Это требование часто называют первой нормальной формой (1НФ). Оно заключается в том, чтобы все атрибуты в БД были атомарными с точки зрения СУБД. Атомарность означает неделимость каждого значения данных на многие значения, например не допускается иметь в БД атрибутов, представляющих собой списки значений (множественные значения), как-то: номера телефонов, оценки, дни работы и т.д. Не допускается иметь в БД и атрибуты составные, например адрес, включающий город, улицу, дом, квартиру при условии, что в процессе использования БД потребуется обращение к какой-либо части этого адреса.
Во всех этих случаях требуется на этапе логического проектирования обязательно провести нормализацию каждого отношения, т.е. привести его к 1НФ.
На следующем шаге проектирования необходимо оценить полученные отношения с точки зрения нормальных форм более высокого порядка. Причем, из пяти нормальных форм, известных в настоящее время 2НФ, 3НФ. НФБК, 4НФ и 5НФ, на практике, как правило, бывает вполне достаточно обеспечить третью нормальную форму или НФБК (усиленную 3НФ). В крайнем случае, можно вообще не заниматься вопросами приведения БД к той или иной НФ, но при этом надо помнить о том, что надежность проекта будет тем ниже, чем сложнее БД и чем большие требования предъявляются к целостности данных.
Чтобы провести проверку на уровень нормализации БД, необходимо:
- разместить все атрибуты во всех полученных сущностях-отношениях (слабых и сильных);
- выявить в каждом отношении потенциальные ключи;
- выявить все функциональные зависимости (ФЗ) между атрибутами в каждом отношении;
- сопоставить потенциальные ключи с детерминантами ФЗ (их левыми частями);
- если какой-либо детерминант отношения не совпадает ни с одним потенциальным ключом этого же отношения, то данное отношение не находится в той или иной НФ и его требуется нормализовать в соответствии с теорией нормальных форм.
Заключение
В наше время очень сложно, даже практически невозможно представить свою жизнь без различных современных технологий. Они стали неотъемлемой частью жизни людей и применяются в различной деятельности человека. Технический прогресс продолжает развиваться, и с каждым днём мы можем наблюдать за новинками и совершенствованиями в электронной технике, новыми открытиями в информационной сфере, большим влиянием информационных и интернет-технологий в жизни людей. Порой даже немыслимо осознавать то, что в прошлом человек жил без электронных технологий и доступа к ним. Если обратиться к научной точке зрения, то информационные технологии представляют весь накопленный опыт человечества в универсальном виде, пригодном для практического использования. Любая сфера деятельности в наши дни требует не только тщательного анализа эффективности труда, но и применение современных технологий управления различными ресурсами, благодаря которым стало возможным обеспечить наилучшее качество выполнения различных задач.
Еще одну сложность управления создает необходимость осуществления контроля выполнения различных работ, мониторинг ресурсов и прочего. Все эти процессы возможно упростить внедрив использование общего пространства обмена информацией, результатами выполнения задач и единой оценкой трудовых ресурсов. Благодаря всем этим мерам возможно осуществление рационального распределения рабочей силы с целью максимальной выгоды организации их исполнения.
Данный подход, который был осуществлен в процессе написания дипломного проекта обеспечит выполнение этих условий с применением самых современных технологий, таким образом управление организацией значительно облегчится, модернизируется и станет более продуктивным, что в свою очередь повысит эффективность всей компании в целом.
В проекте рассматриваются все этапы внедрения и доработки ИС, от аналитической разработки проекта, до внедрения проекта на предприятии.
Исходя из цели и поставленных задач, была определена структура данного дипломного проекта. Был произведён анализ деятельности компании и описание услуг, анализ алгоритмов для создания системы, представлена программная реализация для написания приложения и описан результат работы системы.
Результатом решения поставленных задач является создание частичной автоматизированной обработки документов информационной системы.
В начале выполнения выпускной работы были изложены теоретические основы построения. Был выполнен комплекс мер, направленных на обоснование необходимости автоматизации: определена сущность задачи, описаны основные свойства системы, дано описание всех существующих бизнес-процессов, рассмотрены вопросы, связанные с анализом существующих разработок в этой области. Также в первой главе обосновываются проектные решения по информационному, программному, техническому и технологическому обеспечению.
Проектная часть посвящена рассмотрению этапов жизненного цикла проекта. Также дана характеристика информационной архитектуры разрабатываемого проекта, построена информационная модель задачи. Были рассмотрены различные методы приобретения программного продукта и выявлено наиболее подходящее решение. Рассмотрены наиболее важные этапы разработки проекта, определены технические и программные средства, необходимые для реализации данного проекта.
В ходе проектирования базы данных были пройдены все этапы проектирования: описание информационных объектов предметной области, проектирование инфологической модели предметной области, логическое и физическое проектирование БД. В качестве СУБД была выбрана MS Server.
Для разработки системы была выбрана концепция Windows-приложения с использованием Microsoft Entity Framework. В качестве среды разработки была выбрана среда Visual Studio.
В результате была создана программа, представляющая клиентское приложение для оформления и просмотра отчетности по документообороту:
— введена авторизация;
— разработана возможность просматривать работу по сотрудникам;
— разработана возможность отслеживания ремонтов.
Программа отвечает основным заявленным требованиям и реализует интуитивно понятный интерфейс.
Результатом проекта являются улучшения показателей работы компании, за счет автоматизации документооборота и управления взаимоотношениями с работниками компании ООО «Техторг».
В конце проекта приводятся данные об экономической эффективности проекта, на основании этих расчетов можно сделать вывод, что проект автоматизации задачи учета товаров и услуг в компании ООО «Техторг» является быстро окупаемым и целесообразным.
Результатом проекта являются улучшения показателей работы компании, за счет автоматизации документооборота ООО «Техторг».
Список литературы
- «Основные понятия методологии и языка IDEF0» ГОССТАНДАРТ РОССИИ Руководящий документ IDEF0-2000. Методология функционального моделирования IDEF0. Принят и введен в действие 2000 г.
- Мишенин А. И. «Теория экономических информационных систем» / Москва: Финансы и статистика, 2007г. – 240 с.: ил.;
- Микрюков В. Ю. «Информация, информатика, компьютер, информационные системы, сети» / Москва: Феникс, 2007г. – 448 с.: ил.;
- Информационная система — Wikimedia Foundation https://dic.academic.ru/dic.nsf/ruwiki/101791#cite_note-6
- Остроух А. В. «Ввод и обработка цифровой информации» / Академия — Москва, 2012. — 288 c.
- Коробов Н. А. «Информационные технологии в торговле» / Н.А. Коробов, А.Ю. Комлев. — М.: Академия, 2016. — 176 c.
- Криницкий, Н.А. «Автоматизированные информационные системы» / Н.А. Криницкий, Г.А. Миронов, Г.Д. Фролов. — М.: Наука, 2017. — 382 c.
- НОУ «Интуит» Лекция: Классификация программного обеспечения https://www.intuit.ru/studies/courses/3632/874/lecture/14291
- ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология (ИТ). Системная и программная инженерия. Процессы жизненного цикла программных средств. Руководящий документ Национальный стандарт РФ. Дата введения 2012-03-01
- Майкл С. В. Тернер «Основы Microsoft Solution Framework» / Майкл С.В. Тернер. — М.: Русская Редакция, Питер, 2008. — 336 c.
- Ицхак Калдерон Адизес «Управление жизненным циклом корпораций» / Манн, Иванов и Фербер, 2014. – 700 с. : ил.;
- Избачков С.Ю., Петров В.Н. «Информационные системы» / СПб.: Питер, 2008. – 655 с
- Гулиян Г.Б., Нестеров И.А. «Основы организации компьютерных сетей. Часть 1.» / Московская финансово-промышленная академия. – М., 2007г. – 169 с. ил.;
- Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. «Базы данных» / Учебник, Корона – Век, 2010г. – 736 с.: ил.;
- Томас Коннолли, Каролин Бегг «Базы данных. Проектирование, реализация и сопровождение. Теория и практика» / Вильямс 2016 г. -240 с.: ил;
- Крис Дейт «Введение в системы баз данных» / Диалектика 2016 г. – 20 с.: ил.;
- Тарасов Сергей Витальевич «Сергей Тарасов: СУБД для программиста. Базы данных изнутри» / Солон-пресс 2015 г. – 60 с.: ил.;
- Руководство по Entity Framework – Введение в Entity Framework https://metanit.com/sharp/entityframework/1.1.php
- О. С. Сухарев «Теория эффективности экономики” / КУРС, Инфра-М 2015 г. — 40 с.: ил..