5

Федеральное агентство по образованию

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

Казанский государственный финансово-экономический институт

Кафедра математики и экономической информатики

Реферат

по дисциплине: Информационные технологии

на тему: Компьютерное моделирование экономики

Выполнила: Давленшина И.А.

Казань 2010

Содержание

Введение

1. Общая характеристика технологии создания прикладных программных средств и экономических моделей

2. Алгоритмизация, как третий этап технологического процесса подготовки решения экономических задач на ЭВМ

3. Компьютерное моделирование и технология системного проектирования программных средств

Заключение

Список использованных источников

Приложения

Введение

Нужно ли знать математику и ее приложения в области анализа социально-экономических процессов экономисту, социологу и другим представителям гуманитарных профессий? А если нужно, то в какой мере? Вопросы далеко не праздные: на практике при решении многих конкретных управленческих проблем часто берут верх неформализуемые факторы, а применение математики сводится к использованию лишь четырех действий арифметики. Сейчас в это трудно поверить, но всего 70 лет назад подобные же вопросы остро обсуждались при разработке учебных программ технических вузов. Выдающийся русский математик академик А.Н. Крылов, обосновывая необходимость глубокого математического образования инженеров, высказал в своем докладе “Прикладная математика” на состоявшейся летом 1931 г. чрезвычайной сессии Академии наук СССР следующий довод: «…за тысячелетие от 500 до 1500 года мы можем проследить значительное развитие техники, хотя... даже правило простого сложения сил, называемое правилом параллелограмма сил, известно не было».

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

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

1. Общая характеристика технологии создания прикладных программных средств и экономических моделей

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

Технология разработки программ решения задачи определяется главным образом двумя факторами:

* осуществляется ли разработка программы решения задачи как составного элемента единой системы автоматизированной обработки информации либо как относительно независимой, локальной компоненты общего программного комплекса, обеспечивающего решение на ЭВМ задач управления;

* какие программно-инструментальные средства используются для разработки и реализации задач на ЭВМ.

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

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

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

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

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

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

Рис. 1.1. Принципиальная схема разработки программных средств решения экономических задач на ЭВМ

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

* форма представления отдельных реквизитов (цифровая, символьная и т.д.);

* количество знаков (разрядов), выделяемых для записи реквизитов исходя из их максимальной значности;

* вид реквизита по его роли в процессе решения задачи (исходный, расчетный, нормативный, справочный и т.п.);

* источник (документ, задача и т.п.) возникновения реквизита.

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

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

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

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

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

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

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

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

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

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

* аналитические (вычислительные);

* матричные (балансовые);

* графические (частным видом которых являются сетевые).

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

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

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

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

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

* ориентирован на минимальный объем исходной информации;

* обеспечивает наиболее быстрое получение искомых результатов.

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

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

2. Алгоритмизация, как третий этап технологического процесса подготовки решения экономических задач на ЭВМ

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

Наряду с трактовкой алгоритма в соответствии с принятым стандартом (по ГОСТ 19.004-80 "алгоритм - это точное предписание, определяющее вычислительный процесс, ведущий от варьируемых начальных данных к искомому результату ") термин "алгоритм" может быть представлен более развернутым определением как конечный набор правил, однозначно раскрывающих содержание и последовательность выполнения операций для систематического решения определенного класса задач за конечное число.

Любой алгоритм обладает следующими свойствами: детерминированностью, массовостью, результативностью и дискретностью.

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

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

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

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

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

Процесс алгоритмизации решения задачи обычно реализуется по следующей схеме:

* выделение автономных этапов процесса решения задачи (как правило, с одним входом и выходом);

* формализованное описание содержания работ, выполняемых на каждом выделенном этапе;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* программа работает, но не выдает всех запланированных результатов и не выходит на останов (происходит ее "зацикливание");

* программа выдает результаты и завершает свою работу, но они полностью или частично не совпадают с контрольными.

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

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

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

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

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

В этом плане примечателен факт недавнего обвинения компании Microsoft в «шпионаже» за теми, кто устанавливал их программные продукты на своих компьютерах. Так, было выявлено, что программы, входящие в Office 97, создавали специальные идентификационные номера, помечавшие документы в форматах Word и Excel.

В результате компания Microsoft была вынуждена создать и распространить по сети Интернет программу-заплатку, препятствующую появлению таких идентификационных номеров, а также программу, стирающую идентификационные номера в Windows 98.

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

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

В настоящее время лидирующее положение на мировом рынке автоматизированных средств контроля качества ПО занимают три компании: Rational Software (27%), Intersolv (11%), Mercury Interactive (11%), тогда как на долю компании Microsoft приходится только 5% мирового рынка соответствующей продукции.

Оценивая возрастание роли независимого тестирования программных средств информационных систем, в нашей стране также стали появляться специализированные центры тестирования программных продуктов. Если до недавнего времени такие работы осуществлялись только в Лаборатории оптимизации серверных приложений (в московском представительстве Intel) и только для платформ этой корпорации, то в 1999 г. компания «АйТи» открыла свой Центр тестирования, который на коммерческой основе оказывает услуги любым компаниям в проведении полномасштабного тестирования информационных систем (как готовящихся к внедрению, так и уже находящихся в эксплуатации).

В качестве испытательных стендов при этом используются серверы и рабочие станции Hewlett-Packard, Sun, Compag, работающие под управлением Unix и Windows NT. На их платформах установлены СУБД Oracle, Microsoft SQL Server, Informix и Sybase. При этом клиентские места могут быть реализованы и на компьютерах отечественной сборки. В качестве основных инструментов тестирования работоспособности и производительности в Центре применяются программные продукты мирового лидера в этой сфере софтверного бизнеса - компании Rational Software Corp. Используемые передовые технологии обеспечивают автоматизированное тестирование приложений архитектуры клиент-сервер как в режиме стабильной, так и стрессовой нагрузки системы (эмулируя произвольное число ее пользователей).

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

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

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

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

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

По завершении работы комиссии оформляется акт приема-передачи.

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

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

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

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

3. Компьютерное моделирование и технология системного проектирования программных средств

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

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

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

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

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

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

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

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

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

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

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

Другой чертой системной разработки проектов прикладных программ является их ориентация на использование интегрированных и распределенных баз данных. В связи с этим в качестве инструментальных средств разработки компонентов ПО наряду с языками программирования стали применяться языковые средства СУБД. В этих условиях технологическая схема процесса разработки программ решения задач экономического управления претерпела существенное изменение (рис. 2.1).

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

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

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

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

Заключение

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

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

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

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

Список использованных источников

1. Крылов А.Н. Прикладная математика и ее значение для техники. М.; Л., 2001. С.6.

2. Блауг М. Экономическая мысль в ретроспективе. / Пер. с англ. М., 2004. С.277.

3. Капица П.Л. Эксперимент, теория, практика: Статьи и выступления. М., 2006. С.417.

4. Маршалл А. Принципы экономической науки / Пер. с англ. М., 2003. Т.1. С.49--50.

5. Самарский А.А., Михайлов А.П. Математическое моделирование. М., 1997.

6. Петров А.А., Поспелов И.Г., Шананин А.А. Опыт математического моделирования экономики. М., 2006.

7. Тихомиров Н.П., Райцин В.Я., Гаврилец Ю.Н., Спиридонов Ю.Д. Моделирование социальных процессов. М., 1993.

8. Лебедев В.В. Математическое моделирование социально-экономических процессов. М., 1997.

9. Кейнс Дж.М. Избранные произведения / Пер. с англ. М., 1993.

10. Цисарь И.Ф., Нейман В.Г. "Компьютерное моделирование экономики". М.: 2007.

Приложение 1

Схема алгоритма решения задачи определения стажа работы