WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ И РЕАЛИЗАЦИИ БЮДЖЕТНЫХ РАСПРЕДЕЛЁННЫХ СИСТЕМ МОНИТОРИНГА И УПРАВЛЕНИЯ ОБОРУДОВАНИЕМ ЭЛЕКТРОСВЯЗИ М.Л. Зубов, старший преподаватель

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

Введение факторами. Примером может служить учёт и конт роль энергоресурсов. Очевидно, что если экономи втоматизированные системы управления и ческий эффект от внедрения равен нулю, система мониторинга (СМУ) уже нашли своё место не будет создана. Создание систем этого класса со Аво всех областях деятельности человека. пряжено с определёнными трудностями. В частно Полезность СМУ, а так же и то, что их роль с каж сти, необходимо экономическое обоснование со дым годом будет расти, уже не вызывает сомнений. здания системы, которое в свою очередь строится Не смотря на то, что СМУ разрабатываются и ис на основе прогнозов затрат как на создание систе пользуются в течение продолжительного времени, мы, так и на эксплуатацию. Прогнозы должны и еще имеется много вопросов, требующих деталь строиться на основе анализа моделей, описываю ного исследования. При этом вопросы экономиче щих этапы жизненного цикла (ЖЦ) систем. К со ского характера являются наиболее актуальными. К жалению, не существует полного набора моделей ним относятся как оценка экономической целесоо (для всех этапов ЖЦ) для выполнения анализа и бразности внедрения СМУ, так и оценки затрат на получения точных прогнозов. На данный момент всех этапах жизненного цикла системы. единственной моделью, широко используемой для По мере разработки, внедрения и эксплуатации оценки стоимости, является статистическая модель СМУ в различных предметных областях были полу COCOMO (Constructive Cost Model), предложенная чены типовые подходы к проектированию СМУ. Барри Боэмом в 1981 г. [1]. К сожалению, для выво Примером достаточно хорошо проработанных да формул использовались данные о выполнении предметных областей могут служить системы конт реальных программных проектов, ориентирован роля и управления технологическими процессами, ных на конечного пользователя. Доступных данных охранные системы, системы управления безопас о результатах создания сложных распределенных ностью полетов и др. Объединяет выше перечис систем, к которым относятся СМУ, на момент со ленные предметные области то, что СМУ являются здания просто не было. Данные о проектах, имею неотъемлемой частью бизнес процессов, и исполь щих как программную, так и аппаратную компо зование СМУ мотивируется не только экономичес ненты, также не учитывались.

кими факторами. Трудности, возникающие в проведении иссле Другой класс СМУ – это системы, создание кото дований, и проблемы построения моделей, по рых мотивировано исключительно экономическими зволяющих получать оценки затрат с приемлемой 28 БИЗНЕС-ИНФОРМАТИКА №1(07)–2009 г.

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ точностью, вынуждают искать пути создания систе и предварительную обработку данных. Доступ к дан мы с предсказуемым уровнем затрат. Ниже описы ным обеспечивается через локальные интерфейсы ЦУ.

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

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

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

номического эффекта БС находятся в пограничном на момент создания предполагается единичное слое между понятиями «выгодно» и «не выгодно». производство, с перспективой выхода на се Задачи, решаемые БC, имеют вспомогательный рийное производство. Как правило, изначаль характер и не ориентированы на массового потре но система создается для конкретного заказчи бителя. БС не влияют на процесс основной дея ка и предполагается, что появятся другие;

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

до года) или долгий (от повышение прибыли от использования системы не нескольких лет);

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

месяцев;

система контроля присутствия опасных газов;

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

стью;

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

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

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

явилась задача контроля присутствия опасных газов в точке, располагающейся на расстоянии до 1,5 ки лометров от точки наблюдения. Похожие особенно Особенности выполнения этапов анализа требований сти можно привести по остальным примерам. и проектирование БСМУ Из всего спектра областей применения БС мы рассматриваем системы мониторинга и управления Анализ требований и проектирование являются оборудованием электросвязи. типичными этапами любой системы. Несмотря на В общем случае БСМУ состоят из одной или не то, что в литературе и научных работах уделяется скольких сетей распределенных датчиков, актуато много внимания к формализации выполнения этих ров и центрального узла (ЦУ), выполняющего сбор этапов, много вопросов остается открытыми.

БИЗНЕС-ИНФОРМАТИКА №1(07)–2009 г. МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ Одними из таких вопросов являются совместное Использование COTS продуктов позволяет ис проектирование программных и аппаратных ком пользовать уже готовые части системы, по прием понентов, эффективная, с экономической точки лемой стоимости, которые уже выполняют часть зрения, декомпозиция задач и др. По определению функциональности системы.

БСМУ имеют как программную, так и аппаратную Другим подходом для реализации подсистем компоненту. Решение этих вопросов является является использование продуктов, относящихся принципиальным для успешного создания ВСМУ. к категории NDI [2] (nondevelopmental item). Эти В работах Николоса Вороса [2] и Клауса Бехендера продукты обладают своими особенностями:

[3] детально рассматриваются вопросы совместного существует полнофункциональная реализа дизайна и текущее состояние дел по этому вопросу. ция продукта, но она не удовлетворяет всем В работе Мухамеда Абида [4] приводится пример, критериям для широкой продажи на рынке на базе которого рассматривается влияние различ (например, нет качественной упаковки, оце ных дизайнерских решений для выполнения одной ниваемый потребительский спрос слишком и той же задачи на стоимость решения и ключевые мал для широких продаж и т.п.);

характеристики системы. для конечного пользователя существуют оп Основной вывод, который можно сделать по ре ределенные сложности получения информа зультатам [2–4] – это необходимость создания про ции о том, что продукт существует и какими тотипа как минимум до момента формирования характеристиками обладает;

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

типа приведены в работе Клауса Бехендера [5].

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

полняющая основные функции, и рассматривается Альтернативой COTS и NDI продуктам являет как нечто промежуточное между «почти готовым ся разработка уникальных компонентов системы с продуктом» и чем то, что должно быть разработано. расчетом на получение более дешевого решения.

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

Подходы к выполнению этапа реализации Разработка уникальных компонентов также подсистем БСМУ имеет свои достоинства и недостатки. Основным недостатком является невозможность с высокой Наиболее часто применяемым подходом для по степенью точности оценить затраты на разработку.

строения различных подсистем системы управления И опыт показывает, что сравнительно большой является использование COTS (Commercial Off the процент разработок заканчивается неудачей.

shelf) продуктов [6]. Термин COTS полностью опре К достоинствам разработки уникальных компо делен в [3] и относится к существующим продуктам, нентов можно отнести:

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

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

с изменяющимися требованиями при мини широко доступны;

мальных затратах;

могут быть куплены (получены в лизинг или возможность проектирования компонента, об лицензированы). ладающего дополнительными возможностями 30 БИЗНЕС-ИНФОРМАТИКА №1(07)–2009 г.

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ («на вырост»), не связанными непосредствен Эволюционирующее аппаратное обеспечение но с задачами текущего проекта;

это позволя ет в дальнейшем его использовать в виде са БСМУ – это сложная распределённая програм мостоятельного продукта категорий COTS мно аппаратная система. Именно распределен или NDI;

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

но сочетаться на основе определенной методологии Кроме того, стоимость этих узлов должна быть ми анализа и проектирования. По результатам анализа нимальной. Помимо этого требуется возможность реальных проектов можно сказать, что в ходе при для УПОИ быть подключенными к разнородному нятия решения о том, что должно использоваться оборудованию электросвязи. Таким образом, необ при построении БСМУ, придерживаются следую ходимо иметь достаточно большую номенклатуру щих эвристических правил: дешевых УПОИ.

1. Если существует COTS продукт, то использу Но существует альтернативный вариант – ис ется он. пользование эволюционирующего аппаратного 2. Если не существует СОТS продукта и сущест обеспечения (ЭАО), подробно рассмотренного в вует NDI продукт, то используется он. тематическом выпуске журнала «Communications of 3. Лишь в том случае, если нет ни COTS ни the ACM» [11 – 12]. Использование ЭАО позволяет, NDI продуктов, то принимается решение о разра помимо снижения номенклатуры УПОИ, решить и ботке. проблемы применимости RAD, быстрого создания прототипов и совместного проектирования про граммных и аппаратных компонент.

Модель быстрой разработки и компонентное конструирование Выводы Модель быстрой разработки приложений (Rapid Application Development, далее RAD) [8] обеспечи Ввиду специфических особенностей БСМУ не вает экстремально короткий цикл разработки. представляется возможным выработка универсаль RAD процесс позволяет создавать программные ных методик и подходов, пригодных для создания системы за период от 2 x до 3 х месяцев. Основу БСМУ для широкого круга предметных областей.

RAD составляет использование компонентно ори Предлагается следующий подход для построе ентированного конструирования. RAD применим ния БСМУ оборудованием электросвязи:

только тогда, когда требования к системе определе 1. Эволюционирующее аппаратное обеспечение ны полностью. Ключевой особенностью RAD явля должно быть использовано для построения прото ется построение моделей предметной области и со типов системы.

здаваемой системы с дальнейшей генерацией при 2. Должна быть разработана архитектура типо ложения по этим моделям. вой БСМУ с учетом особенностей использования Компонентное конструирование (КК) подразу RAD (быстрое создание приложений) подхода для мевает использование как COTS, так и NDI про реализации программных компонент системы.

дуктов. КК c точки зрения экономической эффек 3. Должны быть построены модели с целью вы тивности рассматривается в [9]. Основным досто полнения имитационного моделирования с целью инством КК является снижение затрат на разработ анализа различных вариантов построения системы.

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

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

траты сопряженные с ней.

БИЗНЕС-ИНФОРМАТИКА №1(07)–2009 г. МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ Литература 1. Boehm B.W., Abts C., Brown A.W., at al. Software Cost Estimation with COCOMO II. – Prentice Hall, 2000. 256 р.

2. Voros N. Hardware/Software Co design of Complex Embedded Systems // Design Automation for Embedded Systems. 2003.

№ 8. P. 5 –49.

3. Buchenrieder K. Integration of Reconfigurable Hardware into System Level Design // Design Automation for Embedded Systems. 2000. № 5. P. 222 –231.

4. Abid M. Exploration of Hardware/Software Design Space through a Co design of Robot Arm Controller // EURO DAC' with EURO VHDL'96. P. 599.

5. Buchenrieder K. Rapid Prototyping of Embedded Hardware/Software Systems // Design Automation for Embedded Systems.

2000. № 5. P. 215 –221.

6. COTS and Open Systems – An Overview: Software Technology Roadmap // http://www.sei.cmu.edu/str/descriptions/cots.html#110707.

7. Federal Acquisition Regulations. – Washington, DC: General Services Administration, 1996. 576 р.

8. McConnel S. Rapid Development. – Microsoft Press;

1st edition, 1996. 347 р.

9. Component Based Software Development / COTS Integration: Software Technology Roadmap // http://www.sei.cmu.edu/str/descriptions/cbsd.html.

10. Andrews D., Niehaus D. Programming Models for Hybrid CPU/FPGA Chips // Computer. 2004. № 1. P. 118 –120.

11. Xin Yao Evolvable Hardware: Introduction // Communications of ACM. 1999. V. 42. № 4. P. 46 –49.

12. Sipper M., Mange D., Sanchez E. Evolvable Hardware: Quo Vadis Evolvable Hardware? // Communications of ACM. 1999.

V. 42. № 4. P. 50 –56.

13. Marchal P. Evolvable Hardware: Field Programmable Gate Arrays // Communications of ACM. 1999. V. 42. № 4. P. 57 –59.

14. Higuchi T., Kajihara N.: Evolvable Hardware: Evolvable Hardware Chips for Industrial Application // Communications of ACM. 1999. V. 42. № 4. P. 60 –66.

Издательство «Синтег» выпустило новую книгу Владимира Васильевича Липаева, профессора кафедры управления программной инженерии ГУ ВШЭ и главного научного сотрудника Института системного программирования РАН «Отечественная программная инженерия:

фрагменты истории и проблемы».

В монографии проанализированы этапы отечественной истории развития вычислительной техники с акцентом на методы и процессы программи рования. Первая глава отражает развитие в стране автоматизации про граммирования в 50–60-е гг. Представлены процессы, начальные проек ты отечественной вычислительной техники, развитие программирования и роль ведущих специалистов, заложивших основы в этой области. Выде лены особенности развития специализированных вычислительных машин и программирования для оборонных систем реального времени. Формированию программной инженерии в 70-е гг. посвящена вторая глава. В тре тьей главе отражено развитие программной инженерии в 80-е гг. Изложена история развития экономики, мето дов и процессов программной инженерии в 70–80-е гг. Значительное внимание уделено реализации ПРОМЕТЕЙ-технологии программной инженерии для создания крупных комплексов программ реального вре мени оборонных систем. В четвертой главе подведены итоги развития программной инженерии и формирова ния ее методологии. Представлены проблемы расширения состава и совершенствования международных стан дартов и инструментария программной инженерии, а также проблемы обучения методологией программной инженерии студентов и специалистов.

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

32 БИЗНЕС-ИНФОРМАТИКА №1(07)–2009 г.




© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.