Проектирование технологических процессов обработки экономической информации Исполнитель

{spoiler=Далее}

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

Задача – основная единица обработки информации. Содержание работ по проектированию процессов обработки экономической информации определяется особенностями экономической задачи, как основной единицы обработки данных в локальных АЭИС.

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

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

Существуют следующие взаимосвязанные методы проектирования [18]:

• метод структурного проектирования;
• метод модульного проектирования;
• метод проектирования «сверху-вниз»;
• метод структурного программирования;
• метод HIPO – документирования.

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

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

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

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

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

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

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

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

Другим ограничением, применяемом  в этом методе, являются ограничения на типы используемых операторов и структур. Рекомендуется использование линейных структуры (последовательность взаимосвязанных операторов), иерархической структуры с оператором if и циклических (кольцевых) структур с использованием оператора dowhile. Не рекомендуется применение оператораgoto.

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

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

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

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

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

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

{/spoilers}