Разработка программного
обеспечения систем контроля и управления электроснабжением
Г.Н. Калянов,
зав. лаб., д.т.н., проф., kalyanov@ipu.ru,
В.В.
Петухов,
вед.
инж.,
ИПУ РАН, г. Москва
В докладе рассмотрены вопросы создания программного
обеспечения систем контроля и управления электроснабжением предприятия (СКУ ЭЧ).
Основу современных СКУ ЭЧ составляют программно-технические
комплексы, состоящие из технических и программных средств. СКУ ЭЧ
характеризуются сложностью (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними, наличие совокупности тесно
взаимодействующих подсистем, необходимость и т.п.). Основу СКУ ЭЧ, как правило,
составляет программное обеспечение. Для разработки программного обеспечения
предлагается использовать средства CASE-технологий, в частности рассмотрена
методология быстрой разработки приложений RAD (Rapid Application Development),
являющаяся одним из возможных подходов к разработке программного обеспечения в
рамках спиральной модели ЖЦ.
In
the report questions of creation of the software of control and management
systems for power supply of the enterprise (SKU ECh)
are considered. The basis of modern SKU ECh is made
by the software and hardware complexes consisting from technical and software.
SKU ECh are characterized by complexity (rather large
number of functions, processes, elements of data and difficult interrelations
between them, existence of set of closely interacting subsystems, need, etc.).
SKU ECh basis is made, as a rule, by the software.
For development of the software it is offered to use means of CASE
technologies, in particular the methodology of fast applications programming of
RAD (Rapid Application Development) which is one of possible approaches to
development of the software within the ZhTs spiral
model is considered.
Тенденции развития
современных систем управления электроснабжением предприятия, в т.ч. и релейная
защита оборудования (СКУ ЭЧ) приводят к постоянному возрастанию сложности этих
систем. Современные СКУ ЭЧ характеризуются, как
правило, следующими особенностями:
· сложность описания
(достаточно большое количество функций, процессов, элементов данных и сложные
взаимосвязи между ними), требующая тщательного моделирования и анализа данных и
процессов;
·
наличие
совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои
локальные задачи и цели функционирования (например, традиционных приложений,
связанных с обработкой транзакций и решением регламентных задач, и приложений
аналитической обработки (поддержки принятия решений), использующих нерегламентированные
запросы к данным большого объема);
· отсутствие прямых аналогов,
ограничивающее возможность использования каких-либо типовых проектных решений и
прикладных систем;
· необходимость интеграции
существующих и вновь разрабатываемых приложений;
· функционирование в
неоднородной среде на нескольких аппаратных платформах;
· разобщенность и
разнородность отдельных групп разработчиков по уровню квалификации и
сложившимся традициям использования тех или иных инструментальных средств;
· существенная временная
протяженность проекта, обусловленная, с одной стороны, ограниченными
возможностями коллектива разработчиков, и, с другой стороны, масштабами
организации-заказчика и различной степенью готовности отдельных ее
подразделений к внедрению СКУ ЭЧ.
При разработке СКУ ЭЧ она должна быть
прежде всего адекватно описана, должны быть построены её полные и
непротиворечивые функциональные и информационные модели. Накопленный к
настоящему времени опыт проектирования показывает, что это логически сложная,
трудоемкая и длительная по времени работа, требующая высокой квалификации
участвующих в ней специалистов. Однако до недавнего времени проектирование СКУ
ЭЧ выполнялось в основном на интуитивном уровне с применением неформализованных
методов, основанных на искусстве, практическом опыте, экспертных оценках и
дорогостоящих экспериментальных проверках качества функционирования. Кроме
того, в процессе создания и функционирования СКУ ЭЧ информационные потребности
пользователей могут изменяться или уточняться, что еще более усложняет разработку
и сопровождение таких систем.
Ранее при разработке
достаточно широко применялась структурная методология, предоставляющая в
распоряжение разработчиков строгие формализованные методы описания СКУ ЭЧ и
принимаемых технических решений]. Она основана на наглядной графической технике: для
описания различного рода моделей СКУ ЭЧ используются схемы и диаграммы.
Наглядность и строгость средств структурного анализа
позволяла разработчикам и будущим пользователям системы с самого начала
неформально участвовать в ее создании, обсуждать и закреплять понимание
основных технических решений. Однако, широкое
применение этой методологии и следование ее рекомендациям при разработке
конкретных СКУ ЭЧ встречалось достаточно редко, поскольку при
неавтоматизированной (ручной) разработке это практически невозможно.
Действительно, вручную очень трудно разработать и графически представить
строгие формальные спецификации системы, проверить их на полноту и
непротиворечивость, и тем более изменить. Если все же удается создать строгую
систему проектных документов, то ее переработка при появлении серьезных
изменений практически неосуществима. Ручная разработка обычно порождала
следующие проблемы:
§ неадекватная спецификация
требований;
§ неспособность обнаруживать
ошибки в проектных решениях;
§ низкое качество
документации, снижающее эксплуатационные качества;
§ затяжной цикл и
неудовлетворительные результаты тестирования.
С другой стороны, разработчики СКУ ЭЧ исторически
всегда стояли последними в ряду тех, кто использовал компьютерные технологии
для повышения качества, надежности и производительности в своей собственной
работе (феномен "сапожника без сапог").
Аналогичные проблемы возникают и при разработке
других информационных систем [1]. Перечисленные факторы способствовали появлению
программно-технологических средств специального класса
- CASE-средств, реализующих CASE-технологию создания и сопровождения систем, в
т.ч. и СКУ ЭЧ. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма
широком смысле. Первоначальное значение термина CASE, ограниченное вопросами
автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело
новый смысл, охватывающий процесс разработки сложных комплексов в целом. Теперь
под термином CASE-средства понимаются программные средства, поддерживающие
процессы создания и сопровождения сложных систем, включая анализ и формулировку
требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование,
документирование, обеспечение качества, конфигурационное управление и
управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду
разработки комплексов вооружения и военной техники [2, 3].
CASE-технология представляет собой методологию
проектирования сложных систем, а также набор инструментальных средств,
позволяющих в наглядной форме моделировать предметную область, анализировать
эту модель на всех этапах разработки и сопровождения систем и разрабатывать
приложения в соответствии с информационными потребностями пользователей.
Большинство существующих CASE-средств основано на методологиях структурного (в
основном) или объектно-ориентированного анализа и проектирования, использующих
спецификации в виде диаграмм или текстов для описания внешних требований,
связей между моделями системы, динамики поведения системы и архитектуры
программных средств.
Одним из базовых понятий методологии проектирования
системы является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с
момента принятия решения о необходимости его создания и заканчивается в момент
его полного изъятия из эксплуатации. Он определяет структуру ЖЦ, содержащую
процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО состоит из
следующих процессов:
·
основные
процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация,
сопровождение);
· вспомогательные
процессы, обеспечивающие выполнение основных процессов (документирование,
управление конфигурацией, обеспечение качества, верификация, аттестация,
оценка, аудит, решение проблем);
· организационные процессы
(управление проектами, создание инфраструктуры проекта, определение, оценка и
улучшение самого ЖЦ, обучение).
Разработка включает в себя
все работы по созданию ПО и его компонент в соответствии с заданными
требованиями, включая оформление проектной и эксплуатационной документации,
подготовку материалов, необходимых для проверки работоспособности и
соответствующего качества программных продуктов, материалов, необходимых для
организации обучения персонала и т.д.
Управление проектом связано с вопросами
планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ.
Техническое и организационное обеспечение проекта включает выбор методов и
инструментальных средств для реализации проекта,
определение методов описания промежуточных состояний разработки, разработку
методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества
проекта связано с проблемами верификации, проверки и тестирования ПО.
Технология проектирования определяется как
совокупность трех составляющих:
o пошаговой процедуры,
определяющей последовательность технологических операций проектирования;
o критериев и правил,
используемых для оценки результатов выполнения технологических операций;
o нотаций (графических и
текстовых средств), используемых для описания проектируемой системы.
Опыт разработки ПО СКУ ЭЧ показал, что должны быть
выполнены следующие общие требования:
§ технология должна
поддерживать полный ЖЦ ПО;
§ технология должна
обеспечивать гарантированное достижение целей разработки с заданным качеством и
в установленное время;
§ технология должна
обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е.
возможность декомпозиции проекта на составные части, разрабатываемые группами
исполнителей ограниченной численности с последующей интеграцией составных
частей).
§ технология должна
обеспечивать возможность ведения работ по проектированию отдельных подсистем
небольшими группами;
§ технология должна
обеспечивать минимальное время получения работоспособной системы;
§ технология должна
предусматривать возможность управления конфигурацией проекта, ведения версий
проекта и его составляющих, возможность автоматического выпуска проектной
документации и синхронизацию ее версий с версиями проекта;
§ технология должна
обеспечивать независимость выполняемых проектных решений от средств реализации
ИС (систем управления базами данных (СУБД), операционных систем, языков и
систем программирования);
§
технология
должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих
автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Для разработке
ПО предлагается применение получившая в последнее время широкое распространение
методология быстрой разработки приложений RAD (Rapid Application Development). Под
этим термином обычно понимается процесс разработки ПО,
содержащий 3 элемента:
ü небольшую команду
программистов (от 2 до 10 человек);
ü короткий, но тщательно
проработанный производственный график (от 2 до 6 мес.);
ü повторяющийся цикл, при
котором разработчики, по мере того, как приложение начинает обретать форму,
запрашивают и реализуют в продукте требования, полученные через взаимодействие
с заказчиком.
Следует, однако, отметить, что методология RAD, как
и любая другая, не может претендовать на универсальность, она хороша в первую
очередь для относительно небольших проектов, разрабатываемых для конкретного
заказчика. Если же разрабатывается типовая система, которая
не является законченным продуктом, а представляет собой комплекс типовых
компонент, централизованно сопровождаемых, адаптируемых к программно-техническим
платформам, СУБД, средствам телекоммуникации, организационно-экономическим
особенностям объектов внедрения и интегрируемых с существующими разработками,
на первый план выступают такие показатели проекта, как управляемость и
качество, которые могут войти в противоречие с простотой и скоростью
разработки. Для таких проектов необходимы высокий уровень планирования и
жесткая дисциплина проектирования, строгое следование заранее разработанным
протоколам и интерфейсам, что снижает скорость разработки.
В качестве итога перечислим
основные принципы методологии RAD:
v разработка приложений
итерациями;
v необязательность полного
завершения работ на каждом из этапов жизненного цикла;
v обязательное вовлечение
пользователей в процесс разработки ИС;
v необходимое применение
CASE-средств, обеспечивающих целостность проекта;
v применение средств
управления конфигурацией, облегчающих внесение изменений в проект и
сопровождение готовой системы;
v необходимое использование
генераторов кода;
v использование прототипирования, позволяющее полнее выяснить и
удовлетворить потребности конечного пользователя;
v тестирование и развитие
проекта, осуществляемые одновременно с разработкой;
v ведение разработки
немногочисленной хорошо управляемой командой профессионалов;
v грамотное руководство
разработкой системы, четкое планирование и контроль выполнения работ.
Литература
1. Корнухин М.Г., Любинецкий Я.Г., Майданчик Е.И.
Жизненный цикл и эффективность машин. М.: Машиностроение,
2.
Васильев Р.Б., Калянов Г.Н., Левочкина Г.А.. Управление
развитием информационных систем. М.: Горячая линия: Телеком,
3.
Васильев Р.Б., Калянов Г.Н., Левочкина Г.А.. Стратегическое управление информационными
системами. М.: Бином,