Организация и принципы системного проектирования СТС

В организации процесса проектирования СТC можно выделить следующие особенности:

1. В процессе проектирования взаимодействуют основные организации, участвующие в создании системы, в качестве заказчика, головного разработчика, разработчиков и пользователей. Важная роль отводится головному разработчику, функциями которого являются: 1) проведение предпроектных исследований; 2) разработка Т3 на создание системы; 3) взаимная увязка и стыковка проектных решений, выданных разработчиками-соисполнителями; 4) координация деятельности всех разработчиков системы.

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

3. Создание работоспособной системы, как единого целого, обеспечивается с помощью средств административного управления: 1) рабочих совещаний; 2) план-графиков; 3) накладных. Рабочие совещания собираются в составе главного конструктора и руководителей подразделений-исполнителей взаимосвязанных работ в начале каждого этапа создания системы, по его окончании и при возникновении разногласий между соответствующими подразделениями в ходе выполнения работ. Оперативные план-графики работ обеспечивают синхронизацию конкретных точек обмена информацией, так как для каждой работы в них указываются сроки получения промежуточных результатов, основной исполнитель и соисполнители, а также подразделения-потребители информации.

Накладные – это документы, по которым фиксируется завершение работы.

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

Тезис 1. Задача проектирования СТС неразрешима в рамках строго параллельной (декомпозированной только «по объекту») или полностью последовательной (декомпозированной только по «этапам») логической схемы.

Тезис 2. Задача построения сложных проектных решений обладает неопределённостью в части исходных данных, ограничений и целей.

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

Тезис 4. В силу тезисов 2, 3 задаче проектирования свойственна неединственность проектного решения. С другой стороны, в силу многоцелевого назначения СТС в общем случаи не представляется возможным сконструировать правило выбора единственного оптимального проектного решения.

Исходя из поставленных тезисов могут быть сформулированы аксиомы системного проектирования СТС.

Аксиома 1. Из неразрешимости общей задачи проектирования (тезис 1) вытекает необходимость её декомпозиции на совокупность локальных задач, упорядоченных многоуровневой параллельно-последовательной логической схемой проектирования.

Аксиома 2. Из неопределённости исходных данных и ограничений в общей задаче проектирования (тезис 2) вытекает необходимость их прогнозирования и обмена проектными решениями в соответствии с определённой логической схемой.

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

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

1.12. Математическая постановка задачи
принятия проектных решений

Задача проектирования, решаемая на этапе, представляется в виде общей (ОЗП) и частных (ЧЗП) задач, связанных с проектированием отдельных подсистем и элементов СТС. И ОЗП и ЧЗП являются задачами принятия проектных решений. Таким образом, математически задачу принятия Z можно представить в следующем виде:

Z = <t, S, K, F, f, r>,

где t – постановка (тип) задачи; S – множество решений (альтернатив), K= {K₁,…,K_n} – множество критериев; F = {F₁,...,F_n} – множество шкал критериев; f – отображение множества альтернатив в множество векторных оценок в критериальном пространстве; r – решающее правило.

Постановка задачи t в общем виде выглядит следующим образом: необходимо упорядочить множество решений S, выделить множество предпочтительных решений или наиболее предпочтительное решение. Множество S представляет собой совокупность возможных проектных решений.

Каждое решение оценивается по критериям K₁, …, K_n, которые являются показателями эффективности и качества проектных решений. Для каждого из критериев должна быть задана шкала, представляющая собой множество упорядоченных оценок. Шкалы F₁, ..., F_n могут быть числовыми и нечисловыми. Декартово произведение F= F₁*...* F_n образует критериальное пространство. Множеству решений S с помощь отображения f ставится в соответствие множество векторных оценок в критериальном пространстве F. С помощью решающего правила r из множества проектных решений выбираются одно или нескольких предпочтительных решений.