Цель анализа проблемы состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки

Для этого необходимо осуществить следующие пять этапов.

1. Достигнуть соглашения об определении проблемы.

2. Выделить основные причины — проблемы, стоящие за проблемой.

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

4. Определить границу системы решения.

5. Выявить ограничения, которые необходимо наложить на решение.

Давайте подробно рассмотрим каждый их этих этапов.

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

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

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

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

Часто бывает полезно записать проблему в стандартной форме (табл. 1). Создание подобной таблицы является простым, недейственным средством, чтобы удостовериться в том, что все участники проекта работают вместе над осуществлением общей цели.

Таблица 1. Стандартная форма постановки проблемы

Элемент	Описание
Проблема воздействует на результатом чего является Выигрыш от может состоять в следующем	[Описание проблемы] [Указание лиц, на которых оказывает влияние данная проблема] [Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность] [Указание предлагаемого решения] [Список основных предоставляемых решением преимуществ]

Может показаться, что достижение согласия относительно определения решаемой проблемы — шаг небольшой и малозначащий, и чаще всего так оно и есть. Но не всегда. Например, один из наших клиентов, производитель оборудования, занялся усовершен­ствованием своей IS/IT-системы, обеспечивающей пересылку счетов и финансовых от­четов между компанией и ее дилерами. Задачей новой программы было "улучшить сред­ства коммуникации дилеров". В свете этого команда приготовилась разрабатывать новую масштабную систему. Данный пример достижения соглашения о решаемой проблеме весьма показателен. Предложенное командой определение решения предполагало созда­ние мощной новой системы, предусматривающей улучшенную финансовую отчетность, усовершенствованные формы счетов и отчетов, возможность заказа запчастей в интерак­тивном режиме и электронную почту. Помимо этого, команда надеялась (если получится) обеспечить возможность электронного перевода средств между компанией и дилером.

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

2. Выделение основных причин — проблем, стоящих за проблемой

Для понимания реальной проблемы и ее причин можно использовать множество ме­тодов. Одним из них является метод анализа корневых причин (root cause analysis), пред­ставляющий собой семантический способ нахождения причин, лежащих в основе рас- сматриваемой проблемы или ее проявления.

Рассмотрим реальный пример.

Компания GoodsAreUs, занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных на­именований. Решив заняться проблемой недостаточной прибыльности, компания ис­пользует рекомендуемую ее программой обеспечения качества методику "качество — во всем" (total quality management, TQM). Применив данный подход, компания практиче­ски сразу обратила внимание на ущерб от несоответствия (cost of nonconformance), который представляет собой стоимость всего, что идет не так, как надо, и приводит к бесполез­ным затратам. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущерб от не­соответствия, компания заподозрила, что наибольший вклад в него вносят "остатки".

Следующим шагом должно стать определение того, какие факторы оказывают влия­ние на величину остатков. TQM советует для обнаружения проблем, стоящих за пробле­мой, использовать диаграмму в форме рыбного скелета (рис. 4.1). В нашем случае компа­ния выявила много источников, вносящих свой вклад в остатки. Каждый источник ука­зан как одна из "косточек" на диаграмме.

Рис. 3. Диаграмма в форме рыбного скелета для отображения корневых причин

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

Но если проблема более серьезна, простого опроса сотрудников недостаточно. Может понадобиться произвести детальное исследование каждой из перечисленных проблем и количественно определить вклад каждой в отдельности. Этого можно добиться как по­средством "мозгового штурма" с участием тех, кто знаком с данной областью, так и с по­мощью небольшого проекта по сбору данных или, возможно, более строгого научного ис­следования. В любом случае цель состоит в том, чтобы количественно оценить вероят­ный вклад каждой корневой причины.

Устранение корневых причин

Качественные данные свидетельствуют, что многие корневые причины не стоят того, чтобы их устранять.

Конечно, инженер в каждом из нас захочет устранить все корневые причины на "косточках" диаграммы. Кажется, что это правильно. Но так ли это? Зачастую — нет. Ка­чественные данные свидетельствуют, что многие корневые причины просто не стоят того, чтобы их устранять, поскольку затраты на их устранение превысят причиняемый про­блемой ущерб. Как же узнать, какие из них устранять? Ответ: необходимо определить влияние каждой корневой причины. Результат этого исследования можно отобразить в виде Парето-диаграммы, визуально отражающей реальных "виновников".

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

Рис. 4. Парето-диаграмма корневых причин

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

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

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

Таблица 2. Постановка проблемы ввода заказов на покупку

Элементы

Описание

Проблема воздействует на результатом чего является Выигрыш от

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

После написания постановки проблемы, ее следует передать для ознакомления заказ­чикам и заинтересованным лицам, чтобы они внесли свои комментарии. Затем поста­новка проблемы доводится до сведения всех членов команды разработчиков с тем, чтобы все работали в направлении достижения общей цели.

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

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

Заинтересованные лица - это все, на кого реализация новой системы или при­ложения может оказать материальное воздействие.

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

Первая категория заинтересованных лиц — это пользователи системы. Их потребно­сти легко учесть, поскольку они будут непосредственно привлекаться к определению и использованию системы.

Вторую категорию составляют непрямые пользователи, а также те, на кого воздействуют только бизнес - последствия разработки. Этих заинтересованных лиц можно найти в соответствующей бизнес - области или в "окрестностях" среды кон­кретного приложения.

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

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

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

• Кто является пользователями системы?

• Кто является заказчиком (экономическим покупателем) системы?

• На кого еще окажут влияние результаты работы системы?

• Кто будет оценивать и принимать систему, когда она будет представлена и развернута?

• Существуют ли другие внутренние или внешние пользователи системы, чьи по­требности необходимо учесть?

• Кто будет заниматься сопровождением новой системы?

• Не забыли ли мы кого-нибудь?

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

Пользователи	Другие заинтересованные лица
Служащие, занимающиеся вводом заказов Руководитель отдела приема заказов Контроль производства Служащий, выписывающий счета	Администратор информационной системы и команда разработчиков Главный финансист Управляющий производством

4.Определение границ системы - решения

После того как согласована постановка проблемы и выявлены пользователи и заинте­ресованные лица, можно перейти к определению системы, разрабатываемой для решения данной проблемы. Это важный момент, когда необходимо постоянно помнить как о по­нимании проблемы, так и о свойствах потенциального решения.

Следующий важный этап состоит в том, чтобы определить границы системы-решения. Границы системы — это "водораздел" между решением и окружающим его ре­альным миром (рис. 1) Иными словами, граница системы описывает оболочку, в кото­рой заключена система. Информация в виде ввода и вывода передается от находящихся вне системы пользователей системе и обратно. Все взаимодействия с системой осуществ­ляются посредством интерфейсов между системой и внешним миром.

Рис. 1. Отношение вход/система/выход

Мы делим мир на две части. 1. Наша система 2. То, что взаимодействует с нашей системой

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

• Наша система

• То, что взаимодействует с нашей системой

Определим "то, что взаимодействует с нашей системой", общим понятием "акторы" (actors). Они выполняют некоторые действия, заставляя систему делать ее работу. Актор изображается простой пиктограммой в виде человечка. Его определение выглядят сле-дующим образом.

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

С помощью данного понятия мы можем проиллюстрировать границы системы (рис. 2).

Рис. 2. Границы системы

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

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

Ана­литик должен определить, будут ли данные использоваться совместно с другими прило­жениями, должно ли новое приложение распределяться по разным хостам и клиентам, а также кто будет пользователем. Например, должен ли персонал, занятый в производстве, иметь интерактивный доступ к заказам на покупку? Обеспечивается ли контроль качества или функции аудита? Будет ли система выполняться на компьютере-мэйнфрейме или на новом компьютере-клиенте? Должны ли предоставляться специальные отчеты?

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

• Кто будет поставлять, использовать или удалять информацию из системы?

• Кто будет управлять системой?

• Кто будет осуществлять сопровождение системы?

• Где будет использоваться система?

• Откуда система получает информацию?

• Какие внешние системы будут взаимодействовать с системой?

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

Рис. 3. Система, и ее окружение

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

1. Выявление ограничений, налагаемых на решение

Ограничения уменьшают степень свободы, которой мы располагаем при предложении решения.

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

Каждое ограничение может значительно сузить нашу возможность создать предпола­гаемое решение. Следовательно, в процессе планирования необходимо тщательно изу­чить все ограничения. Многие из них могут даже заставить нас пересмотреть изначально предполагавшийся технологический подход.

Необходимо учитывать, что существуют различные источники ограничений (экономические, технические, политические и т.д.). Ограничения могут быть заданы еще до начала работы ("Никакой новой аппаратуры!"), но может получиться, что нам действительно придется их выявлять.

Чтобы их выявить, полезно знать, на что следует обратить внимание. В табл. 4 ука­заны возможные источники системных ограничений. Перечисленные в таблице вопросы помогут выявить большую часть ограничений. Часто полезно получить объяснение огра­ничения, как для того, чтобы убедиться, что вы поняли его назначение, так и для того, чтобы можно было обнаружить (если такое произойдет), что данное ограничение боль­ше не применимо к вашему решению.

Таблица 4. Возможные источники ограничений системы

Источник	Образцы вопросов
Экономический	• Какие финансовые или бюджетные ограничения следует учесть? • Существуют ли соображения, касающиеся себестоимости и цено­образования? • Существуют ли вопросы лицензирования?
Политический	• Существуют ли внешние или внутренние политические вопросы, влияющие на потенциальное решение? • Существуют ли проблемы в отношениях между подразделениями?
Технический	• Существуют ли ограничения в выборе технологий? • Должны ли мы работать в рамках существующих платформ или тех­нологий? • Запрещено ли использование любых новых технологий? • Должны ли мы использовать какие-либо закупаемые пакеты про­граммного обеспечения?
Системный	• Будет ли решение создаваться для наших существующих систем? • Должны ли мы обеспечивать совместимость с существующими решениями? • Какие операционные системы и среды должны поддерживаться?
Эксплуатационный	• Существуют ли ограничения информационной среды или правовые ограничения? • Юридические ограничения? • Требования безопасности? • Какими другими стандартами мы ограничены?
График и ресурсы	• Определен ли график? • Ограничены ли мы существующими ресурсами? • Можем ли мы привлекать работников со стороны? • Можем ли мы увеличить штат? Временно? Постоянно?

После того как ограничения выявлены, некоторые из них станут требованиями к новой системе ("использовать MRP-систему, предлагаемую поставщиком нашей ны­нешней системы учета"). Другие ограничения будут оказывать влияние на ресурсы и планы реализации. Именно при анализе проблемы необходимо выявить потенци­альные источники ограничений и понять, какое влияние каждое ограничение ока­жет на область возможных решений.

Возвратимся к нашему примеру. Ограничения, которые могут налагаться на новую систему ввода заказов на покупку, представлены в табл. 5.

Таблица 5. Ограничения, налагаемые на систему ввода заказов на покупку

Источник	Ограничение	Объяснение
Эксплуатационный	Копия данных заказа на покупку должна оставаться в унаследованной базе данных в течение одного года	Риск потери данных слишком вы­сок; нам необходимо работать па­раллельно в течение года
Системы и операци­онные системы	Приложение должно занимать на сервере не более 20 мегабайт	Количество доступной памяти сер­вера ограничено
Средства, выделен­ные на оборудование	Система должна быть разработана на существующем сервере или хосте; можно предложить новое кли­ентское аппаратное обеспечение для пользователей	Сокращение издержек и поддержка существующих систем
Средства, выделен­ные на оплату труда персонала	Фиксированный штат, не привле­кать работников со стороны	Фиксированные расходы на зарплату по отношению к текущему бюджету
Технологические требования	Должна использоваться новая объектно-ориентированная мето­дология	Мы надеемся, что эта технология по­высит производительность и надеж­ность программного обеспечения

Пример

Диаграмма 1. Причины низкой надежности разрабатываемых программных продуктов.

Диаграмма 2. Соотношение факторов, снижающих надежность разрабатываемых программных продуктов.

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