Здавалка
Главная | Обратная связь

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



 

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

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

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

* Иногда это называют эскизным или аванпроектом.

 

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

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

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

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

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

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

 







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.