Разработка неформальных систем и систем, не имеющих аналогов

Разработка неформальных систем и систем не имеющих аналогов

1. Неформальные этапы разработки систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким же образом определяют возможные отклонения от нормального режима для каждого элемента системы и ее выходов.

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

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

2. Разработка систем, не имеющих аналогов

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

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

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

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

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

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

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

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

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

3. Распределение функций между специалистами при разработке неформальных систем

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

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

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

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

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

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

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

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