Цена ошибок, допущенных в требованиях.

Исследования группы Стендиша (Standish Group) [1] свидетельствуют о следующем. В США ежегодно тратится более 250 миллиардов долларов на разработку прило­жений информационных технологий в рамках примерно 175 000 проектов. Средняя стоимость проекта составляет:

· для крупной компании — $2 322 000;

· для средней компании — $1 331 000;

· для мелкой компании — $434 000.

При этом 31 % проектов будет прекращен до за­вершения. Затраты на 52,7% проектов составят 189% от первоначальной оценки.

Исходя из этого, группа Стендиша оценивает, что американские компании и правительственные учреждения потратят 81 миллиард долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят допол­нительно 59 миллиардов долларов за программные проекты, которые хотя и завер­шатся, но значительно превысят первоначально отведенное на них время.

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

· успешные - завершенные срок и в рамках отведенного бюджета;

· проблемные – проекты, по которым возникла задержка или проекты, не оправдавшие ожи­даний;

· потерпевшие неудачу - прекращенные проекты.

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

· Недостаток исходной информации от клиента: 13% всех проектов.

· Неполные требования и спецификации: 12% проектов.

· Изменение требований и спецификаций: 12% всех проектов.

По остальным факторам (рис. 3.1), влияющим на успех проекта, данные сильно расходятся:

· проект потерпел неудачу из-за нереалистического подхода к составлению графика и выделению времени - 4% проектов,

· неправильный подбор персонала и выделения ре­сурсов - 6%,

· несоответствия технологических навыков (7%)

· по другим причинам.

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

Рисунок 3.1. Факторы, влияющие на провал проекта.

Хотя большинство проектов действительно превышают отведенное время и бюджет, если их вообще удается закончить, группа Стендиша обнаружила, что около 9% проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успеха удалось достигнуть в 16% проектов мелких компаний. Согласно проведенному исследованию тремя наиболее важными "факторами успеха" были названы следующие.

· Подключение к разработке пользователя: 16% всех успешных проектов.

· Поддержка со стороны исполнительного руководства: 14% всех успешных проектов.

· Ясная постановка требований: 12% всех успешных проектов.

Другие источники приводят даже более впечатляющие результаты. Например, орга­низация ESPITI (European Software Process Improvement Training Initiative — Европей­ская инициатива по обучению совершенствованию процесса программирования) прове­ла опрос с целью определить относительную важность различных типов су­ществующих в отрасли проблем. Двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие.

· Спецификации требований.

· Управление требованиями клиента.

Если бы ошибки требований можно было быстро, просто и экономно устранять, про­блема не была бы столь серьезна. Алан Дэвис (Davis) в своей работе [2] подвел итоги нескольких исследований и показал, что при обнаружении ошибок на стадии формирования требова­ний компания получает экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии сопровождения программы.

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

Одной из организаций, действительно работавшей над данным вопросом, является компания “Hughes Aircraft”. Исследование Снайдера (Snyder) [3] обнаружило явление "просачивания" дефектов во многих проектах, выполненных компанией на протяжении 15 лет. В данном исследовании говорится о том, что 74% дефек­тов, связанных с формированием требований, были обнаружены на этапе анализа требова­ний, когда клиенты совместно с системными аналитиками обсуждают, подвергают мозго­вому штурму, согласовывают и документируют требования к проекту. Этот этап работы над проектом является идеальным с точки зрения обнаружения таких ошибок с наименьшими затратами. Однако исследование также свидетельствует, что 4% дефектов "просачиваются" на этап предварительного (высокоуровневого) проектирования, а 7% — еще дальше, на этап детализированного проектирования. Невыявленные ошибочные требования жизненному циклу системы, и 4% ошибок требований оказываются не найденными вплоть до этапа сопровождения, когда система уже передана клиентам и счи­тается полностью работоспособной.

Таким образом, в зависимости от того, где и когда при работе над проектом разработ­ки программного приложения был обнаружен дефект, стоимость его устранения может разниться в 50-100 раз. Причина состоит в том, что для его исправления придется затратить средства на не­которые (или все) ниже перечисленные действия.

· Повторная спецификация.

· Повторное проектирование.

· Повторное кодирование.

· Повторное тестирование.

· Создание документации.

· Замена де­фектной версии исправленной.

· Списание части работы, которая оказалась ненужной.

· Выплаты по гарантийным обязательствам

Из сказанного выше можно сделать два вывода.

· Ошибки в определении требований являются наиболее распространенными.

· Стоимость устранения таких ошибок - одна из самых высоких.

Ошибки в определении требований приводят к затратам, составляю­щим 25-40% бюджета проекта разработки в целом. Учитывая частоту возникновения ошибок в определении требований и эффект умно­жения стоимости их устранения, легко предсказать, что эти ошибки обусловят до 70% затрат на повторную работу.

Пирамида типов требований

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

IEEE Standard Glossary of Software Engineering Terminology [14] определяет требования как

· условия или возможности, необходимые пользователю для решения проблем или достижения целей;

· условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Можно думать о требованиях, как о свойствах, которыми должен обладать продукт, чтобы представлять ценность для заинтересованных сторон. Следующее определение, данное Соммервиллем и Соером в работе [15] подтверждает различие типов требований:

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

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

Учитывая, что системе будут предъявлены сотни, если не тысячи, требований, очень важно организовать их.

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

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

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

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

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

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

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

Зачастую эти запросы формулируются представителями заинтересованных сторон неоднозначными и размыто. Например:

· Мне необходимо ускорение прохождения документов между мной и подчиненными удаленных подразделений.

· Мне необходимо улучшить обратную связь с клиентами компании.

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

· Мне бы хотелось, чтобы существенно возросло количество заказов на покупку.

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

Запрос заинтересованной стороны это отражение некой личной, рабочей или бизнес-проблемы (или возможности), ре­шение которой оправдывает замысел, покупку или использование новой системы.

Эти запросы образуют кластер, ко­торый можно представить в форме небольшой пирамиды (рис 3.2.).

Рисунок 3.2. Запросы заинтересованных сторон, образующие область проблемы.

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

Вместо этого заинтересованные стороны описывают некую абстракцию, что-то вроде:

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

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

· Необходимо, чтобы система формировала отчет, отражающий ежедневный приход товаров на склад.

· Необходимо реализовать заказ товаров через Интернет.

Эти высокоуровневые выражения желаемого поведения системы принято называть функ­циями (features) продукта или системы.

Функция — это предоставляемое системой обслуживание для удовлетворе­ния одной или нескольких, потребностей клиентов.

Следует отметить, что выявляемые таким образом функции часто не очень хорошо определены и могут даже противоречить друг другу, но так или иначе они являются отражением ре­альных потребностей. Это означает, что представитель заинтересованной стороны уже преобразовал реальную потреб­ность (производительность или безопасность) в поведение системы, которое, по его мнению, будет служить реальной потребности. При этом ответ на вопрос “Что мне нужно?" подменился ответом на вопрос "Что, по моему мнению, должна делать система, чтобы удовлетворить мою потребность". Это неплохо, поскольку представители заинтересованных сторон имеют реальный опыт в своей предметной области и реальное понимание значения функции. Кроме того, такие функции легко обсуждать и документировать на обычном языке, а также объяснять их другим, что существенно обогащает схему требований.

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

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

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

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

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

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

Рисунок 3.3. Функции и тре­бования к программному обеспечению, образующие область решения.

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

· При вводе в форме авторизации пароля, длина которого меньше 6 символов, система выдает сообщение, содержащее текст “….”

· При отсутствии данных, вводимых пользователем в обязательном поле “Имя”, система должна повторно предъявить заполняемую форму, установив курсор в пустое поле и указать на ошибку “…”.

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

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

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

Структура процесса, реализуемого в рамках дисциплины управления требованиями, представлена на рис. 3.4.

Рисунок 3.4. Структура потока работ управления требованиями.

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

Большинство систем создается для решения определенной проблемы. Чтобы правильно понять, в чем состоит проблема, следует использовать метод анализа проблем. Для этого необходимо выполнить пять шагов.

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

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

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

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

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

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

Анализ проблемы - это процесс осознания реальных проблем и потребностей пользователя и предложения решений для удовлетворения этих потребностей.

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

Чтобы иметь возможность провести анализ проблемы, полезно определить, что же собой представляет проблема.

Проблема - это разница между желаемым и воспринимаемым[4].

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3.5. Диаграмма, отображающая корневые причины.

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

Естественным желанием инженера является устранить все корневые причины. Однако, многие корневые причины просто не стоят того, чтобы их устранять, поскольку затраты на их устранение превысят причиняемый про­блемой ущерб. Для этого необходимо определить влияние каждой корневой причины. Результат этого исследования можно отобразить в виде Парето-диаграммы, визуально отражающей реальные источники проблемы. Предположим, что в результате сбора данных для приведенного примера получены результаты, приведенные на рис. 3.6.

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

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

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

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

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

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

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

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

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

· Вторую категорию составляют непрямые пользователи, а также те, на кого воздействуют только бизнес-последствия разработки. Представителей этих заинтересованных сторон можно найти в соответствующей бизнес-области или в «окрестностях» среды кон­кретного приложения.

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

Каждая из перечис­ленных категорий заинтересованных сторон может оказывать влияние на требования к сис­теме или будет каким-либо образом связана с результатом ее работы.

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

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

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

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

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

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

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

· Кого еще можно выявить в качестве заинтересованных сторон?

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

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

Таблица 3.3. Заинтересованные стороны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.4. Источники ограничений, налагаемых на систему.

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

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

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

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

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

Таким образом, к результатам корректно выполненного этапа анализа проблемы можно отнести следующее.

· Полное понимание решаемой проблемы и лежащих в ее основе причин.

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

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

· Осознание существующих ограничений и степени свободы, которой команда разработчиков обладает при решении проблемы.