41405

Управление требованиями. Объектно-ориентированный анализ и проектирование

Лекция

Информатика, кибернетика и программирование

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

Русский

2013-10-24

240 KB

0 чел.

Лекция N 1 30/10/02

Объектно-ориентированный анализ и проектирование

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

1. Проблема требований

  1.  Цель
    1.  Статистика
    2.  Основные причины успеха и провала проектов
    3.  Высокая цена ошибок требований

2. Введение в управление требованиями

2.1. Определения

2.2. Подход к управлению требованиями

3. Команда разработчиков

3.1. Разработка программного обеспечения как командная деятельность

3.2. Профессиональные навыки, которыми должна обладать команда для эффективного управления требованиями

3.3. Организация команд, разрабатывающих программное обеспечение

4. Анализ проблемы

4.1. Пять этапов анализа проблемы

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

Лекция N 2 12/11/02

Объектно-ориентированный анализ и проектирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользователи

Другие заинтересованные лица

Служащие, занимающиеся вводом заказов

Руководитель отдела приема заказов

Контроль производства Служащий, выписывающий счета

Администратор информационной системы и команда разработчиков

Главный финансист

Управляющий производством

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

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

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

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

Мы делим мир на две части.

1. Наша система

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Образцы вопросов

Экономический

• Какие финансовые или бюджетные ограничения следует учесть?

• Существуют ли соображения, касающиеся себестоимости и ценообразования?

• Существуют ли вопросы лицензирования?

Политический

• Существуют ли внешние или внутренние политические вопросы, влияющие на потенциальное решение?

• Существуют ли проблемы в отношениях между подразделениями?

Технический

• Существуют ли ограничения в выборе технологий?

• Должны ли мы работать в рамках существующих платформ или технологий?

• Запрещено ли использование любых новых технологий? • Должны ли мы использовать какие-либо закупаемые пакеты программного обеспечения?

Системный

• Будет ли решение создаваться для наших существующих систем?

• Должны ли мы обеспечивать совместимость с существующими решениями?

• Какие операционные системы и среды должны поддерживаться?

Эксплуатационный

• Существуют ли ограничения информационной среды или правовые ограничения?

• Юридические ограничения?

• Требования безопасности?

• Какими другими стандартами мы ограничены?

График и ресурсы

• Определен ли график?

• Ограничены ли мы существующими ресурсами?

• Можем ли мы привлекать работников со стороны?

• Можем ли мы увеличить штат? Временно? Постоянно?

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

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

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

Источник

Ограничение

Объяснение

Эксплуатационный

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

Риск потери данных слишком высок; нам необходимо работать параллельно в течение года

Системы и операционные системы

Приложение должно занимать на сервере не более 20 мегабайт

Количество доступной памяти сервера ограничено

Средства, выделенные на оборудование

Система должна быть разработана на существующем сервере или хосте; можно предложить новое клиентское аппаратное обеспечение для пользователей

Сокращение издержек и поддержка существующих систем

Средства, выделенные на оплату труда персонала

Фиксированный штат, не привлекать работников со стороны

Фиксированные расходы на зарплату по отношению к текущему бюджету

Технологические

требования

Должна использоваться новая

объектно-ориентированная методология

Мы надеемся, что эта технология повысит производительность и надежность программного обеспечения

  1.  Моделирование бизнес – процессов

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

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

В среде IS/IT полезно иметь метод, с помощью которого можно ответить на следующие вопросы:

• Зачем вообще создается система?

• Где она должна размещаться?

• Как определить, какие функциональные возможности лучше всего разместить в отдельно взятой системе?

• Когда следует применять этапы ручной обработки?

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

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

5.1. Цели моделирования бизнес-процесса

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

В любом случае цель бизнес - моделирования двояка.

• Разобраться в структуре и динамике организации

• Удостовериться в том, что заказчики, конечные пользователи и разработчики имеют одинаковое понимание организации

Бизнес-моделирование дает команде возможность понять, где приложения программного обеспечения могут улучшить производительность данного предприятия, и помогает определить требования к этим приложениям.

5.2. Использование методов инженерии программного обеспечения для моделирования бизнес - процессов

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

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

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

5.3. Унифицированный язык моделирования (UML)

Моделирование бизнес-процесса с использованием концепций UML

Одной из целей моделирования бизнес-процесса является создание такой его модели, которой можно руководствоваться при разработке приложения. Для этого можно использовать две основные модельные конструкции: модель прецедентов бизнес-процесса (business use-case model) и модель объектов бизнес-процесса (business object model).               

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

Рис. 4. Модель прецедентов бизнес-процесса

Акторы в модели прецедентов бизнес-процесса представляют внешние по отношению к бизнес-единице роли (например, служащие и клиенты), а прецеденты представляют процессы. Приведем несколько примеров прецедентов бизнес-процесса.

• Предоставление служащему электронной версии расчетного листа.

• Встреча с заказчиком для согласования сроков контракта. Ниже перечислены возможные акторы бизнес-процесса.

1. Клиент

2. Служащий

3. Разработчик программного обеспечения

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

Рис. 5. Модель объектов бизнес-процесса

Модель объектов бизнес-процесса также включает в себя реализации прецедентов бизнес-процесса, которые показывают, как эти прецеденты "осуществляются" при взаимодействии сотрудников и сущностей бизнес-процесса. Чтобы отразить существование в организации групп или подразделений, можно сгруппировать сотрудников и бизнес-сущности в организационные единицы.

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

От моделей бизнес-процесса к модели системы

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

Преобразование одной модели в другую можно кратко описать следующим образом.

• Сотрудники предприятия становятся акторами разрабатываемой системы.

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

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

Рис. 6. Модели бизнес-процесса и системы

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

Когда использовать моделирование бизнес-процесса

Моделирование бизнес-процесса не является универсальным методом, который мы рекомендуем применять в процессе каждой разработки программного обеспечения. Бизнес-модели, в основном, нужны в сложной многомерной прикладной среде, когда множество людей непосредственно вовлекаются в использование системы. Например, при создании дополнительной функции для существующего телекоммуникационного коммутатора моделировать бизнес-процесс не понадобится. Но при создании системы ввода заказов для компании GoodsAreUs моделирование бизнес-процесса позволит получить определенные преимущества при проведении анализа проблемы.

  1.  Инженерия систем, интенсивно использующих программное обеспечение

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

Этим и занимается системная инженерия (системное проектирование - system engineering).

Принципы

• Знание проблемы, клиента и потребителя.

• Использование основанных на потребностях критериев эффективности для принятия системных решений.

• Задание требований и управление ими.

• Выявление и оценка альтернатив при выработке решения.

• Верификация и проверка правильности требований, а также функционирования  решения.

• Обеспечение целостности системы.

• Использование согласованного и документированного процесса.

• Организация действий согласно плану.

Декомпозиция сложных систем

С помощью процесса декомпозиции сложная проблема (система) разбивается на две меньшие проблемы — подсистемы (рис. 7). Эти подсистемы можно обсудить, спроектировать и изготовить, а затем объединить и получить систему, являющуюся решением.

Рис. 7. Декомпозиция  системы

Рис. 8. Подсистема, состоящая из двух подсистем

Иногда создается совершенно новый тип требований, предъявляемых к подсистемам — производные требования. Как правило, существует два класса производных требований.

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

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

Рис. 9. Интерфейс между двумя подсистемами

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

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

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

Как сделать систему работоспособной

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

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

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

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

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

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

 

Рис. 10. Система электронного управления домом, ее подсистемы и акторы

  1.  Задача выявления требований

Среди причин возникновения проблем в проектах чаще всего упоминается "недостаток информации от пользователя". (Исследование группы Стендиша, 1994)

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

  1.  Преграды на пути выявления требований

Синдром "да, но..."

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

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

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

• "Да, но, как насчет...? Нельзя ли было бы...? А что будет, если...?"

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

Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что вы подразумеваете, когда описываете ее. И вот теперь она перед ними— впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали!

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

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

Синдром "неоткрытых руин"

Один из наших друзей однажды был экскурсоводом на автобусном маршруте в районе Four Corners, области, определенной общими границами штатов Колорадо, Нью-Мексико, Юта и Аризона. Экскурсия проходила по живописным вершинам горной цепи Ла-Плата, античным руинам Анасази в Меса-Верде и окрестностям. Вопросы туристов являются постоянным источником развлечения для экскурсоводов и создают определенный фольклор туристического бизнеса. У нашего друга самым любимым "дурацким" вопросом был "А сколько здесь неоткрытых руин?".  

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

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

Синдром "пользователя и разработчика"

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

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

Иногда мы должны учиться более эффективно общаться с этими "пользователями из другого мира". В своей статье Лора Шерер (Laura Scharer, 1981) описывает эту проблему и предлагает некие рекомендации по ее смягчению. В табл.6  представлены некоторые аспекты данной проблемы и предлагаемые решения.

Таблица 6. Синдром "пользователь и разработчик" Проблема                             

 

Проблема

Решение

Пользователи не знают, чего хотят, а если и знают, то не могут это выразить.

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

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

Все считают, что другие руководствуются политическими мотивами

Признавать пользователя экспертом в предметной области и ценить его в этом качестве; пытаться использовать альтернативные методы общения и выявления требований.

Как можно раньше предлагать альтернативные методы выявления: раскадровку, ролевые игры, прототипы и т.п.

Поставить аналитика на место пользователя. Провести ролевую игру в течение часа или всего дня

Такова человеческая натура, поэтому пусть все остается как есть

  1.  Функции продукта или системы

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

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

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

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

  1.  Функции

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

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

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

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

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

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

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

Ранее мы определили функцию следующим образом.

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

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

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

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

Таблица 7. Примеры функций

Прикладная область

Пример функции

Система управления элеватором

Система управления запасами

Система обнаружения неисправностей

Осуществляемое вручную управление дверью при угрозе пожара

Предоставлять свежую информацию о состоянии всех инвентарных единиц

Обеспечивать текущие данные для оценки качества продукции

Система обработки платежных ведомостей

Автоматическая система домашнего освещения (HOLIS)

Система контроля вооружений Готовое приложение

Сообщать текущие начисления по категориям

Установка специального режима на период длительного отсутствия

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

Совместимость с Windows 2000

  1.  Управление сложностью путем выбора уровня абстракции

Систему произвольной сложности можно определить с помощью списка из 25-99 функций.

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

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

Далее эти функции будут преобразованы в детальные требования, достаточно конкретные, чтобы их можно было реализовать. Мы будем называть их требованиями к программному обеспечению, или программными требованиями (software requirements), в отличие от высокоуровневых функций. Необходимость в дополнительной конкретизации возникнет позднее. На данном этапе нам достаточно рассуждать на уровне функций.

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

  1.  Атрибуты функций продукта

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

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

Таблица 8. Атрибуты функций

Атрибут

Описание

Статус

Приоритет/Полезность

Трудоемкость

Риск

Стабильность

Целевая версия

Назначение

Обоснование

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

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

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

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

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

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

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

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

  1.  МЕТОДЫ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ


 

А также другие работы, которые могут Вас заинтересовать

9664. Сертификация продукции и услуг 52 KB
  Сертификация продукции и услуг. Сертификация - это деятельность специальных органов исполнительной власти, прошедших государственную регистрацию в качестве системы сертификации в порядке, установленном Госстандартом России. Сертификация устанавливае...
9665. Экспертиза и гигиеническая оценка товаров 47 KB
  Экспертиза и гигиеническая оценка товаров. Сертификация услуг представляет собой процедуру подтвержденная соответствия, посредством которой независимая от исполнителя услуг и потребителя (покупателя) организация удостоверяет в письменной форме, что...
9666. Регистрация и аттестация продукции и услуг 32 KB
  Регистрация и аттестация продукции и услуг. Государственная регистрация продукции осуществляется на основании статьи 43 Федерального закона Российской Федерации от 30 марта 1999 г. N 52-ФЗ О санитарно-эпидемиологическом благополучии населения, ста...
9667. Правила торговли 62.5 KB
  Правила торговли Определение внешнеторговой деятельности дается в Федеральном законе от 13 октября 1995 г. № 157-ФЗ О государственном регулировании внешнеторговой деятельности. Под ней понимается предпринимательская деятельность в области междун..
9668. Товарооборот, цены и тарифы. Правовое регулирование цен 32 KB
  Товарооборот, цены и тарифы Цена - это денежное выражение стоимости продукции, работ, услуг. Разновидностью цены является тариф, который применяется при перевозке. Цены подразделяются на: свободные регулируемые. Свободная цена складывае...
9669. Маркирование товаров. Товарный знак и знак обслуживания 44.5 KB
  Маркирование товаров. Товарный знак и знак обслуживания Маркировка - это условные обозначения и данные, которые наносятся на товар и/или упаковку. Маркировка выполняет следующие функции: информационная идентифицирующая эмоциональная мотивирующая. ...
9670. Понятие оптовой торговли, ее задачи и принципы 34 KB
  Коммерческая деятельность (от лат. commercium - торговля) в широком смысле трактуется как любая предпринимательская деятельность, ориентированная на получение прибыли. Коммерческая деятельность в торговле - охватывает все виды операций, направленных...
9671. ЭТАПЫ КОММЕРЧЕСКОЙ РАБОТЫ ПО ОПТОВЫМ ЗАКУПКАМ 33 KB
  Закупочная работа является основой коммерческой деятельности в торговле. С нее по существу начинается коммерческая работа. Чтобы продать товар покупателю (потребителю) и получить прибыль, необходимо располагать (владеть) товаром. Как отмечалось, гла...
9672. Изучение и поиск коммерческих партнеров по закупке товаров. Классификация поставщиков 68.5 KB
  Изучение и поиск коммерческих партнеров по закупке товаров. Классификация поставщиков Для успешного выполнения коммерческих операций по закупкам товаров оптовые базы должны систематически заниматься выявлением и изучением источников закупки и постав...