Групповое занятие. Методологические основы автоматизации процессов управления вмф.

Вопросы:

1. Взгляды зарубежных специалистов.

2. Отечественная методология проектирования АСУ военного назначения.

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

Литература:

1. В.Ф. Шпак Основы автоматизации управления. Ч.1, стр. 94-103. Петродворец, ВМИРЭ, 1998 г.

1. Взгляды зарубежных специалистов.

На предыдущем занятии мы рассмотрели концепцию автоматизации процессов управления ВМФ и отметили ее тесную взаимосвязь с методологией автоматизации. На данном занятии мы рассмотрим методологию автоматизации процессов управления ВМФ.

Начнем с анализа методологии, принятой в ряде зарубежных государств. Большинство зарубежных специалистов в области автоматизации полагают, что с переходом на новые информационные технологии в военном деле принципиальным образом меняется характер создания автоматизированных систем. Автоматизированная система (или ее часть) рассматривается как вспомогательное средство для обеспечения принятия решений в управлении и именуется “система обеспечения принятия решений” (decision support system - DSS). Разработка DSS и ее внедрение становятся единым органическим процессом, в котором главную роль играет потенциальный пользователь, формирующий общие идеи проекта и впоследствии развивающий их.

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

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

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

краткое изложение требований ко всей системе и оперативных концепций по её элементам;

общее описание требуемых оперативно-тактических и функциональных характеристик при отсутствии конкретности и детализации в их окончательных значениях;

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

наличие плана эволюционного достижения требуемых конечных характеристик;

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

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

Важными отличительными признаками эволюционного приобретения считаются:

раздельное финансирование каждого этапа создания и внедрения системы;

тщательное планирование разработки и внедрения;

использование принципа “немного поработать, немного испытать и немного внедрить”.

В рамках концепции автоматизации зарубежные специалисты особое место уделяют программному обеспечению (ПО) АСУ военного назначения.

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

- широкое внедрение в практику разработки ПО метода макетирования, то есть ускоренного создания опытных образцов системы или прототипов (rapid prototiping);

- эволюционный подход к разработке и приобретению ПО систем управления;

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

- более активное участие в разработке системы её будущих пользователей, создание и апробирование нескольких альтернативных вариантов системы.

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

- метод “демонстрационных прототипов” (rapid thorowanag prototypes);

- метод “последующей постепенной модернизации” (incremental development);

- метод “эволюционирующих прототипов” (evolutionary prototypes).

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

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

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

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

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

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

Лучшее из описанных подходов к автоматизации процессов управления берут на вооружение и отечественные специалисты по автоматизации управления ВМФ.