otvety_118

21

Стадия 3. Техническое задание.

·разработка и утверждение технического задания на создание ИС. Стадия 4. Эскизный проект.

·разработка предварительных проектных решений по системе и ее частям;

·разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

·разработка проектных решений по системе и ее частям;

·разработка документации на ИС и ее части;

·разработка и оформление документации на поставку комплектующих изделий;

·разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

·разработка рабочей документации на ИС и ее части;

·разработка и адаптация программ. Стадия 7. Ввод в действие.

·подготовка объекта автоматизации;

·подготовка персонала;

·комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами);

·проведение опытной эксплуатации;

·проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

·выполнение работ в соответствии с гарантийными обязательствами;

·послегарантийное обслуживание.

10. Информационное обеспечение ИС

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

Информационное обеспечение ИС является средством для решения следующих задач:

однозначного и экономичного представления информации в системе (на основе кодирования объектов);

организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификации объектов);

организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных);

обеспечения эффективного использования информации в контуре управления деятельностью объекта автоматизации (на основе унифицированной системы документации).

^Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы) и внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структурыинформационной базы: входных, выходных файлов, базы данных).

Кинформационному обеспечению предъявляются следующие общие требования:

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

22

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

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

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

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

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

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

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

^Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации иинформационной базы [21].

11.Жизненный цикл программного обеспечения. Основные процессы ЖЦ

Жизненный цикл программного обеспечения (ПО) — период времени, который

начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

Основные:

1.Приобретение (действия и задачи заказчика, приобретающего ПО)

2.Поставка (действия и задачи поставщика, который снабжает заказчика

программным продуктом или услугой)

3. Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

4. Эксплуатация (действия и задачи оператора — организации, эксплуатирующей

систему)

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

12. Жизненный цикл программного обеспечения. Вспомогательные процессы ЖЦ.

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

Вспомогательные

6.Документирование (формализованное описание информации, созданной в

течение ЖЦ ПО)

7.Управление конфигурацией (применение административных и

технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

8.Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее

ЖЦ соответствуют заданным требованиям и утвержденным планам)

9.Верификация (определение того, что программные продукты, являющиеся

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

23

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

11. Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

12. Аудит (определение соответствия требованиям, планам и условиям

договора)

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

13. Жизненный цикл программного обеспечения. Организационные процессы ЖЦ

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

Организационные

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

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

16.Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

17.Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

14.Методология быстрой разработки приложений

Быстрая разработка приложений - RapidApplicationDevelopment (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки

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

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

Наиболее существенными из них являются:

высокая скорость разработки;

низкая стоимость;

высокое качество.

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

Приведем краткое описание фаз модели RAD и обсудим участие пользователя на всех этапах этого процесса.

24

1.Этап планирования требований - совместное планирование требований (Jointrequirementsplanning, JRP). Сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований, который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач.

2.Пользовательское описание — совместное проектирование приложения (Jointapplicationdesign, JAD). Используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации.

3.Фаза конструирования ("до полного завершения") — объединяет в себе детализированное проектирование, построение (кодирование и тестирование). А также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависят от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств.

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

На стадии анализа и планирования требований пользователи осуществляют следующие действия:

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

• выделение наиболее приоритетных функций, требующих проработки в первую очередь;

• описание информационных потребностей.

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

сразработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:

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

• устанавливаются требования разграничения доступа к данным;

• устанавливаются требования разграничения доступа к данным;

• определяется состав необходимой документации.

На стадии реализации выполняется быстрая разработка приложения:

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

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

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

На стадии внедрения производится обучение пользователей и организационные изменения.

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

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

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

При использовании модели RAD относительно проекта, для которого она в достаточной степени приемлема, появляются следующие преимущества:

25

-время цикла разработки для всего проекта можно сократить благодаря использованию мощных инструментальных средств;

-требуется меньшее количество специалистов, поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области;

-существует возможность произвести быстрый изначальный просмотр продукта и т.д.;

-модель обеспечивает эффективное использование имеющихся в наличии средств и структур;

-привлечение заказчика на постоянной основе сводит до минимума риск того, что он не будет удовлетворен разработанным продуктом;

-в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

Если эта модель применяется для проекта, для которого она не подходит в полной мере, могут сказываться следующие недостатки:

-недостаточное взаимодействие с пользователями на протяжении всего жизненного цикла негативно отражается на конечном продукте;

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

Отметим также, что RAD применяется:

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

-когда затраты и соблюдение графика не являются самым важным вопросом (например, при разработке внутренних инструментальных средств);

-при невысокой степени технических рисков;

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

15. Структурный подход к проектированию ПО. Базовые принципы.

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

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

принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Основными из этих принципов являются следующие:

принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности

элементов;

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

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

26

SADT –методология структурн. проектирования и анализа;

DFD (DataFlowDiagrams) диаграммы потоков данных (подраздел 2.3);

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

16.Методологии моделирования предметной области

Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели.

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

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

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

К моделям проблемных областей предъявляются следующие требования: формализованность, обеспечивающая однозначное описание структуры проблемной

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

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

реализуемость, подразумевающая наличие средств физической реализации модели проблемной области в ЭИС;

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

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования .проблемной области. Структурный аспект функционирования ЭИС предполагает построение:

объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

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

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

27

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

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

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

Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой ЭИС.

Оценочные аспекты моделирования проблемной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

время решения задач; стоимостные затраты на обработку данных; надежность процессов;

косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

Для расчета показателей эффективности ЭИС реализующей модель проблемной области, как правило, используются статические методы функционально-стоимостного анализа (ЛВС) и динамические методы имитационного моделирования.

В основе различных методологий моделирования проблемных областей ЭИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трехуровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на

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

17.Методология функционального моделирования SADT.

Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг,

28

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

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6

блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

Состав функциональной модели

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

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

Рис 1. Функциональный блок и интерфейсные дуги На рисунке 2, где приведены четыре диаграммы и их взаимосвязи, показана структура

SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

Иерархия диаграмм

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

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

29

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

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

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

Рис.2. Структура SADT-модели. Декомпозиция диаграмм

На рисунках 3 - 5 представлены различные варианты выполнения функций и соединения дуг с блоками.

30

Рис. 3. Одновременное выполнение

Рис. 4. Соответствие должно быть полным и непротиворечивым Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один

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

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

Рис. 5. Пример обратной связи Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с

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