В качестве базовых подходов в данной работе будут рассмотрены три модели по работе с требованиями:
· Методология RUP
· Методология Вигерса
· Методология BABOK
Каждая из этих моделей будет проанализирована, будут выделены основные аспекты, на которые каждый подход обращает наибольшее внимание. Во второй части главы будет приведен выбор наиболее релевантной методологии.
Данная методология предлагает деление любого проекта на 4 этапа: Начало внедрения (где определяется, стоит ли начинать проект, каковы его цели, какими ресурсами располагают обе стороны внедрения), Разработка (на данном этапе проводится более глубокий анализ потребностей организации, разработчики предоставляют несколько вариантов реализации проекта, рассчитывается примерная стоимость внедрения), Построение решения (готовое программное решение внедряется в организации и тестируется, производится сбор дополнительных требований), Окончание проекта (система переходит в промышленно-опытную эксплуатацию, вносятся последние правки). На каждом из этапов происходит серия из повторяющихся действий: моделирование, анализ бизнес-процессов, внедрение, тестирование и переход в рабочее состояние. При этом распределение усилий по каждому из этапов происходит по-разному, на каждом этапе проекта фокус определяется в различных степенях.
При этом все фазы могут повторяться со временем, количество таких повторений варьируется в зависимости от конкретного проекта. В данном случае логику RUP можно сравнить с протеканием сезонов в течение года. Вне зависимости от сезона: зимы, весны, лета или осени люди выполняют одинаковые наборы действий, также и в проекте, некоторые действия постоянно повторяются, образуя тем самым замкунтый круг. В качестве примера можно привести следующее: на первом этапе проекта Начале внедрения основной задачей, внедряющей стороны является описание и моделирование существующих бизнес-процессов, определяется, как система концептуально должна будет выглядеть. В том случае, если непосредственно программирование и происходит на данном этапе, то в очень сжатом объеме, только для определения пользовательского интерфейса. На втором этапе, Разработке, будет произведена аналитика описанных процессов и начнется разработка приложения на уровне кода. Таким образом, моделирования бизнес-процесса и кодирование затрагиваеются на обоих этапах, но фокус при каждом из них лежит на разных факторах.
Каждая секция имеет специфичные цели, которые соответственно оцениваются при заверешении этапа. В конце каждого этапа инвесторы и команда внедрения проводят оценку того, насколько хорошо были выполнены поставленные задачи, выделить, какие из критичных задач выполнены не были и причины, почему они не были выполнены вовремя. Самое главное, что происходит в конце этапа - определение того, стоит ли вообще продолжать проект.
На первой стадии, «Начале внедрения», одним из самых первых этапов является определение требований на высшем уровне, на основании данных требований будут определены границы проекта, кроме этого, на основании данных требований можно будет начать разработку самого приложения. На основании разработанных требований можно будет определить, какие цели должны быть достигнуты в результате проекта, или какие претензии организация имеет право предъявлять, а какие нет. Соответственно, данные действия должны быть тщательно задокументированы, руководство организации должно подтвердить, что список выработанных требований является полным и верным, чтобы дополнительные требования, возникающие уже в процессе проекта, проходили не как часть основного проекта, а как отдельная доработка.
На втором этапе, Разработке, требования становятся более подробными, разрабатывается архитектура системы, появляется спецификация метода хранения данных, объекты и документы, которыми будет оперировать система. Для каждого требования также определяются границы. Для этого производится подробное моделирование каждого бизнес-процесса, например, use-case диаграммы, flow диаграммы. Так же как на первом этапе, руководство организации должно подтвердить, что все описания являются точными и не искажают сути реальных процессов. Нарушение данного условия повлечет ошибки на всех последующих этапах, что может создать очень серьезные задержки в проекте или обернуться множество дополнительных трат на переоборудование и структурирование поставленной системы.
На третьем этапе, Построении решения, все ранее разработанные требования, начиная с высших требований, до требований, разработанных на предыдущем этапе берутся за основу решения. Соответственно, в конце этапа должно быть разработано тестовое решение, которые будет тестироваться либо подрядчиком, либо на стороне клиента. В конце данного этапа пользователь должен дать ответ, удовлетворены ли предъявляемые к системе требования, что нужно исправить в системе, что было выполнено не так, как оговаривалось ранее или в неполном объеме.
На заключительном четвертом этапе проекта, Окончании, тестовая версия системы устанавливается для проведения опытной эксплуатации. Кроме этого пользователю предоставляется вся необходимая документация для работы в системе.
Методология RUP предполагает многочисленное повторение цикла действия, как уже было описано ранее. Каждый из циклов завершается созданием версии приложения. Практически ни в одном из проектов первый релиз не становится последним, и, как правило, между первой и последней версиями существует большая разница. Именно по этой причине RUP предполагает выпуск многочисленных версий одного и того же приложения, каждый из которых будет все больше подходить к выполнению требований, при этом вовсе не обязательно при каждой итерации выполнять полный цикл работ. Например, если была допущена критическая ошибка на этапе программирования, то можно не исправлять эту ошибку, а повторить этап разработки снова, создав абсолютно новую версию приложения.
Управление требованиями происходит примерно по такой же логической цепочке: у клиента или у компании есть определенные нужды. Эти нужды переводятся в определенные свойства, на основании которых создаются критерии, предъявляемые к системе. Данные критерии, в свою очередь используются для создания решения или тестового образца, трансформирующегося через серию из доработок в рабочую версию программы. Параллельно с данным процессом готовится сопутствующая документация.
В отличие от методологии RUP, обращающей наибольшее внимание на цикличность операций при работе с требованиями, данная методология приводит намного более подробную декомпозицию требований по различным уровням. Методология делит все требования на функциональные и нефункциональные. К функциональным требованиям относятся требования, которые находятся в рамках функций реализуемой системы, та часть функционала, которая должны быть обязательно выполнена, чтобы пользователи могли работать. К нефункциональным требованиям можно отнести требования, не относящиеся к функционалу напрямую, но тем не менее очень важные для клиента, простота работы с программой, защита информации, которая в ней хранится, устойчивость к сбоям. Работа над проектом, так же как в методологии RUP начинается с определения границ проекта, для чего производится анализ бизнес-требований, требований высшего уровня организации. Эти требования закрепляются в специальном документе - «Документ об образе и границах проекта». Целью данного документа является закрепление исходных требований, на основании которых можно представить, каким образом будет выглядеть система, какими функциями она будет обладать. На следующем этапе происходит более подробное описание системы, ее конкретных функций. Для описания функций нужно построить для каждого пользователя use case диаграмму, которая покажет полный набор функций каждого сотрудника, какими обязанностями и полномочиями он обладает. Это позволяет построить требования на новом уровне, на более глубоком уровне. Понять, что именно требуется от системы в каждом отдельном сценарии и предложить варианты, как это может быть реализовано. Выходом для данного этапа будет документ о вариантах использования, где подробно описаны все возможные сценарии, в этом же документе можно заранее предсказать, какие ошибки система может встретить и как их можно избежать. Дополнительно выделяются системные требования, в данном подходе подчеркивается важность системных требований. Системные требования действительно важны, поскольку именно системные требования определяют, что организация действительно может сделать, а чего она сделать не может. Например, скорость работы программы выделена организацией, как одно из основных требований, но для того чтобы эту скорость обеспечить, нужно поставить отдельный сервер, поскольку на одном терминальном сервере работает одновременно большое количество человек. Организация в данный момент не может обеспечить необходимые системные требования.
Обращаясь подробнее к нефункциональным требованиям, здесь можно выделить еще четыре элемента, которые напрямую или косвенно оказывают влияние на требования, предъявляемые к системе. Во-первых, это бизнес правила, которые определяют, в какой среде находится организация, это безусловно оказывает влияние на систему, которой пользуется организация. В качестве примера можно рассмотреть обязанность предоставления данных об уплате НДС в налоговые органы. Отчет на данный момент нужно предоставлять в электронном виде. Соответственно, к программе бухгалтерского учета предъявляется требование, что она имела реестр по НДС, который можно будет сдать в налоговые органы. Другим важным нефункциональным требованием являются атрибуты качества. Под атрибутами качества понимаются свойства системы, не входящие в ее основной функционал, например, возможность создания копий базы данных и скорости восстановления данных. Если организация работает с большим количеством разъединенных независимых серверов, то существует опасность физического уничтожения данных, пожара. В такой ситуации, свойство системы быстро восстанавливать информацию является ключевым. Последние два нефункциональных требования - это ограничения и внешний интерфейс. Данные требования также имеют внешнее происхождение и касается особенностей использования системы. При создании портала по медицинской помощи, к системе предъявляется требование по возможности двоякого представления информации на веб-сайте. Первое представление будет сделано специально для людей с дефектами или проблемами со зрением, для них нужно использовать более жирные шрифты, увеличить размер всех надписей, убрать многие вложенные функции. Второе представление будет для пользователей без каких-либо отклонений со зрением.
После сбора первичных требований они подвергаются анализу, самым простым из которых является создание контекстной диаграммы, которая должна выявить и показать в доступной форме все существующие сущности и показать, каким именно образом данные сущности взаимодействуют друг с другом. Отталкиваясь от этой информации можно уже описать пользовательский интерфейс будущей системы и подумать, какие именно функции должны быть у каждого отдельного пользователя, можно создать прототип системы. Построения такой модели как на физическом уровне в виде тестовой версии программы, так и на логическом уровне в виде ряда графиков, позволяет не только выявить, какие требования предъявляются к системе, но и понять, какие из ранее зафиксированных требований не имеют реальной надобности. Для того, чтобы построить правдоподобную модель аналитик может пользоваться различными инструментами, такими как проведение интервью, анализа документации, анализ развития процесса предприятия, проведение совместной работы с клиентом на его рабочем месте. Так как многие проекты предполагают достаточно продолжительную работу с клиентом, в течение которой набор требований постоянно меняется, какие-то требования становятся неактуальными, какие-то требования, наоборот, добавляются. Для того, чтобы избежать полного хаоса, нужно требования контролировать, что можно делать с помощью трех инструментов:
Управление версиями требований, предполагающее постоянно фиксирование текущих требований, обеспечение возможности прямого доступа к текущим требованиям всех участников проекта. Наиболее удобный вариант для отслеживания версий требования, это ведение специальной базы данных, где будут храниться все ранее созданные версии.
Введение атрибутов требований, что позволяет рассматривать каждое требование, как отдельный класс или объект. К каждому объекту предъявляются определенные атрибуты, как например, дата создания требования, кто именно данное требование предъявил, трудозатраты на реализацию требования. Такая классификация позволяет разбить требования по классам и подойти к процессу их выполнения более расчетливо и рационально.
Добавление атрибута «состояние» для классификации требований. Это позволяет оценить готовность проекта в целом и каждого из его элементов в отдельности. При этом переход требования в новое состояние должно быть согласовано обеими сторонами. Только в этом случае на проекте не будет происходить откатов на более ранние стадии работы.
Методология BABOK
Наряду с методологией Карла Вигерса в данной методологии работа с требованиями к системе начинается со сбора данных, с обследования текущей ситуации на производстве. В качестве входных данных данного процесса могут выступать документы, использующиеся на производстве, регламенты по проведению работ, сотрудники со стороны анализируемой организации. В данном случае важно отметить, что под сотрудниками подразумеваются именно заинтересованные в проекте лица, сотрудники, у которых есть желание и возможность участвовать в проекте внедрения информационной системы. В качестве выхода данного процесса выступает документ, в котором подробно описан и проанализирован бизнес-процесс предприятия. Методология BABOK предлагает подойти к анализу организации в разрезе шести составляющих:
· Изменение (процесс трансформации в организации, вызванный существованием потребности)
· Потребность (проблема, существующая у сотрудников организации, они могут быть как осознанными, так и нет)
· Решение (способ удовлетворения потребности, конкретный метод)
· Заинтересованная сторона (сотрудники, являющиеся инициаторами, источниками потребности или сотрудники, занимающиеся внедрением информационной системы)
· Ценность (положительный эффект, получаемый сторонами при завершении проекта внедрения)
· Контекст (это вся окружающая среда, которая изменяется при внедрении информационной системы)
Все шесть сторон имеют абсолютно одинаковую важность, ни один анализ не может быть полным до конца, если не раскрыты шесть основных его составляющих. Таким образом, каждая потребность должна быть декомпозирована по данным шести концепциям. Задачей анализа является проектирование дизайна или конкретного решения, основанного на выработанных требованиях.
Требования в данной методологии также классифицируются по-разному: