Программа системного анализа это

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

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

На 1-м этапе проектирования ПО важно найти и понять, что на самом деле желает пользователь. Нередко это совсем непросто сделать, ведь даже пользователь не всегда представляет, что же он хочет получит в действительности.

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

Принципы системного анализа

Если требования определены некачественно, это станет причиной разработки программного продукта, который станет пусть даже и правильно решать задачу, но делать это он будет в отношении задачи, которая сама по себе сформулирована неверно. Как известно, если «написано что-нибудь не то», то и реализовано будет «что-нибудь не то», то есть продукт не будет отвечать истинным потребностям заказчика.

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

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

Результат системного анализа — ясное понимание того: 1) что требует пользователь; 2) что хочет пользователь.

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

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

Что такое системный анализ?

Источник: otus.ru

Системы бизнес и системного анализа

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

Чтобы претендовать на включение в категорию Систем бизнес и системного анализа, программный продукт должен:

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

Читать далее

Сравнение Системы бизнес и системного анализа

Выбрать по критериям:

Системы бизнес и системного анализа

Подходит для
Специалист
Малый бизнес
Средний бизнес
Корпорация
Администрирование
Анализ бизнес-процессов

Анализ и управление требованиями
Генерация программного кода
Графическое моделирование схем и диаграмм
Импорт/экспорт данных
Математическое моделирование и симуляция
Многопользовательский доступ
Наличие API
Отчётность и аналитика
Оценка рисков

Применение репозитория
Управление архитектурой предприятия
Управление задачами
Тарификация
Ежемесячная оплата
Ежегодная оплата

Единовременная оплата
Оплата потребления
По запросу
Развёртывание
Сервер предприятия
Мобильное устройство
Персональный компьютер
Облако (SaaS)
Графический интерфейс

Веб-браузер
Поддержка языков
Азербайджанский
Белорусский
Бенгальский
Болгарский
Венгерский
Вьетнамский
Грузинский
Индонезийский

Итальянский
Каталонский
Латвийский
Монгольский
Нидерландский
Норвежский
Персидский

Португальский
Украинский
Французский
Хорватский
Английский

Нет продуктов

Руководство по покупке Системы бизнес и системного анализа

1. Что такое Системы бизнес и системного анализа

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

2. Зачем бизнесу Системы бизнес и системного анализа

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

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

3. Назначение и цели использования Системы бизнес и системного анализа

Программное обеспечение для бизнес и системного анализа (Business and Systems Analysis Software) предназначено для структурированного исследования и описания моделей бизнеса и моделей систем. Такое описание в зависимости от достигаемых целей может отражать текущее состояние бизнеса (“как есть”, англ. “as is”) или желаемое будущее состояние (“как должно быть”, англ. “to be“). Программное обеспечение данной категории, формируя единое пространство представления деятельности организации, помогает наладить взаимодействие между всеми участниками процессов развития бизнеса, максимально достоверно транслируя требования руководителей и решения рабочих команд.

Программные продукты бизнес и системного анализа помогают специалистам формализовать представления о бизнес-процессах, системах управления, информационных системах, сложноорганизованной архитектуре предприятия (АП, англ. Enterprise Architecture, EA) и требованиям к ним.

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

4. Обзор основных функций и возможностей Системы бизнес и системного анализа

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

Функции управления требованиями позволяют производить размещение требований по моделям, создавать очереди требований, отслеживать согласованность и статус требований Генерация программного кода Функции генерации программного кода позволяют по результатам создания моделей информационной системы автоматически создавать заготовки программного кода для реализации соответствующих модулей системы. По результатам генерации кода остаётся дополнить созданные программные модули кодом с программной логикой Графическое моделирование схем и диаграмм Функции Графического моделирования схем и диаграмм реализуют возможности создания графических моделей систем, бизнес-процессов, архитектур предприятия и иных объектов в различных нотациях (UML, BPMN, IDEF, ARIS, DFD и прочие) Импорт/экспорт данных Возможность импорта и/или экспорта данных в продукте позволяет загрузить данные из наиболее популярных файловых форматов или выгрузить рабочие данные в файл для дальнейшего использования в другом ПО.

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

Наличие API Часто при использовании современного делового программного обеспечения возникает потребность автоматической передачи данных из одного ПО в другое. Например, может быть полезно автоматически передавать данные из Системы управления взаимоотношениями с клиентами (CRM) в Систему бухгалтерского учёта (БУ).

Для обеспечения такого и подобных сопряжений программные системы оснащаются специальными Прикладными программными интерфейсами (англ. API, Application Programming Interface). С помощью таких API любые компетентные программисты смогут связать два программных продукта между собой для автоматического обмена информацией. Отчётность и аналитика Наличие у продукта функций подготовки отчётности и/или аналитики позволяют получать систематизированные и визуализированные данные из системы для последующего анализа и принятия решений на основе данных. Оценка рисков Функции Оценки рисков обеспечивают выявление и анализ потенциально-негативных событий, а также оценку их последствий для предприятия на основании исторических данных и с учётом влияющих факторов Применение репозитория Функции применения репозитория (хранилища) позволяют группе пользователей использовать общее единое место для хранение моделей и документов, обеспечивая тем самым возможность командной работы в аналитическом проекте Управление архитектурой предприятия Функции Управления архитектурой предприятия позволяют реализовать различные представления организационной архитектуры (в зависимости от уровня требований), позволяя объединить и гармонизировать различные представления предприятия в понятную и последовательную совокупность моделей. Для представления архитектур могут использоваться как собственные наборы представлений, так и общепринятые каркасы архитектуры (фреймворки типа TOGAF, Модель Закмана, CIMOSA, SOA, EAF, ARIS и прочие) Управление задачами Функции Управления задачами предоставляют организационные инструменты для использования данного программного продукта, включая планирование работы, постановку задач, контроль и учёт результатов работы в системе

5. Выгоды, преимущества и польза от применения Системы бизнес и системного анализа

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

6. Виды Системы бизнес и системного анализа

Системы анализа бизнес-процессов Программное обеспечение анализа бизнес процессов помогают специалистам систематизировать и формализовать сведения о деятельности предприятия. Системы имитационного моделирования Системы имитационного моделирования позволяют создавать и анализировать цифровую модель физического объекта для прогнозирования работоспособности этого объекта в реальных условиях.

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

Системы разработки архитектуры предприятия Системы разработки архитектуры предприятия (АП, англ. Enterprise Architecture, EA) позволяет формализовать представление о предприятии в виде комплекса взаимосвязанных моделей. Используя комплексную модель архитектуры предприятия, организации получают полное видение своей деятельности (бизнеса): характер деятельности, процессы, потоки управления, ИТ-инфраструктура, бизнес-модели, продукты и услуги. Системы анализа требований Программное обеспечение анализа требований помогают специалистам проводить сбор и фиксирование требований, их систематизацию, приоритизацию, построение взаимосвязей на протяжении всего жизненного цикла требований к процессу, продукту, услуге. Инструменты системного анализа и проектирования Программные продукты системного анализа и проектирования используются для изучения, визуального моделирования и проектирования систем: информационных систем, технических систем и программного обеспечения.

7. Отличительные черты Системы бизнес и системного анализа

Чтобы претендовать на включение в категорию Систем бизнес и системного анализа, программный продукт должен:

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

Источник: soware.ru

Основные принципы системного анализа в SEBoK

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

В отличие от SWEBoK , SEBoK распространен в России намного меньше. По крайней мере при подготовке учебного курса для магистратуры, найти хоть каких-то переводов его статей мне не удалось. А тем не менее, книга структурирует очень полезные и пока что разрозненные знания в области разработки больших систем и, в том числе, системного анализа.

Так как мой курс касался именно системного анализа, под катом будет перевод этой главы SEBoK… Но это всего несколько глав одного из 7 разделов книги.

P.S. Буду благодарен за комментарии и Ваше мнение об этой статье (качестве, необходимости) и об интересе к системному анализу и системной инженерии.

Основные принципы системного анализа

• Определения критериев сравнения на основе системных требований;
• Оценки предполагаемых свойств каждого альтернативного решений в сравнении с выбранными критериями;
• Сводной оценки каждого варианта и ее объяснения;
• Выбора наиболее подходящего решения.

• Системный анализ – итеративный процесс, состоящий из оценки альтернативных решений, полученных в процессе синтеза системы.
• Системный анализ основывается на критериях оценки, основанных на описании проблемы или возможности системы;

• Критерии основываются на базе идеального описания системы;
• Критерии должны учитывать требуемое поведение и свойства системы в итоговом решении, во всех возможных более широких контекстах;
• Критерии должны включать нефункциональные вопросы, например: безопасность и защищенность системы и т.д. (подробнее описывается в главе «Системная инженерия и специальное проектирование»).
• «Идеальная» система может поддерживать «нестрогое» описание, из которого могут быть определены «нечеткие» критерии. Например, стейкхолдеры выступают за или против некоторых видов решений, соответствующие социальные, политические или культурные условности должны также учитываться и т.д.

• Исследование компромиссов – междисциплинарный подход для поиска наиболее сбалансированного решения среди множества предполагаемых жизнеспособных вариантов.
• При исследовании рассматривается весь набор критериев оценки, с учетом их ограничений и взаимосвязей. Создается «система критериев оценки».
• При сравнении альтернатив придется иметь дело одновременно с объективными и субъективными критериями. Необходимо особо внимательно относиться к определению влияния каждого критерия на общую оценку (чувствительность общей оценки).

Исследование компромиссов

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

• Критерии оценки используются для классификации различных вариантов решения. Они могут быть относительные или абсолютные. Например, максимальная цена на единицу продукции – в рублях, снижение затрата — %, повышение эффекивности — %, снижение риска так же в %.
• Определяются допустимые границы критериев оценки, которые применяется во время анализа (например, вид издержек, которые необходимо принять во внимание; приемлемые технические риски и т.д.);
• Для сравнения количественных характеристик используются шкалы оценки. Их описание должно включать максимальный и минимальный предел, а также порядок изменения характеристики в этих пределах (линейная, логарифмическая и т.д.).
• Оценочный балл присваивается каждому варианту решения по всем критериям. Цель исследования компромиссов – обеспечить количественное сравнение по трем направлениям (и их декомпозиции на отдельные критерии) для каждого варианта решения: затраты, риск и эффективность. Эта операция как правило сложна и требует создания моделей.
• Оптимизация характеристик или свойств улучшает оценку наиболее интересных решений.

• Субъективные критерии оценки – персональное мнение аналитика. Например, если компонент должен быть красивым, то что собой представляет критерий «красивый»?
• Неопределенные данные. Например, инфляция должна быть учтена при расчете затрат на обслуживание для полного жизненного цикла системы. Как системный инженер может прогнозировать развитие инфляции в следующие пять лет?
• Анализ чувствительности. Общая оценка, выставляемая каждому альтернативному решению, не абсолютна; поэтому рекомендуется проводить анализ чувствительности, который учитывает небольшие изменения «весов» каждого критерия оценки. Оценка считается надежной, если изменение «весов» не изменяет существенно саму оценку.

Тщательно проведенное исследование компромиссов определяет допустимые значения результатов.

Анализ эффективности

Анализ эффективности отталкивается от контекста использования системы или проблемы.

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

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

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

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

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

Анализ затрат

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

Тип Описание и пример

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

Методы определения стоимости затрат описываются в разделе «Планирование» (раздел 3).

Анализ технических рисков

1. Вероятность реализации (вероятность того, что риск оправдается, и цели не будут достигнуты);
2. Степень влияния или последствия реализации.

1. Анализ наличия потенциальных угроз или нежелательных событий и вероятности их возникновения.
2. Анализ последствий выявленных угроз и их классификация по шкале тяжести.
3. Снижение вероятности угроз или уровня их воздействия до приемлемых значений.

• Неправильная оценка технологических возможностей;
• Переоценка технической готовности элемента системы;
• Аварии из-за износа или устаревания оборудования, комплектующих или ПО,
• Зависимость от поставщика (несовместимые детали, задержка поставки и т.д.);
• Человеческий фактор (недостаточное обучение, неправильные настройки, недостаточная обработка ошибок, выполнение несоответствующих процедур, злой умысел) и т.д.

Процессный подход

Цель и принципы подхода

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

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

Задачи в рамках процесса

• Планирование изучения альтернатив:

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

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

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

Артефакты и терминология процесса

• Модель критериев выбора (список, шкалы оценки, веса);
• Отчеты по анализу затрат, рисков, эффективности;
• Отчет с обоснованием выбора.

В процессе используются термины, перечисленные в таблице ниже.

Термин Описание

Критерий оценки	В контексте системного анализа, критерий оценки – характеристика, используемая для сравнения элементов системы, физической архитектуры, функциональных сценариев и других элементов, которые могут сравниваться. Включает: идентификатор, название, описание, вес.
Оценочный выбор	Управление элементами системы, на основе оценочного балла, который объясняет выбор элементов системы, физической архитектуры или сценария использования.
Оценочный балл (оценка)	Оценочный балл получают элементы системы, физической архитектуры, функциональных сценариев используя набор критериев оценки. Включает: идентификатор, название, описание, значение.
Затраты	Значение в выбранной валюте, связанное со значением элемента системы и т.д. Включает: идентификатор, название, описание, сумма, тип затрат (разработка, производство, использование, обслуживание, утилизация), метод оценки, период действия.
Риск	Событие, которое может произойти и повлиять на цели системы или ее отдельные характеристики (технические риски). Включает: идентификатор, название, описание, статус.

Проверка правильности системного анализа

• Соответствие моделей и данных в контексте использования системы;
• Соответствие критериев оценки относительно контекста использования системы;
• Воспроизводимость результатов моделирования и расчетов;
• Достаточный уровень точности шкал сравнения;
• Доверие к оценкам;
• Достаточный уровень чувствительности полученных баллов относительно весов критериев оценки.

Принципы использования моделей

• Использование общих моделей. Различные типы моделей могут быть использованы в контексте системного анализа.

• Физические модели – масштабные модели, позволяющие экспериментировать с физическими явлениями. Специфичны для каждой дисциплины; например: макеты, испытательные стенды, прототипы, вибростолы, декомпрессионные камеры, воздушные тоннели и т.д.
• Модели представлений в основном используются для моделирования поведения системы. Например, диаграммы состояний и т.д.
• Аналитические модели используются для установления значения оценок. Используют уравнения или диаграммы для описания реальной работы системы. Они могут быть как очень простые (сложение элементов), так и невероятно сложные (вероятностное распределение с несколькими переменными).

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

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

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

• Построить иерархию критериев;
• Связать с каждым критерием каждой ветви дерева с его «весом» относительно критериев того же уровня.
• Вычисляется вес для каждого «листа» критериев для каждой ветви умножением на все веса ветки.
• Оценить каждый альтернативный вариант решения по листьям критериев, суммировать оценки и сравнить между собой.
• С использованием компьютера можно провести анализ чувствительности для получения точного результата.

Практические рекомендации

Основные «подводные камни» и успешные практики системного анализа описаны в двух разделах ниже.

Подводные камни

Подводный камень Описание

Аналитическое моделирование – не инструмент принятия решений	Аналитическая модель предоставляет аналитический результат из анализированных данных. Ее следует рассматривать как помощь, но не как инструмент принятия решений.
Модели и уровни декомпозиции системы	Модель может быть хорошо адаптирована для энного уровня декомпозиции системы и несовместима с моделью более высокого уровня, которая использует данные дочерних уровней. Важно, чтобы системный инженер обеспечивал согласованность моделей на различных уровнях.
Оптимизация – это не сумма оптимизированных элементов	Общая оптимизация исследуемой системы – это не сумма оптимизации каждой ее части.

Источник: habr.com