Материал: Бизнес-процессы компании

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования организации к методологии

Набрано баллов

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

56

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

46

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

64

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

220

Наличие стандартов для оформления

28

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

118

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

24

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

114

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

58

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

108

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

74


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

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

Требования организации к методологии

Набрано баллов

Полученный коэффициент

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

220

0,347002315

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

118

0,18611987

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

114

0,17981073

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

108

0,170347

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

74

0,11671924


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

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


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

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

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

- Нет данных функций, не отвечает данному требованию.

- Плохо реализовано.

- Удовлетворительно.

- Хорошо.

- Превосходно.

При рассмотрении и сравнении трех методологий, были получены следующие результаты (см. Таблица 3 Оценки методологий)

Таблица 3. Оценки методологий

 

RUP

Вигерс

BABOK

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

4

5

5

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

4

2

1

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

5

4

4

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

1

5

1

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

4

5

4


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

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

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

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

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

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

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

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

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

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

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