CC BY
68рой будет создана система, обеспечивающая повышение эффективности деятельности организации.
Рассмотрим основные аспекты ситуации формулировки цели проекта. При анализе будем рассматривать следующий круг «заинтересованных» лиц:
• заказчик проекта - лицо, принимающее решение в отношении формулировки задания и подтверждающее, что проект выполнен в соответствии с заданием;
• спонсор проекта — представитель организации, который выступает в качестве связующего звена между заказчиком проекта и проектной группой;
• аналитик - специалист в области применения принципов системного анализа в практической деятельности;
• проектировщик - проектная группа, разрабатывающая проект;
• пользователи - персонал, который будет использовать систему в своей работе. Заказчик проекта и пользователи являются представителями организации, инициировавший проект, а аналитик и проектировщик входят в проектную группу и являются исполнителями проекта. Роль аналитика в проектной группе заключается в профессиональном применении методов системного анализа и проектирования на всех этапах выполнения проекта. Роль пользователя заключается в формировании требований к проектируемой системе, обеспечивающих соблюдение всех технологических аспектов и удобство использования системы.
1. Начальный этап проектирования
Исходным моментом проектирования является принятие решения заказчика о начале работ по созданию системы и формирование проектной группы. Чтобы найти правильное проектное решение, прежде всего, необходимо оценить поставленную задачу с точки зрения ее соответствия реальным проблемам организации. Проектировщик должен выявить побудительные причины, которые легли в основу принятия этого решения. В системном анализе есть принцип, согласно которому формулировка задания заказчиком отражает только его точку зрения и не может быть принята к исполнению без анализа и уточнения со стороны проектировщика [1]. Такой анализ должен быть основан на учете всех внешних и внутренних факторов, влияющих на систему в контексте поставленной задачи. Эффективно эту задачу может выполнить только аналитик, так как обладает соответствующими профессиональными навыками. В том случае, когда функции аналитика берет на себя проектировщик, увеличивается риск принятия неэффективных проектных решений, так как проектировщик, в большинстве случаев, относится к этапу анализа как к обязательной, но не самой главной части проекта.
Цель первого этапа анализа задачи проекта - определение существенных факторов, которые могут повлиять на проектное решение. Для этого аналитику необходимо декомпозировать задачу на составные части (подзадачи) и для каждой части определить сферу деятельности организации, которые связаны с составными частями (подзадачами). Для каждой сферы деятельности требуется выявить факторы внешней и внутренней среды функционирования системы, которые существенно влияют на результат деятельности в этой сфере. Работу по декомпозиции задачи аналитик должен выполнять в тесном взаимодействии со спонсором проекта, так как только ответственный представитель организации может подтвердить справедливость логических построений, которые будет формулировать аналитик.
На втором этапе аналитического исследования необходимо выявить проблемы организации, связанные с задачей. Декомпозиции задачи на подзадачи, сферы деятельности и факторы влияния образуют контекст, в рамках которого идентифицируются проблемы организации. Возможность такой идентификации основана на целевом характере постановки задачи - если задача поставлена (есть определенная цель), то она должна решать реальные
проблемы предприятия. Идентификация проблем производится на основе восстановления логической связи между задачей и проблемой. Наиболее эффективной методологий, обеспечивающей выявления истинных проблем организации, является теория ограничения систем (TOC) [2], в рамках которой разработаны инструменты для проведения анализа. Если между задачей и проблемой действительно существует взаимосвязь, то, используя инструменты TOC, аналитик сможет сформулировать список проблем, существующих реально в деятельности организации.
Рис. 1. Декомпозиция задачи проекта на этапе аналитического анализа
Для каждой проблемы из этого списка необходимо проверить исходные предположения, лежащие в основе связи между задачей и проблемой [2]. Исходные предположения формулируются по следующей логической схеме: «Чтобы устранить (проблему), необходимо решить (задачу), потому что: (исходные предположения)». В формулировке исходных предположений следует использовать те сферы деятельности и факторы, которые связаны с задачей в декомпозиции. В результате анализа исходных предположений необходимо или подтвердить, что такая взаимосвязь действительно существует в реальности или подвергнуть сомнению истинность этой связи. Если для части задач не удается определить проблему, то данные задачи выделяют в отдельный список для последующего анализа. В том случае, когда некоторые проблемы, выявленные аналитиком, не удается связать с задачами проекта, следует попытаться сформулировать дополнительные задачи проекта. Они должны войти в список задач проекта. Результатом аналитического этапа выполнения проекта заказчику будет представлен уточненный вариант задания на разработку системы будут обоснованием всех ключевых моментов и, прежде всего, цели (задачи) проекта. Принятие уточненного варианта задания на проектирование повышает качество проекта за счет его аналитического обоснования.
Таким образом, первым принципом проектирования организационно-технических систем является детальный анализ задания на проектирование.
2. Моделирование предметной области
Следующий шаг в разработке любой системы - описание предметной области, для которой создается система. Для создания наглядного образа организационно - технической системы целесообразно работу по описанию предметной области начать с основных объектов системы, на которые направлена деятельность организации в данной предметной области. Обычно объекты системы представляют собой упорядоченную структуру. Основной вопрос, на который должны ответить разработчики, это тип структуры объектов предметной области. Можно выделить следующие типовые структуры для объектов:
• списочная (парковая) структура однородных объектов, между которыми отсутствует взаимодействие;
• сетевая структура взаимосвязанных объектов. Для такого типа структуры требуется описание не только самих объектов, но и элементов инфраструктуры, через которую происходит взаимодействие объектов;
• структура распределенных объектов. Данный тип структуры является разновидностью сетевой структуры, в которой сама инфраструктура является основным объектом предметной области, так как объекты распределены по сети. В данной структуре используются простые объекты, т.е. не требующие декомпозиции своей внутренней структуры. Примером структуры распределенных объектов является железнодорожный путь, формируемый верхним строением пути, состоящим из рельсов, шпал, скреплений и балласта.
На этапе разработки модели объектов предметной области необходимо произвести декомпозицию внутренней структуры объектов, причем степень детализации внутренней структуры будет определяться задачами проекта разработки системы.
Важным элементом общего образа предметной области является модель организационной структуры, в рамках которой происходит деятельность. Основные особенности организации деятельности должны быть выявлены до начала основных работ по проекту.
Таким образом, вторым принципом проектирования организационно-технических систем является создание общего образа предметной области.
Разработка модели функций системы - ключевой момент в проекте. Одной из самых эффективных методологий разработки моделей функций системы выступает методология структурного анализа и проектирования (БАОТ) [3]. Базовые элементы модели функций системы: цель моделирования, точка зрения и система - модель взаимодействия системы с окружающим миром (границы системы).
Определяющим моментом работы по описанию функционирования системы является точность формулировки цели моделирования. Очевидно, что при определении цели моделирование необходимо учитывать цели проекта, однако между этими целями нет прямой взаимосвязи, так как они относятся к различным сферам деятельности: цели проекта относятся к деятельности организации, а цели моделирования - к технологии разработки модели деятельности.
В большинстве случаев заказчик формулирует задание как разработку и внедрение предложений по повышению эффективности работы организации в определенной сфере деятельности. Средством реализации этих предложений является проектируемая система. Предложения по повышению эффективности деятельности могут касаться различных аспектов: организационных, технологических и т.д. Если эти предложения касаются организации деятельности, то разработчики системы должны цель разработки модели системы формулировать с учетом того, что модель должна отвечать на вопросы о функционировании системы в тех сферах деятельности, с которыми связаны предложения по повышению эффективности деятельности. Кроме того, разработчики должны предложить изменения функций существующей системы, определить ее новые функции и «встроить» их в модель существующей системы. Таким образом, в цели разработки модели должны быть основаны на предложениях по повышению эффективности работы организации.
Таким образом, третьим принципом проектирования организационно - технических систем является формулировка цели разработки модели системы на основе предложений по повышению эффективности организации
Рассмотрим проблемы определения границ системы, которые напрямую связаны со сферой деятельности, рассматриваемой в проекте. В явном виде границы предметной области в задании на проектирование не указываются, они подразумеваются из контекста содержания задания. При формировании решаемой задачи аналитик должен определить границы системы в явном виде. Методология структурного анализа и проектирования рекомендует начинать разработку функциональной модели системы с составления списка объектов и списка функций. При анализе списка функций необходимо определить «внешние» функции по отношению к системе и «внутренние». Разделение функций производится по результатам ответа на вопрос: «Входит ли данная функция непосредственно в сферу деятельности, рассматриваемую в проекте?». Если ответ на это вопрос положительный, то данная функция должна быть включена в список «внутренних» функций. «Внешние функции» относятся к деятельности внешних подсистем, взаимодействие с которыми существенно для описания предметной области.
Рис. 2. Разделение функций на «внешние» и «внутренние»
Взаимодействие с внешними подсистемами отображается в виде связей, которые отображаются на контекстной диаграмме функциональной модели. «Внутренние» функции составляют основу для формирования базовых функций системы, которые отображаются на диаграмме основных функций системы.
Декомпозиция основной функции системы осуществляется в соответствии с рекомендациями методологии системного анализа и проектирования (БАОТ). Описание существующих функций системы дается в виде модели «как есть». Разработка этой модели ведется на основе утвержденных нормативных документах о порядке деятельности в данной предметной области с учетом информации, получаемой от специалистов предметной области (экспертов) о реальных приемах их работы. Границы описания деятельности определяются сферой предметной области, рассматриваемой в проекте, а степень детальности - поставленными задачами проекта.
Внешняя
подсистема 1 ^
Связь 1.1
Связь 1.2
{> {>
Основная функция системы
ЕЕ01
Связь 2.1
Связь 2.2
V
Внешняя
подсистема 2
Рис. 3. Формирование внешних связей системы на контекстной диаграмме модели
Практика показывает, что разработка модели функций системы только в виде диаграмм не всегда обеспечивает получение точного и полного описания системы, так как провоцирует на «формальное» моделирование. Методология БАОТ рекомендует для повышения качества разработки моделей использовать авторское рецензирование, которое проводиться в виде ответов на вопросы [3]. Повышение качества разработки БАОТ моделей может быть повышено за счет использования текстового описания модели, как метод логического моделирования. Хотя БАОТ модель структурирует естественный язык, однако логичность утверждения, которая скрыта в функциональной модели, может быть проверена только после превращения в соответствующее текстовое описание. В этом случае логика функционального моделирования проверяется логикой высказывания в виде текста, и большинство логических ошибок функционального моделирования удается выявить на этапе описания диаграммы.
На основании этого можно сформулировать четвертый принцип проектирования организационно-технических систем: сочетание логического и функционального подхода в разработке моделей систем.
Следующим шагом в разработке функциональной модели является определение новых функций системы, которые обеспечивают решение задачи проекта. Новые функции системы должны определяться из целей проекта, принятых на первом этапе. Очевидно, что одна и та же цель может быть достигнута различными способами. Разработчики новой системы должны определить эти способы и выбрать из них тот, который обеспечит достижение поставленных целей наиболее эффективным способом. Список новых функций системы послужит основанием для изменения модели системы, таким образом, чтобы обеспечить функционирование действующей системы в соответствии с задачами проекта. Такая измененная модель системы (модель «как должно быть») разрабатывается в следующей последовательности:
• определяется взаимодействие новых функций с функциями модели «как есть»;
• переход от модели «как есть» к модели «как должно быть» за счет введения новых функций;
• корректировка функций модели, перешедших из модели «как есть».
Рассмотрим последовательность разработки модели «как должно быть» на иллюстративном примере. Пусть в организации используется цикл управления (РОС): планировать - выполнить - контролировать. Заказчиком сформулирована следующая задача - повысить эффек-
3. Модель будущего состояния системы
тивность системы управления организацией. Аналитик проекта разработал предложение - внедрить процессный подход в управлении [4]. Модель «как есть» представлена на рис. 4.
Рис. 4. Модель системы «как есть»
Функция Планировать (А1) выполняется на основе Стратегического плана и Отчета о выполнении плана. В функции Выполнить (А2) Вход преобразуется в Выход. В функции Контролировать (А3) проводится сравнение Плана и Выхода и на основе этого сравнения формируется Отчет о выполнении плана. Данный цикл управления используется в тех случаях, когда основное внимание в деятельности сосредоточено на достижении количественных показателях, заложенных в плане.
Внедрение процессного подхода изменяет систему управления организацией в результате использования в управлении цикла Деминга РБСЛ (планировать, выполнить, проверить, воздействовать). Такой цикл управления ориентирован на повышение показателей качества деятельности. Анализ сути предложения позволяет сформулировать следующие изменения, которые требуется произвести в модели деятельности:
• необходимо планировать не только количественные, но и качественные показатели деятельности;
• при выполнении работ следует ориентироваться не только количественные показатели, но соблюдать правила, обеспечивающие требования качества;
• функция контроля преобразуется в две функции - проверить и воздействовать. Это связано с изменением стиля управления - переходом от непосредственной реакции на отклонение к разработке воздействия на процесс на основе анализ отклонений плановых показателей, как по количественным, так и качественным признакам.
В результате использования цикла РБСЛ функциональная модель «как должно быть» будет иметь вид, представленный на рис. 5.
Рис. 5. Модель системы «как должно быть»
В данной модели используется набор объектов Воздействие. В него входят и Отчет о выполнении количественных показателей, на основе которого будет проводиться разработка Плана. В этот набор объектов входят Управленческие решения, обеспечивающие устранение недостатков в деятельности в области качества. В функции Проверить А3 проводиться проверка результатов деятельности (Выход) как по количественным, так и по качественным показателям. Результаты анализа отклонений служат основой для выработки Воздействия.
Анализ данного иллюстративного примера позволяет сделать следующий практический вывод - для разработки модели «как должно быть» необходимо предварительно провести анализ тех изменений, которые требуется внести в модель «как есть». Результаты этого анализа следует зафиксировать в виде списка дополнительных объектов и функций модели «как должно быть» и списка объектов и функций, которые должны быть исключены из модели. В том случае, когда объекты и функции в модели «как должно быть» изменяют свое определение, то это должно быть также предварительно зафиксировано в описании необходимых изменений. Возникает вопрос: «В в какой форме наиболее рационально зафиксировать результаты такого анализа?». На основе принципа сочетание логического и функционального подхода в разработке моделей систем целесообразно сначала предлагаемые изменения оформить в виде текстового описания (логическая модель), а затем реализовать в функциональной модели «как должно быть». После этого согласовать логическую и функциональную модели.
Пятым принципом проектирования организационно-технических систем, является переход к модели «как должно быть» производить на основе детального текстового описания необходимых изменений.
Для организационно-технических систем организационный аспект деятельности имеет такое же определяющее значение, как и технический аспект. В связи с этим, при
разработке проектов необходимо уделить этому вопросу должное внимание. Речь идет об определении организационных проектных решений, требующихся для реализации технических проектных решений. Эта задача решается на основе разработки технологической модели проекта. В рамках разработки проекта системы под технологической моделью понимается описание действий, которые должен выполнять персонал, использующий систему в своей деятельности. Разработка технологической модели ведется на основе функциональной модели «как должно быть» и является ее отражением на организационную структуру, обеспечивающим реализацию функций системы.
Технологическая модель может состоять из нескольких разделов в зависимости от числа операций технологических процессов, подлежащих описанию. Каждый раздел должен четко детально характеризовать всю последовательность работы персонала в условиях данной технологии. Указываются:
• перечень функциональных ролей (должностей);
• порядок выполнения операций, при этом для каждой операции указывают:
- при каких условиях следует выполнять операцию;
- какова цель, результат операции;
- порядок выполнения операции;
- сроки, затрачиваемые на выполнение процесса (операции), исполнителей (отдел, должность);
- кто контролирует выполнение операции.
На технологические операции рекомендуется составлять блок-схемы, поясняющие инструкции. Графическое изображение технологических процессов наглядно демонстрирует все связи и взаимодействия при выполнении операций технологического процесса.
Принцип разработки технологической модели реализации функций системы является завершающим, шестым, принципом проектирования систем на основе системного подхода.
Заключение
Таким образом, для повышения качества проектирования организационно-технических систем рекомендуется использовать следующие принципы:
1. Детальный анализ задания на проектирование;
2. Создание общего образа предметной области;
3. Формулировка цели разработки модели системы на основе предложений по повышению эффективности организации;
4. Сочетание логического и функционального подхода в разработке моделей систем
5. Переход к модели «как должно быть» производить на основе детального текстового описания необходимых изменений;
6. Разработка технологической модели реализации функций системы.
Данные принципы направлены на повышение уровня системности процесса проектирования, заключающегося в принятии решений на основе:
• структурирования всех данных, используемых при проектировании;
• выявления причинно-следственных связей при детальном анализе проблем;
• логического анализа получаемых результатов.
Библиографический список
1. Перегудов, Ф.И. Введение в системный анализ / Ф.И. Перегудов, Ф.П. Тарасенко. - М.:
Высш. шк., 1989. - 367 с.
2. Детметр, У. Теория ограничений Голдратта. Системный подход к непрерывному
совершенствованию: [пер. с англ.] / Уильям Детметр. - М.: Альпина Паблишерз, 2010. - 444 с.
3. Марка, Д.А. Методология структурного анализа и проектирования: [пер. с англ.] /
Д. А. Марка, К.М. Гоуэн. - М.: МетаТехнология, 1993. - 240 с.
4. Репин, В.В. Процессный подход к управлению. Моделирование бизнес-процессов / В.В. Репин, В.Г. Елиферов. - М.: РИА «Стандарты и качество», 2004. - 408 с.
Дата поступления в редакцию 25.06.2013
A.V. Zaporozhtsev
THE DESIGN PRINCIPLES OF ORGANIZATIONAL AND TECHNICAL SYSTEMS
Nizhny Novgorod state technical university n.a. R.E. Alexeev
Purpose: To determine the principles of design of organizational and technical systems, designed to improve the quality of project development.
Methodology: Development of principles of designing is based on a detailed analysis of the design process from the point of view of system approach, methods of structural analysis and design (SADT), using the principles and tools of the theory of constraints systems (TOC) and the process approach in management.
Approach: Improving the consistency of the design process, consisting in making decisions on the basis of:
• structuring of all the data used in the design;
• problem analysis based on the identification of causal relationships;
• logical analysis of the obtained results.
Results and application area: Designed basic principles of design of organizational and technical systems that cover all stages of project development from the analysis of the design task to develop a technological models of realization of functions of the system. These principles can be used in the practice of design of any organizational - technical systems. Summary: The real increase of the quality of the design can be achieved only through informed use of systemic methodologies.
Key words: organizational and technical system, systems approach, system model, structural analysis and design, theory of constraints systems.
ЯДЕРНАЯ ЭНЕРГЕТИКА И ТЕХНИЧЕСКАЯ ФИЗИКА
УДК 621.378.82
В.А. Бажилов, Е.А. Михалицын
ТОЧНАЯ ЮСТИРОВКА ФИКСИРОВАННЫХ АТТЕНЮАТОРОВ С МАЛЫМ УРОВНЕМ ОСЛАБЛЕНИЯ
ФНПЦ «НИИИС им. Ю.Е. Седакова»
Проведено исследование влияния лазерной подгонки на характеристики СВЧ аттенюаторов с малым уровнем ослабления построенных на основе неоднородных распределенных резистивных структур.
Ключевые слова: фиксированные аттенюаторы, резистивные пленки, лазерная подгонка.
Введение
Фиксированные аттенюаторы в микрополосковом тонкопленочном исполнении находят широкое применение в трактах приемопередающей РЭА СВЧ и используются для калиброванного ослабления мощности, развязки взаимовлияющих функциональных узлов, согласования импедансов в межкаскадных СВЧ цепях. В литературе подробно рассмотрены вопросы расчета и проектирования тонкопленочных микрополосковых аттенюаторов среднего и высокого уровня ослабления [1-3], тогда как аттенюаторы с малым ослаблением (0,5-4 дБ) в силу ряда их особенностей исследованы не в полной мере.
Известно, что лазерная подгонка резистивных структур аттенюатора позволяет смягчить конструктивно-технологические требования к формированию топологии и самому процессу изготовления. Вместе с тем, анализ влияния лазерной подгонки резистивных пленок на частотные характеристики и тепловые режимы работы устройства в литературе практически отсутствует. А компромиссное соотношение технологических возможностей производства и требований к техническим характеристикам аттенюатора позволит увеличить выход годной готовой продукции и снизить её стоимость. В данной работе проводится численное исследование влияния величины реза неоднородной резистивной структуры на частотные свойства фиксированных аттенюаторов малого уровня ослабления. При этом очень важным аспектом расчета является его нацеленность на практическое применение в инженерной и технологической практике.
Конструктивная и расчетная модели
Рассмотрим низкодецибельный аттенюатор, конструктивно представляющий собой диэлектрическую пластину, на верхнюю сторону которой нанесены две тонкие (меньше толщины скин-слоя) резистивные пленки, а также проводящие центральные и заземляющий контакты (рис.1). Между входным и выходным центральными контактами напыляется рези-стивная пленка с малой величиной поверхностного сопротивления р1=5 - 25 Ом/а Пленка с более высоким значением поверхностного сопротивления р2=100 - 1000 Ом/^ примыкает к низкоомной и соединяется с заземляющим контактом. Заземление осуществляется косвенным образом с помощью перемычки.
© Бажилов В.А., Михалицын Е.А., 2013.
