Анализ проблемы и моделирование предметной области с использованием системного подхода

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

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

Анализ проблем
Анализ проблем – это процесс осознания реальных проблем и потребностей пользователей и предложения решений, позволяющих удовлетворить эти потребности.
Цель анализа проблемы состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки.
Выявление актантов системы является ключевым шагом в анализе проблемы.
При этом необходимо проанализировать и понять область проблемы и исследовать разнообразные области решений.
По определению Гауса и Вайнберга (Cause,Weinberg, 1989) проблема - это разница между желаемым и воспринимаемым.

Этапы для анализа проблемы

Этап 1. Достижение соглашения об определении проблемы
Стандартная форма постановки проблемы

Этап 2. Выделение основных причин – проблем, стоящих за проблемой
Анализ корневых причин, представляющий собой семантический способ нахождения причин, лежащих в основе рассматриваемой проблемы или ее проявления.
Рассмотрим реальный пример. Компания GoodsAreUs, занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных наименований. Применяет методику "качество – во всем". Обращает внимание на ущерб от несоответствия. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущерб от несоответствия, компания заподозрила, что наибольший вклад в него вносят "остатки".
Следующим шагом должно стать определение того, какие факторы оказывают влияние на величину остатков. TQM советует для обнаружения проблем, стоящих за проблемой, использовать диаграмму в форме рыбного скелета. В нашем случае компания выявила много источников, вносящих свой вклад в остатки. Каждый источник указан как одна из "косточек" на диаграмме.

Способы выявления коневых причин
Способ выявления корневых причин зависит от конкретного случая. Существует несколько способов выявления причин:

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

Постановка проблемы ввода заказов на покупку

Этап 3. Выявление заинтересованных лиц и пользователей
Заинтересованные лица – это все, на кого реализация новой системы или приложения может оказать материальное воздействие.
Первая категория заинтересованных лиц – это пользователи системы. Их потребности легко учесть, поскольку они будут непосредственно привлекаться к определению и использованию системы.
Вторую категорию составляют непрямые пользователи, а также те, на кого воздействуют только бизнес-последствия разработки и те, кто воздействует на разработку. Потребности заинтересованных лиц, не являющихся пользователями, также необходимо выявить и учесть.

Выявление заинтересованных лиц и пользователей

Пользователи и лица, заинтересованные в новой системе

Этап 4. Определение границ системы-решения
Переходим к определению системы, разрабатываемой для решения данной проблемы.
Граница системы описывает оболочку, в которой заключена система. Информация в виде ввода и вывода передается от находящихся вне системы пользователей системе и обратно. Все взаимодействия с системой осуществляются посредством интерфейсов между системой и внешним миром.
Делим мир на два интересующих нас класса.
Наша система.
То, что взаимодействует с нашей системой.

Актант
Актант - это находящееся вне системы нечто (или некто), взаимодействующее с системой.

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

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