Обоснование целесообразности автоматизации решения задачи

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

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

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

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

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

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

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

· формирование исследовательского коллектива;

· планирование предусматриваемых работ по обоснованию це­лесообразности автоматизации;

· обследование существующей системы;

· выработка новых проектных решений;

· комплектование документации этапа обоснования целесооб­разности автоматизации;

· принятие решений о выборе варианта проекта и о проведении работ по его дальнейшей конкретизации на этапе функционального анализа задачи.

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

ОГЛАВЛЕНИЕ ДОКУМЕНТАЦИИ ЭТАПА ОБОСНОВАНИЯ

ЦЕЛЕСООБРАЗНОСТИ АВТОМАТИЗАЦИИ РЕШЕНИЯ ЗАДАЧИ

1.1. Постановка задачи

1.2. Список исполнителей работ на этапе обоснования целесообраз­ности автоматизации

1.3. Намечавшийся и фактический план-график работ на этапе обоснования целесообразности автоматизации

1.4. Обследование существующей системы

1.4.1. Виды деятельности организации или ее подразделения

1.4.2. Должностная структура организации

1.4.3. Документы и массивы

1.4.4. Используемые средства обработки информации

1.4.5. Потоки данных

1.4.6. Затраты на функционирование системы

1.5. Критический анализ существующей системы

1.5.1. Обобщенная характеристика выявленных недостатков

1.5.2. Причины недостатков

1.5.3. Диагноз

1.6. Цели. Новые проектные решения

1.6.1. Основные цели решения задачи

1.6.2. Возможные проектные решения

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

1.7. Решения, принятые при завершении этапа обоснования целе­сообразности автоматизации. Краткое описание выбранного проектного решения

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

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

На этапе функционального анализа должны быть изучены:

· выходные данные;

· массивы данных;

· ввод данных;

· диалоговые процедуры (если задача допускает применение диалогового режима);

· процедуры контроля вводимых данных;

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

· проблемы защиты;

· потоки данных.

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

1. Подход с точки зрения выходных данных (потребностей пользователей). В данном случае требуется начинать разработку с изучения выходных данных и в дальнейшем следовать порядку, приведенному выше.

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

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

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

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

6. “Глобальный” подход. Он применяется лишь в некоторых случаях и состоит в почти одновременном проведении исследова­ний по основным перечисленным выше пунктам. Такой подход применяется при разработке некоторых территориально рассредо­точенных задач: изучение хранимых данных и процедур обработки должно проводиться одновременно с выбором технических средств (в т. ч. средств связи). Данный подход применяется также для разработки “небольших” задач и выполнения многочисленных ра­бот по сопровождению задач. Решаемые при этом проблемы не яв­ляются слишком сложными; разработчик ведет исследования без заранее намеченной методики, переходя от разработки диалоговой процедуры к проектированию массивов, затем к разработке вы­ходного документа и снова возвращаясь к проектированию диало­говой процедуры и т. д.

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

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

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

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

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

· “Размер” задачи. Небольшие задачи и некоторые крупные задачи часто разрабатываются (несмотря на все разнообразие ис­пользуемых ими средств) исходя из принципов глобального под­хода.

· Мнения, взгляды, рабочие приемы и т. п. разработчиков. Раз­работчики обладают своим личным опытом и навыками; поэтому ясно, что эти факторы также влияют на выбор подхода к разра­ботке задачи.

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

· Формирование коллектива разработчиков.

· Уточнение целей решения задачи.

· Планирование работ, предусматриваемых на этапе функцио­нального анализа.

· Составление “правил управления”, которым должно следо­вать решение задачи. Эти правила должны быть сформулированы вплоть до мельчайших подробностей.

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

· Разработка массивов. Выходные данные вырабатываются с помощью программ, которые будут пользоваться данными, имею­щимися в массивах. Следовательно, после изучения выходных дан­ных уместно приступить к разработке массивов.

· Изучение ввода данных. Необходимые данные должны быть введены в массивы. Следовательно, после разработки массивов логично приступить к изучению ввода данных.

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

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

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

· Решение проблем защиты. На данной стадии могут быть рас­смотрены проблемы защиты, поскольку принятые в связи с этим решения окажут прямое влияние на определение потоков данных.

· Определение потоков данных разрабатываемой задачи (с ука­занием рабочих мест, операций, сроков и т. д.).

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

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

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

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

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

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

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

· подготовка помещений (одиннадцатый главный этап);

· подготовка персонала (девятый главный этап).

3.2. Разработка постановки задачи и оформление документации

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

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

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

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

Часть 3. Алгоритм решения задачи. Здесь описываются в математическом виде все взаимосвязи между параметрами, используемыми в задаче, формальная постановка задачи и приводится в блок-схеме алгоритма ее решения, оформленная в соответствии с Гостом. Блок-схема достаточно сложного алгоритма обязательно снабжается комментарием и ссылками на исходные данные, приводятся варианты интерпретации полученных результатов.

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

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

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

Дата добавления: 2015-07-15