Размещено на http://www.allbest.ru/

22

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Анализ текущей ситуации в организации

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

2.1 Анализ существующих подходов по управлению требованиями

2.2 Определение требований к ИС организации

2.3 Определение наиболее релевантной методологии

2.4 Пояснения к распределению баллов

2.5 Выбор методологии для работы с требованиями

Глава 3. Разработка требований к ИС организации ХХХ

3.1 Обработка документа заказа, выгруженного из системы Magento

3.2 Обработка заказа на продажу физическому лицу в магазине

3.3 Обработка заказа на продажу юридическому лицу

3.4 Обработка заказа на закупку товара

3.5 Операции по складу

Заключение

Список литературы

Введение

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

Данный вопрос безусловно поднимался другими авторами во многих статьях, раскрывающих разнообразные методики по управлению требованиями организации, способам их определения. Данная информация встречается и будет упомянута в работах Подиновского, Babok, RUP, Карла Виггерса и прочих. Однако, требования к информационной системе в данных работах даны в общем виде, в данной же работе будут выделены требования, предъявляемые к определенной системе для определенной организации. Кроме этого, многие из работ перечисленных авторов были написаны более десяти лет назад, а особенностью IT является быстрая изменчивость рынка, что необходимо учитывать при разработке определения требований.

В данной работе объектом исследования являются бизнес-процессы компании ХХХ. В качестве предмета исследования выступают функциональные требования для ИС компании ХХХ. Цель работы - сформировать функциональные требования, определяющие работу ИС организации.

Задачи, которые должны быть выполнены в рамках данной работы:

— Проанализировать текущие процессы организации и показать потребности организации, обусловленность внедрения ИС

— Проанализировать уже описанные методологии

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

— Выбрать наиболее релевантную методологию для организации XXX

— Обосновать состав требований для организации XXX

В данной работе будут использоваться следующие методы исследования:

— Наблюдение (используется для анализа предприятия XXX)

— Сравнение (будет использоваться при сравнении различных методик по управлению требованиями)

— Обобщение (в работе будут приведены примеры различных методик для обоснования выбора наиболее подходящей из них для предприятия ХХХ)

— Моделирование (будет построена IDEF0 модель для двух уровней и диаграмма вариантов использования для описания текущих бизнес-процессов организации, будет построена диаграмма сценариев использования для анализа функциональных требований)

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

Методики по управлению требованиями ИС перечисленные в данной работе будут получены на основании:

· Открытых источников (авторы работ перечислены ранее)

· Личного опыта (будет рассмотрен проект, в котором принималось личное участие)

В итоге работы должны быть получены следующие результаты:

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

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

· Выявлена наиболее релевантная методология для предприятия XXX

· Приведен пример разработки требований для предприятия XXX

· Даны выводы по проделанной работе

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

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

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

· В первой главе будет проанализирована текущая ситуация в организации, обусловлена необходимость внедрения ИС

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

· В третьей главе будет приведен пример разработки функциональных требований к ИС для организации ХХХ

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

· В списке литературы перечислены использованные материалы.

Глава 1. Анализ текущей ситуации в организации

Организация ХХХ занимается продажей мебели, начиная с 2002 года. Компания имеет два отделения: первое из которых занимается продажей продукции физическим лицам (в категорию данных продуктов попадают предметы мелкой гарнитуры, как например крючки, подставки, полки и так далее) и юридическим лицам, крупным мебельным магазинам, реализующим свою продукцию в России и в Европе. Работа и правила продажи и закупки для юридических лиц регламентируются специальным документом - «Общее соглашение», которое описывает условия, на которых организация ХХХ и ее партнеры производят совместную хозяйственную деятельность при покупке, продаже товаров и материалов. Продажа продукции физическим лицам происходит через интернет-магазин. Интернет-магазин работает на платформе Magento, которая позволяет обрабатывать заказы клиентов, контент и остатки товаров на складах. Кроме интернет-канала продажа физическим лицам происходит через небольшой магазин в торговом центре. В связи с резко увеличившимся потоком клиентов, как в частном секторе, так и в секторе ритейла организации ХХХ стало очень сложно отслеживать движение товаров и вовремя предоставлять необходимую документацию как при закупке товара, так и при его реализации. Перед руководством компании встал серьезные выбор, между тем, чтобы оставить ситуацию в неизменном состоянии или же попытаться улучшить качество работы предприятия за счет внедрения информационной системы. Другим важным вопросом, в случае внедрения системы, является вопрос о том, какую именно систему нужно внедрить.

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

Для отражения основных функций организации была подготовлена контекстная диаграмма (см. Рисунок 1 Контекстная диаграмма) или первый уровень диаграммы IDEF0.

Рисунок 1. Контекстная диаграмма

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

· Процесс закупки товара

· Процесс продажи товара

· Операции по складу

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

Рисунок 2. IDEF0 Второй уровень

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

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

Рисунок 3 Варианты использования

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

Второй важной проблемой, существующих в текущих бизнес-процессах организации является ручная подготовка документации. В случае, если продажа оформляется в магазине, то продавцу приходится вручную заполнять все продаваемые позиции товаров, что сильно замедляет обслуживание каждого отдельного клиента и влечет множество ошибок, которые затем нужно переделывать, что влечет большие затраты времени. Такое обслуживание не удовлетворяет самих клиентов и многие из них предпочитают не возвращаться в данный магазин. В случае, если продажа или закупка осуществляется с юридическим лицом, то здесь проблема с ручной подготовкой документации обстоит еще более острым образом, так как требования к печатным формам у каждого из юридических лиц свои, что влечет ошибки при подготовке документации вручную. Кроме этого, как было оговорено ранее, деятельность с юридическими лицами определяется документом «Общее соглашение». Данный документ содержит условия и ограничения на продажу, закупку, он содержит специальные цены, которые, как правило, гораздо ниже обычных расценок. При заведении продажи или закупки, бухгалтер вынужден для каждого клиента проверять условия «Общего соглашения», следить, чтобы они не были нарушены. Если же бухгалтер совершит ошибку и, например, забудет проставить специальные цены для контрагента, то это вызовет серьезное недовольство со стороны партнера. Если же такие ошибки будут происходить часто, то это может привести к потере бизнес-партнёра, потере устойчивого источника денег.

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

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

В качестве базовых подходов в данной работе будут рассмотрены три модели по работе с требованиями:

· Методология RUP

· Методология Вигерса

· Методология BABOK

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

Методология RUP

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

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

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

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

На втором этапе, Разработке, требования становятся более подробными, разрабатывается архитектура системы, появляется спецификация метода хранения данных, объекты и документы, которыми будет оперировать система. Для каждого требования также определяются границы. Для этого производится подробное моделирование каждого бизнес-процесса, например, use-case диаграммы, flow диаграммы. Так же как на первом этапе, руководство организации должно подтвердить, что все описания являются точными и не искажают сути реальных процессов. Нарушение данного условия повлечет ошибки на всех последующих этапах, что может создать очень серьезные задержки в проекте или обернуться множество дополнительных трат на переоборудование и структурирование поставленной системы.

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

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

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

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

Методология Вигерса

В отличие от методологии RUP, обращающей наибольшее внимание на цикличность операций при работе с требованиями, данная методология приводит намного более подробную декомпозицию требований по различным уровням. Методология делит все требования на функциональные и нефункциональные. К функциональным требованиям относятся требования, которые находятся в рамках функций реализуемой системы, та часть функционала, которая должны быть обязательно выполнена, чтобы пользователи могли работать. К нефункциональным требованиям можно отнести требования, не относящиеся к функционалу напрямую, но тем не менее очень важные для клиента, простота работы с программой, защита информации, которая в ней хранится, устойчивость к сбоям. Работа над проектом, так же как в методологии RUP начинается с определения границ проекта, для чего производится анализ бизнес-требований, требований высшего уровня организации. Эти требования закрепляются в специальном документе - «Документ об образе и границах проекта». Целью данного документа является закрепление исходных требований, на основании которых можно представить, каким образом будет выглядеть система, какими функциями она будет обладать. На следующем этапе происходит более подробное описание системы, ее конкретных функций. Для описания функций нужно построить для каждого пользователя use case диаграмму, которая покажет полный набор функций каждого сотрудника, какими обязанностями и полномочиями он обладает. Это позволяет построить требования на новом уровне, на более глубоком уровне. Понять, что именно требуется от системы в каждом отдельном сценарии и предложить варианты, как это может быть реализовано. Выходом для данного этапа будет документ о вариантах использования, где подробно описаны все возможные сценарии, в этом же документе можно заранее предсказать, какие ошибки система может встретить и как их можно избежать. Дополнительно выделяются системные требования, в данном подходе подчеркивается важность системных требований. Системные требования действительно важны, поскольку именно системные требования определяют, что организация действительно может сделать, а чего она сделать не может. Например, скорость работы программы выделена организацией, как одно из основных требований, но для того чтобы эту скорость обеспечить, нужно поставить отдельный сервер, поскольку на одном терминальном сервере работает одновременно большое количество человек. Организация в данный момент не может обеспечить необходимые системные требования.

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

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

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

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

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

Методология BABOK

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

· Изменение (процесс трансформации в организации, вызванный существованием потребности)

· Потребность (проблема, существующая у сотрудников организации, они могут быть как осознанными, так и нет)

· Решение (способ удовлетворения потребности, конкретный метод)

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

· Ценность (положительный эффект, получаемый сторонами при завершении проекта внедрения)

· Контекст (это вся окружающая среда, которая изменяется при внедрении информационной системы)

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

Требования в данной методологии также классифицируются по-разному:

· Бизнес-требования: дают подробное описание причин начала проекта, зачем происходит внедрение.

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

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

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

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

Для анализа требований методология использует следующие инструменты:

· Бенчмаркинг (сравнение собственных бизнес-процессов с эталонной компанией или группой компаний)

· Брейнсторм (решение одной задачи усилиями множества людей, при которой каждый сотрудник предлагает свой вариант решения, далее с помощью голосования определяется наилучший вариант)

· Анализ бизнес-правил (анализ формального окружения организации, базирующегося на существующих регламентах)

· Игровая манера (предлагает участникам проекта генерировать идеи в игровой форме)

· Концептуальное моделирование (анализ основных сущностей модели и существующих между ними связей)

· Исследование интерфейсов (анализ попарного взаимодействия сотрудников, программ, систем)

· Интервью (анализ требований через ответы на заранее подготовленный список вопросов)

· Моделирование процессов (построение моделей, описывающих взаимодействие сущностей или последовательность действий процесса)

· Наблюдение (физическое присутствие на рабочем месте клиента, для описания его деятельности)

· Опрос (простое анкетирование сотрудников)

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

2.2 Определение требований к ИС организации

информационный управление требование

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

· Точное перечисление участников проекта и их ролей

· Анализ требований на нескольких уровнях

· Описание роли аналитика критериев, его роли и компетенций

· Предъявление наибольшего количества методов для получения требований

· Возможность построения отчетов

· Подробное описание распределения усилий на всех этапах проекта

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

· Описание требуемого результата при работе с требованиями на каждом этапе проекта

· Перечисление наибольшего количества описательных диаграмм для моделирования процесса

· Описание методов отслеживания изменяющихся требований

· Разбор методов классификации требований по различным уровням

Данный список был получен на основании предварительных переговоров грядущего проекта между продавцом внедряющей организации, представленной в лице группы профессиональных IT специалистов с большим опытом внедрения проектов и компанией ХХХ, заказывающей проект по внедрению информационной системы. После того, как список с требованиями был подготовлен, для достижения наибольшей объективности всем сотрудникам организации ХХХ было предложено пройти тестирование и определить, какие из требований к методологии является наиболее важными. Условия тестирования были следующими, каждый опрашиваемый получил ранее оговоренный список с перечисленными потребностями организации. Среди данных пунктов сотрудник должен был выбрать пять наиболее важных, критичных потребностей для своей организации. При этом пять пунктов нужно было расположить в порядке возрастания потребности организации, первый пункт получал 2 бала, второй- 4, третий - 6, четвертый - 8 и наиболее важный, по мнению интервьюируемого, 10. В результате данного опроса был получен список потребностей организации, который можно считать объективным, так как свои пункты он основывает не на мнении одного человека или группы лиц, а учитывает мнение всех специалистов, работающих в организации. Ниже приведен список с полученными результатами (см. Таблица 1 Критерии выбора методологии")

Таблица 1. Критерии выбора методологии

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

Таблица 2. Веса важности критериев