Учебное пособие Пермь ипц «Прокростъ» 2017 удк

5) Поиск решения, разработка алгоритма решения и ис-
следование его свойств, реализация алгоритма в виде про-
граммы для ЭВМ 
В случаях, когда решение можно найти аналитическим 
методом, потребности в разработке специального программ-
ного обеспечения, как правило, не возникает. Численный, 
или приближенный, метод реализуется всегда в виде вычис-
лительного алгоритма. Требования, предъявляемые к алго-
ритму, указываются в следующем определении. 
Алгоритм – это упорядоченный набор недвусмыслен-
ных и выполнимых этапов, определяющий некоторый конеч-
ный процесс. 
Это определение содержит несколько важных требо-
ваний: 

---

62 
1) требование упорядоченности указывает, что этапы 
алгоритма должны выполняться в некотором определенном 
порядке, но необязательно один за другим; 
2) требование выполнимости этапа означает принципи-
альную возможность его осуществления; 
3) требование недвусмысленности означает, что во вре-
мя выполнения алгоритма при любом состоянии процесса 
информации должно быть достаточно, чтобы полностью 
определить действия, которые требуется осуществить на 
каждом этапе; 
4) требование конечности процесса означает, что алго-
ритм должен быть результативен, т.е. выполнение алгоритма 
должно приводить к его завершению. 
Кроме того, к методам и алгоритмам, как и к математи-
ческим моделям, предъявляют требования точности и эконо-
мичности.
Точность характеризуется степенью совпадения точно-
го решения уравнений заданной модели и приближенного 
решения, полученного с помощью оцениваемого метода, а 
экономичность – затратами вычислительных ресурсов на ре-
ализацию метода (алгоритма). 
Оценки точности и экономичности бывают теоретиче-
скими и экспериментальными. Теоретические оценки обычно 
характеризуют эффективность применения исследуемого ме-
тода не к одной конкретной модели, а к некоторому классу 
моделей и являются предметом изучения в вычислительной 
математике. Экспериментальные оценки основаны на опре-
делении показателей эффективности решения с помощью 
набора специально составляемых тестовых задач. 
Процесс создания программного обеспечения обычно 
идет в следующей последовательности: 

---

63 
- составление технического задания на разработку про-
граммного обеспечения; 
- проектирование структуры программного комплекса; 
- кодирование алгоритма; 
- тестирование и отладка; 
- сопровождение и эксплуатация. 
Техническое задание на разработку программного обес-
печения оформляют в виде спецификации. Примерная форма 
спецификации включает следующие семь разделов: 
Название задачи – дается краткое определение решае-
мой задачи, название программного комплекса, указывается 
система программирования для его реализации и требования 
к аппаратному обеспечению (компьютеру, внешним устрой-
ствам и т.д.). 
Описание – подробно излагается математическая поста-
новка задачи, описываются применяемая математическая мо-
дель для задач вычислительного характера, метод обработки 
входных данных для задач не вычислительного (логического) 
характера и т.д. 
Управление режимами работы программы – формиру-
ются основные требования к способу взаимодействия поль-
зователя 
с 
программой 
(интерфейс 
«пользователь–
компьютер»). 
 Входные данные – описываются входные данные, указыва-
ются пределы, в которых они могут изменяться, значения, 
которые они не могут принимать, и т.д. 
Выходные данные – описываются выходные данные, 
указывается, в каком виде они должны быть представлены (в 
числовом, графическом или текстовом), приводятся сведения 
о точности и объеме выходных данных, способах их сохра-
нения и т.д. 

---

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

---

65 
проектирования (САПР), где они в значительной степени со-
кращают время на получение данных и оценку результатов 
моделирования. 
6) Проверка адекватности модели 
Проверка адекватности модели преследует две цели: 
- убедиться в справедливости совокупности гипотез, 
сформулированных на этапах концептуальной и математиче-
ской постановок; 
- установить, что точность полученных результатов со-
ответствует точности, оговоренной в техническом задании. 
Проверка разработанной математической модели вы-
полняется путем сравнения с имеющимися эксперименталь-
ными данными о реальном объекте или с результатами дру-
гих, созданных ранее и хорошо себя зарекомендовавших мо-
делей. Как правило, различают качественное и количествен-
ное совпадение результатов сравнения. При качественном 
сравнении требуется лишь совпадение вида функции распре-
деления выходных параметров (убывающая или возрастаю-
щая, с одним экстремумом или с несколькими). При количе-
ственном сравнении оценивают точность вычисления пара-
метров. В моделях, предназначенных для выполнения оце-
ночных и прикидочных расчетов, удовлетворительной счита-
ется точность 10–15 %. В моделях, используемых в управля-
ющих и контролирующих системах, требуемая точность мо-
жет быть менее 2 %. 
Неадекватность результатов моделирования возможна, 
по крайней мере, по трем причинам: а) значения задаваемых 
входных параметров модели не соответствуют допустимой 
области этих параметров, определяемой принятой системой 
гипотез; б) принятая система гипотез верна, но константы и 
параметры в использованных определяющих соотношениях 

---

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

---

67