ррр. Методы и средства защиты КИ. Проблемы проектирования

Название	Проблемы проектирования
Дата	11.04.2022
Размер	43.16 Kb.
Формат файла
Имя файла	Методы и средства защиты КИ.docx
Тип	Реферат #463366

Министерство науки и высшего образования
Российской Федерации

Федеральное государственное бюджетное образовательное
учреждение высшего образования

«Казанский национальный исследовательский
технологический университет»

(ФГБОУ ВО «КНИТУ»)

КМИЦ “Новые технологии»

РЕФЕРАТ

по дисциплине: «Методы и средства защиты компьютерной информации»

Тема: «Проблемы проектирования»

Выполнил: студент 3 курса

Мавлиев Айрат Маратович

группы 1292-Ц15

Проверил (а): _______________________

г.Казань 2022г.

ВВЕДЕНИЕ

В процессе выполнения своей работы приходится решать разного рода задачи. Эти задачи могут быть сложными и ответственными, требовать оригинальное решение. А могут быть простыми, уже имеющими решение в виде инструкций и алгоритмов. Но любая задача, поставленная перед человеком, является творческой, поскольку никогда заранее не известны все ее условия, абсолютно четко не определены цели, что приводит к появлению ряда решений и необходимости выбора одного из них. Поэтому от того, насколько грамотно мы сумеем решать задачи (в т.ч. производственные), будет зависеть эффективность результатов нашей деятельности.

Поиск оригинальных решений и идей в настоящее время ведется посредством применения эвристических методов (методов изобретательного творчества). Однако в случае производственной деятельности решение таких задач также включает подготовительные стадии, оформление и утверждение результатов, оценку эффективности и другие виды работ. Весь этот цикл взаимосвязанных и взаимообусловленных работ составляет проектирование.

Проектирование объединяет с творчеством направленность на создание качественно нового (слово «проектирование» происходит от лат. projectus, что буквально означает брошенный вперед), но это более общее понятие.

Существует много определений термина «проектирование». Но чаще всего под «проектированием» подразумевают практическую деятельность, направленную на удовлетворение новых потребностей людей. Конечным итогом проектной деятельности является проект, т.е. комплект документации, предназначенной для создания определенного объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект. Объектом проектирования может быть материальный предмет, выполнение работы, оказание услуги.
Слово «проект» еще применяется в значении «программа», «план действий».

Проектирование связано не только с техническими объектами. Так, имеется социальное проектирование, проектирование программного обеспечения и другие. Отличительной особенностью проектирования является его практическая направленность (обязательное наличие практических результатов, иначе это будет «прожект», «маниловщина», творчество ради творчества) и персональная ответственность за полученные и переданные заказчику результаты.

Внутри процесса проектирования, наряду с расчетными этапами и экспериментальными исследованиями, часто выделяют процесс конструирования. Конструирование — деятельность по созданию материального образа разрабатываемого объекта, ему свойственна работа с физическими моделями и их графическими изображениями. Эти модели и изображения, а также некоторые виды изделий называют конструкциями.

СТРУКТУРА ПРОЕКТИРОВАНИЯ

Проектирование, как осознанная целенаправленная деятельность, обладает определенной структурой, т.е. последовательностью и составом стадий и этапов разработки проекта, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.

У каждого из нас на основе личного опыта выработалось свое представление о структуре проектной (творческой) деятельности. Однако за длительный период существования человечества сформировались и общепринятые, проверенные практикой подходы к проектированию и его структура.

В настоящее время существуют два представления структуры проектирования, подобные по форме, но различные по целям и подходам к деятельности. Это — структура в виде стадий разработки проектной документации (стадий проектирования) и структура процесса проектирования.

Стадии проектирования

Соответствующая им структура регламентирована стандартом (ГОСТ 2.103, 15.201) и используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ.

Данная структура устанавливает стадии разработки конструкторской документации изделий всех отраслей промышленности и этапы выполнения работ. Эта документация необходима для отчета перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации. Основные стадии (этапы) структуры представлены.

Техническое задание (ТЗ) устанавливает основное назначение, технические и тактикотехнические характеристики, показатели качества и технико-экономические требования к разрабатываемому объекту, предписание по выполнению необходимых стадий создания документации и ее состав, а также специальные требования к изделию.

Техническое предложение (ПТ) — совокупность документов, содержащих техническое и технико-экономическое обоснование (ТЭО) целесообразности разработки проекта. Такое заключение дается на основании анализа ТЗ заказчика и различных вариантов возможных решений, их сравнительной оценки с учетом особенностей разрабатываемого и существующих изделий, а также патентных материалов.

Согласованное и утвержденное в установленном (на предприятии, в министерстве и т.п.) порядке ПТ является основанием для разработки эскизного проекта.

Эскизный проект (ЭП) — совокупность документов, содержащих принципиальные решения и дающих общее представление об устройстве и принципе работы разрабатываемого объекта, а также данные, определяющие его назначение, основные параметры и габаритные размеры. В случае большой сложности объекта этому этапу может предшествовать аванпроект (предпроектное исследование), обычно содержащий теоретические исследования, предназначенные для обоснования принципиальной возможности и целесообразности создания данного объекта.

При необходимости на стадии ЭП проводят изготовление и испытание макетов разрабатываемого объекта.

Технический проект (ТП) — совокупность документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве проектируемого объекта, исходные данные для разработки рабочей документации.

На стадии рабочего проекта (РП) сначала разрабатывают подробную документацию для изготовления опытного образца и последующего его испытания. Испытания проводят в ряд этапов (от заводских до приемо-сдаточных), по результатам которых корректируют проектные документы. Далее разрабатывают рабочую документацию для изготовления установочной серии, ее испытания, оснащения производственного процесса основных составных частей изделия. По результатам этого этапа снова корректируют проектные документы и разрабатывают рабочую документацию для изготовления и испытания головной (контрольной) серии. На основе документов окончательно отработанных и проверенных в производстве изделий, изготовленных по зафиксированному и полностью оснащенному технологическому процессу, затем разрабатывается завершающая рабочая документация установившегося производства.

В процессе разработки проектной документации (рис.2) в зависимости от сложности решаемой задачи допускается объединять между собой ряд этапов. Этапы постановки ТЗ и технического проектирования могут входить в цикл научно-исследовательских работ (НИР), а этапы технического предложения и эскизного проектирования — образовывать цикл опытно-конструкторских работ (ОКР).

Завершает цикл работ этап, подводящий итог проектной деятельности - сертификация. Ее назначение — определение уровня качества созданного изделия и подтверждение его соответствия требованиям тех стран, где предполагается его последующая реализация. Необходимость выделения этого этапа в виде самостоятельного вызвана тем, что в настоящее время экспорт продукции или ее реализация внутри страны во многих случаях недопустимы без наличия у нее сертификата качества.

Сертификацию осуществляют специальные организации (органы по сертификации), зарегистрированные в Госстандарте России. На основе анализа протоколов испытаний и состояния производства продукции и других факторов орган по сертификации дает оценку соответствия продукции установленным требованиям, оформляет и регистрирует сертификат. В течение всего срока действия сертификата за сертифицированной продукцией ведется инспекционный контроль.

Сертификация может быть обязательной или добровольной. Обязательной сертификации подлежат товары, на которые законами или стандартами установлены требования, обеспечивающие безопасность жизни и здоровья потребителей, охрану окружающей среды, предотвращение причинения вреда имуществу потребителя. Добровольная сертификация проводится по инициативе предприятий. Обычно это делается с целью официального подтверждения характеристик продукции, изготавливаемой предприятием, и, как следствие, повышения доверия к ней у потребителей.

Структура управления процессом проектирования

Правильное ведение документации облегчает взаимодействие участников процесса проектирования. Осознанный же подход к проектной деятельности позволяет не только быстро находить эффективные решения, но и управлять этой деятельностью.

В настоящее время, на основе исследований сущности процесса проектирования, разработаны рекомендации по ведению этой деятельности. Предложен ряд структур и алгоритмов проектирования, совпадающих в основных чертах и различающихся только в содержании или названии отдельных этапов. В результате их анализа и обобщения предложена структура.

Решение любой задачи начинается с ее осмысления и уточнения исходных данных. Те (технические) требования (ТТ), которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость ее решения, т.е. сформулировать техническое задание, — первый и обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком.

В машиностроении этот этап иногда называют внешним проектированием. Этим подчеркивается, что разработка объекта уже начинается с постановки задачи (ТТ) и формирования ТЗ и активно ведется совместно с заказчиком.

Следующие этапы образуют внутреннее проектирование. Они нацелены на поиск решения задачи и выполняются разработчиком. Сюда входят этапы синтеза принципа действия, структуры и параметров проектируемого объекта.

На этапе синтеза принципа действия отыскивают принципиальные положения, физические, социальные и т.п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведется с принципиальными моделями и их графическим представлением — блок-схемами. Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103.

На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления объекта — структуры, схемы, алгоритмы, упрощенные эскизы. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования.

На этапе параметрического синтеза отыскиваются значения параметров объекта, находится численное решение проектной задачи, создается подробная документация или описание объекта, чертежи изделия и его частей. Этот этап соответствует стадиям технического и рабочего проектирования.

В процессе решения задачи появляется потребность в разработке дополнительных частей и узлов. Решение частных проектных задач, дополняющих основное решение, также проводится в соответствии с представленной последовательностью.

На каждом этапе внутреннего проектирования выполняются следующие процедуры:

выбор модели (т.е. основополагающего принципа, вида блок-схемы и расчетной схемы),
выбор метода решения,
решение,
анализ полученных результатов и принятие решения.

Замечено, что эффективность проектируемого объекта определяется: в первую очередь — выбранным принципом действия, во вторую — предложенной структурой и в третью — соотношением параметров.

Ведение разработки последовательно от общих черт проектируемого объекта к детальным частным называется нисходящим проектированием. Его результатом будут требования к отдельным частям и узлам.

Возможен ход разработки от частного к общему, что образует процесс восходящего проектирования. Такое проектирование встречается, если одна или несколько частей уже являются готовыми (покупными или уже разработанными) изделиями. Результатом проектирования будет частная документация на узлы.

Нисходящее и восходящее проектирование обладают своими достоинствами и недостатками. Так, при нисходящем проектировании возможно появление требований, впоследствии оказывающихся нереализуемыми по технологическим, экологическим или иным соображениям. При восходящем проектировании возможно получение объекта, не соответствующего заданным требованиям. В реальной жизни, вследствие итерационного характера проектирования, оба его вида взаимосвязаны.

ОСНОВНЫЕ ПРОБЛЕМЫ И ПРИНЦИПЫ

ПРОЕКТИРОВАНИЯ СИСТЕМ

Основными проблемами проектирования являются:

• реализуемость разработки системы в заданные сроки;

• выбор уровня сложности технических решений;

• обеспечение технологичности применения системы;

• проблема внедрения системы;

• обеспечение функциональной и структурной гибкости системы;

• создание нормативных документов, регламентирующих создание системы;

• проблема терминологии.

Проблема реализуемости системы в заданные сроки обусловлена несколькими причинами:

• использование недостаточно совершенных методов прогнозирования сроков создания сложных систем;

• необходимость учета новых требований к системе, возникающих в ходе ее разработки и внедрения;

• разработка в процессе создания самой системы необоснованно большого количества новых технических и программных средств (например, вычислительных систем и комплексов, рабочих мест, средств отображения, аппаратуры обеспечения безопасности функционирования, аппаратуры первичного и вторичного электропитания, средств вентиляции, а иногда даже новой элементной и конструктивной базы; операционных систем, программ специального назначения и т.д.).

Назначение недостаточно обоснованных сроков приводит к тому, что проектирующие организации несвоевременно завершают разработку системы или внедряют ее с большими недоделками. Необходимость учета новых требований приводит к дополнительным структурным или функциональным изменениям в системе, что также затягивает сроки. Как показывает опыт проектирования, новые требования всегда возникают в дополнение к ранее разработанному ТТЗ, и их игнорирование может поставить под сомнение целесообразность внедрения системы. Проблема выбора уровня сложности технических решений возникла вследствие неудачных попыток реализовать слишком сложные проекты систем. Данная проблема обусловлена следующими причинами:

• стремлением максимально усложнить процессы функционирования систем;

• включением в проекты большого количества вновь разрабатываемых «собственных» нестандартных элементов;

• неоправданно высокими требованиями заказчиков.

Для решения проблемы необходимо искать так называемую рабочую область практически реализуемых проектных решений, приводящих к созданию эффективной системы в заданные сроки. Проблема технологичности применения систем вызвана, прежде всего, отсутствием достаточно простых средств и методов общения операторов с техническими средствами, сложностью разработки и отладки новых программ, недостаточным уровнем подготовки персонала, эксплуатирующего средства системы.

Проблема внедрения заключается в определении рациональной последовательности поэтапного ввода системы в эксплуатацию, а также в разработке и своевременной реализации комплекса мероприятий, обеспечивающих подготовку персонала. Этапность разработки и внедрения должна быть определена на преднроектной стадии и отражена в ТТЗ, а окончательно содержание и сроки выполнения отдельных этапов могут быть уточнены в ходе эскизного и технического проектов.

Проблема обеспечения структурной и функциональной гибкости системы заключается в необходимости выбора при ее создании таких технических решений, которые бы обеспечивали возможность дальнейшего эволюционного развития системы и ее адаптации к изменяющимся требованиям потребителя.

Проблема нормативных документов возникает тогда, когда для разрабатываемой системы не полностью разработан комплекс взаимоувязанных и согласованных документов, определяющих порядок и методы проектирования на всех этапах, уровнях и направлениях создания больших систем. Во многих случаях используемые государственные и отраслевые стандарты, а также другие нормативные правовые документы и различные методики не полностью решают эту проблему. Поэтому ЖЦ системы должен начинаться с разработки, согласования и утверждения таких документов.

Проблема терминологии заключается в том, что многие термины и понятия, используемые в процессе создания и применения больших систем, получают неоднозначное толкование и противоречат друг другу. Все это приводит к возникновению терминологических барьеров между отдельными коллективами разработчиков систем, а также между разработчиками и заказчиками. Основной путь решения данной проблемы заключается в создании общегосударственных словарей терминов. В настоящее время такие словари, как правило, создаются только в пределах отдельных проектов.

Перечисленные проблемы нашли свое частичное разрешение в установленных принципах проектирования сложных систем. На основе опыта создания сложных систем, а также отечественных и зарубежных публикаций можно сформулировать пять принципов проектирования сложных систем:

1) реалистических целей;

2) проверенной базы;

3) поэтапного подхода;

4) активного потребителя;

5) централизованного руководства.

Суть принципа реалистических целей в том, что перед разработчиками ставятся такие цели, которые являются реально достижимыми в пределах заданного срока разработки системы. Основными путями реализации данного принципа являются выбор оптимальных сроков проектирования и последовательное уточнение оценок ожидаемых характеристик системы в процессе ее создания. При выборе оптимальных сроков проектирования необходимо учитывать, что одни и те же технические решения, реализованные в различные сроки, могут привести к противоположным результатам. Назначение малых сроков проектирования приведет к тому, что эти решения могут быть не реализованы, а увеличение сроков — к тому, что данные решения будут рассматриваться как морально устаревшие. Уточнение оценок следует из цикличности процесса проектирования, в соответствии с которым полученные ранее технические решения должны уточняться на всех этапах и уровнях разработки системы.

Принцип проверенной базы заключается в том, что при создании системы в качестве базовых должны использоваться хорошо отработанные и экспериментально проверенные технические решения. Для реализации данного принципа необходимо:

• максимально использовать унифицированные, серийно выпускаемые технические средства и хорошо отлаженное программное обеспечение;

• минимально использовать для создания системы вновь проектируемые технические средства и программы. В тех случаях, когда специфика создаваемой системы не позволяет обойтись без разработки новых средств, процесс их проектирования и ввода в эксплуатацию должен планироваться на ранних стадиях создания системы.

Принцип поэтапного подхода связан с выделением последовательной реализации этапов проектирования. Он учитывает финансовые и производственные ограничения, а также ограничения, связанные с численностью подготовленного оперативного и обслуживающего персонала. Поэтапный подход позволяет получить эффект от создаваемой системы в более короткие сроки, лучше организовать работу разработчиков системы и упрощает контроль проектирования.

В соответствии с принципом активного потребителя будущие пользователи больших систем должны активно участвовать в процессе создания системы на всех этапах разработки и внедрения.

Принцип централизованного руководства состоит в том, что планирование, координация и контроль за осуществлением всех мероприятий по созданию системы должны проводиться централизованно аппаратом главного конструктора системы.

ЗАКЛЮЧЕНИЕ

Основной формой организации хранения данных в информационных системах являются базы данных. Проблемы проектирования связаны с функциями БД в программно - технологической среде, поддерживающей информационные технологии.

Поскольку база данных является связующим звеном между пользовательскими приложениями и аппаратными средствами, ее проектирование можно разделить на два направления: проектирование структуры и пользовательских приложений и распределение данных по аппаратным средствам (в случае баз данных на сетях). Одной из распространенных технологий разработки БД является следующая: сбор данных о предметной области; анализ представлений пользователей; интеграция представлений пользователей; разработка сетевой модели; преобразование сетевой модели в первую нормальную форму реляционной модели; нормализация отношений путем преобразования их к третьей нормальной форме. В результате получается модель реляционной базы данных, которая представляет собой совокупность взаимосвязанных отношений. Построение сетевой модели связано скорее с потребностью разработчика графически представить взаимосвязь данных, полученных в результате интеграции представлений пользователей. Преобразование сетевой модели в реляционную дает первую нормальную форму последней. Вторая и третья нормальные формы позволяют избежать аномалий при обновлении данных и избавится от информационной избыточности в отношениях. Недостатком такого подхода является то, что в моделях, имеющих десятки и сотни атрибутов очень трудно имперически построить модель, все отношения которой заданы в третьей нормальной форме и связаны между собой таким образом, что составляют единое целое.

СПИСОК ЛИТЕРАТУРЫ

Дейт, К., Дж. Введение в системы баз данных, 7-е издание. : Пер. с англ. — М. : Издательский дом "Вильяме", 2017. — 1072 с.
Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - СПб.: КОРОНА принт, 20017. - 416 с.
Бекаревич Ю. Б., Пушкина Н. В. Microsoft® Access 2000. — СПб.: БХВ — Санкт-Петербург, 2016. — 480 с.