- PVSM.RU - https://www.pvsm.ru -
Системный анализ обеспечивает строгий подход к технике принятия решений. Он используется для исследования альтернатив и включает моделирование и имитацию, анализ затрат, анализ технических рисков и анализ эффективности.
В отличие от SWEBoK , SEBoK распространен в России намного меньше. По крайней мере при подготовке учебного курса для магистратуры, найти хоть каких-то переводов его статей мне не удалось. А тем не менее, книга структурирует очень полезные и пока что разрозненные знания в области разработки больших систем и, в том числе, системного анализа.
Так как мой курс касался именно системного анализа, под катом будет перевод этой главы SEBoK… Но это всего несколько глав одного из 7 разделов книги.
P.S. Буду благодарен за комментарии и Ваше мнение об этой статье (качестве, необходимости) и об интересе к системному анализу и системной инженерии.
Одна из основных задач системной инженерии является оценка результатов, полученных в результате ее процессов. Сравнение, проведение оценки – это центральный объект системного анализа, обеспечивающего необходимые техники и средства для:
Процесс анализа и выбора между альтернативными решениями выявленной проблемы/возможности описывается во 2 разделе SEBoK (глава Системный подход в проектировании систем [1]). Определим основные принципы системного анализа:
Примечание: «Мягкое»/«нестрогое» и «строгое» описание системы отличается возможностью четко определить цели, задачи и миссию системы (для «мягких» систем это зачастую сделать крайне сложно).
Примечание: В нашей литературе чаще встречается термин «Анализ альтернатив» или «Оценка альтернатив»
В контексте описания системы, исследование компромиссов состоит из сравнения характеристик каждого элемента системы и каждого варианта архитектуры систем для определения решения, в целом наиболее подходящего по оцениваемым критериям. Анализ различных характеристик выполняется в процессах анализа затрат, анализа рисков, и анализа эффективности. С точки зрения системной инженерии эти три процесса будут рассматриваться более подробно.
Все методы анализа должны использовать общие правила:
Процесс принятия решений – это не точная наука, поэтому исследование альтернатив имеет свои ограничения. Необходимо принимать во внимание следующие проблемы:
Тщательно проведенное исследование компромиссов определяет допустимые значения результатов.
Анализ эффективности отталкивается от контекста использования системы или проблемы.
Эффективность решения определяется исходя из выполнения основных и дополнительных функций системы, которые выявляются исходя удовлетворения требований стейкхолдеров. Для продуктов, это будет набор общих нефункциональных качеств, например: безопасность, защищенность, надежность, ремонтопригодность, удобство использования и т.д. Эти критерии часто точно описаны в смежных технических дисциплинах и сферах. Для услуг или организаций, критерии могут быть больше связаны с определением потребностей пользователей или целей организации. Типичные характеристики таких систем включают устойчивость, гибкость, возможность развития и т.д.
В дополнение к оценке абсолютной эффективности решения, необходимо также учитывать ограничения по затратам и времени реализации. В целом, роль системного анализа сводится к выявлению решений, которые могут обеспечить эффективность в какой-то мере с учетом затрат и времени выделенных для каждой заданной итерации.
Если ни одно из решений не может предоставить уровень эффективности, оправдывающий предполагаемые инвестиции, тогда необходимо вернуться к первоначальному состоянию проблемы. Если хотя бы один из вариантов показывает достаточную эффективность, тогда может выполняться выбор.
Эффективность решения включает несколько существенных характеристик (но не ограничивается): производительность, удобство использования, надежность, производство, обслуживание и поддержку, и т.д. Анализ в каждом из этих направлений выделяет предложенные решения с точки зрения различных аспектов.
Важно установить классификацию важности аспектов для анализа эффективности, т.н. ключевые показатели производительности. Основная сложность анализа эффективности – правильно отсортировать и выбрать набор аспектов, в точки зрения которых оценивается эффективность. Например, если продукт выпускается для одноразового использования, ремонтопригодность не будет подходящим критерием.
Анализ затрат рассматривает затраты полного жизненного цикла. Базовый набор типовых расходов может изменяться для конкретного проекта и системы. В структуру затрат могут входить как трудовые затраты (на оплату труда), так и не трудовые.
Тип | Описание и пример |
---|---|
Разработка | Проектирование, разработка инструментов (оборудование и программное обеспечение), управление проектом, тестирование, макетирование и прототипирование, обучение и т.д. |
Производство продукта или оказание услуги | Сырье и поставки, запасные части и складской запас, необходимые для работы ресурсы (вода, электричество и т.д.), риски, эвакуация, переработка и хранение отходов или брака, административные расходы (на налоги, администрацию, документооборот, контроль качества, уборку, контроль и т.д.), упаковка и хранение, необходимая документация. |
Продажи и постпродажное обслуживание | Расходы на сеть продаж (филиалы, магазины, сервисные центры, дистрибьюторов, получение информации и т.д.), работу с жалобами и обеспечение гарантии и т.д. |
Использование у клиентов | Налоги, установка (у заказчика), необходимые для работы ресурсы (вода, топливо и т.д.), финансовые риски и т.д. |
Поставки | Транспортировка и доставка |
Обслуживание | Сервисные центры и выезды, профилактика, контроль, запасный части, затраты на гарантийное обслуживание и т.д. |
Удаление | Сворачивание, демонтаж, транспорт, уничтожение отходов и т.д. |
Методы определения стоимости затрат описываются в разделе «Планирование» [3] (раздел 3).
Риск – потенциальная неспособность к достижению целей в рамках определенных затрат, графика и технических ограничений. Состоит из двух частей:
Каждый риск имеет вероятность больше 0 и меньше 1, степень влияния больше 0 и сроки в будущем. В случае, если вероятность равна 0 – риска нет, если равна 1 – это уже факт, а не риск; если степень влияния равна 0 — риска нет, т.к. нет никаких последствий его возникновения (можно игнорировать); если сроки не в будущем – значит это уже свершившийся факт.
Анализ рисков в любой сфере основан на трех факторах:
Технические риски реализуются, когда система перестает удовлетворять требованиям к ней. Причины этого находятся либо в требованиях, либо в самом решении. Они выражаются в виде недостаточной эффективности и могут иметь несколько причин:
Технические риски не должны смешиваться с проектными рисками, хотя и методы управления ими совпадают. Не смотря на то, что технические риски могут приводить к проектным рискам, они ориентированы на саму систему, а не на процесс ее разработки (подробнее описано в главе «Управление рисками» раздела 3).
Процесс системного анализа используется для:
Этот процесс был также назван процессом анализа решений (NASA, 2007) и использовался для оценки технических задач, альтернативных решений и их неопределенности для принятия решений. Подробнее в главе «Управление решениями» (раздел 3).
Системный анализ поддерживает другие процессы описания системы:
Как и любой процесс описания системы, системный анализ – повторяющийся. Каждая операция выполняется несколько раз, каждый шаг улучшает точность анализа.
Основные виды деятельности и задачи в рамках этого процесса включают:
В рамках процесса создаются такие артефакты, как:
В процессе используются термины, перечисленные в таблице ниже.
Термин | Описание |
---|---|
Критерий оценки | В контексте системного анализа, критерий оценки – характеристика, используемая для сравнения элементов системы, физической архитектуры, функциональных сценариев и других элементов, которые могут сравниваться. Включает: идентификатор, название, описание, вес. |
Оценочный выбор | Управление элементами системы, на основе оценочного балла, который объясняет выбор элементов системы, физической архитектуры или сценария использования. |
Оценочный балл (оценка) | Оценочный балл получают элементы системы, физической архитектуры, функциональных сценариев используя набор критериев оценки. Включает: идентификатор, название, описание, значение. |
Затраты | Значение в выбранной валюте, связанное со значением элемента системы и т.д. Включает: идентификатор, название, описание, сумма, тип затрат (разработка, производство, использование, обслуживание, утилизация), метод оценки, период действия. |
Риск | Событие, которое может произойти и повлиять на цели системы или ее отдельные характеристики (технические риски). Включает: идентификатор, название, описание, статус. |
Для получения проверенных результатов, необходимо обеспечить выполнение следующих пунктов:
Наиболее часто используемые аналитические модели в рамках системного анализа приведены в таблице.
Тип модели | Описание |
---|---|
Детерминированные (определенные) модели | Детерминированной называется модель, которая не зависит от теории вероятности.
|
Стохастические (вероятностные) модели | Если в модели среди величин имеются случайные, т.е. определяемые лишь некоторыми вероятностными характеристиками, то модель называется стохастической (вероятностной, случайной). В этом случае и все результаты, полученные при рассмотрении модели, имеют стохастический характер и должны быть соответственно интерпретированы. Теория вероятности позволяет классифицировать возможные решения как следствие множества событий. Эти модели применимы для ограниченного числа событий с простыми комбинациями возможных вариантов. |
Многокритериальные модели | Если критериев больше 10, рекомендуется использовать многокритериальные модели. Они получаются в результате следующих действий:
|
Основные «подводные камни» и успешные практики системного анализа описаны в двух разделах ниже.
Подводный камень | Описание |
---|---|
Аналитическое моделирование – не инструмент принятия решений | Аналитическая модель предоставляет аналитический результат из анализированных данных. Ее следует рассматривать как помощь, но не как инструмент принятия решений. |
Модели и уровни декомпозиции системы | Модель может быть хорошо адаптирована для энного уровня декомпозиции системы и несовместима с моделью более высокого уровня, которая использует данные дочерних уровней. Важно, чтобы системный инженер обеспечивал согласованность моделей на различных уровнях. |
Оптимизация – это не сумма оптимизированных элементов | Общая оптимизация исследуемой системы – это не сумма оптимизации каждой ее части. |
Методика | Описание |
---|---|
Оставаться в оперативном поле | Модели никогда не смогут показать все поведение и реакцию системы: они работают в ограниченном пространстве с узким набором переменных. Используя модель, всегда необходимо убедиться, что входные данные и параметры являются частью операционного поля. Иначе есть высокий риск неправильных результатов. |
Развивайте модели | Модели должны развиваться на протяжении проекта: путем изменения настроек параметров, вводя новые данные (изменение критериев оценки, выполняемых функций, требований и т.д.), и путем использования новых инструментов, когда предыдущие достигают предела своих возможностей. |
Используйте несколько типов моделей | Рекомендуется одновременно использовать несколько различных типов моделей для сравнения результатов и учета других аспектов системы. |
Поддерживайте согласованность элементов контекста | Результаты моделирования всегда получаются в рамках контекста моделирования: используемых инструментов, допущений, введенных параметров и данных, и разброса выходных значений. |
Автор: Kettariecz
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-i-proektirovanie-sistem/84390
Ссылки в тексте:
[1] Системный подход в проектировании систем: http://sebokwiki.org/wiki/Systems_Approach_Applied_to_Engineered_Systems
[2] «Системная инженерия и специальное проектирование»: http://sebokwiki.org/wiki/Systems_Engineering_and_Specialty_Engineering
[3] «Планирование»: http://sebokwiki.org/wiki/Planning
[4] Источник: http://habrahabr.ru/post/251831/
Нажмите здесь для печати.