Материал: Организация управления требованиями

Модельное значение СИ для таких матриц соответственно равно 1,24 и 1,48.

Значение ОС≤0,10 считается приемлемым порогом допустимой согласованности суждений.

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

В Приложении 2, 3, 4, 5, 6 представлены матрицы сравнения альтернатив по критериям и свертка результатов для экспертов 1, 2, 3, 4, 5 соответственно. Отношение согласованности матриц имеет допустимые значения. Ниже в таблице представлены итоговые веса альтернатив, сделанные каждым экспертом и окончательный выбор методики.

Таблица 2

Итоговые веса альтернатив экспертами и выбор методики

По результатам расчетов наиболее подходящей методикой управления требованиями для проектов заказной разработки программного обеспечения является методология Rational Unified Process.

2.     
Разработка показателей эффективности процессов управления требованиями

1.10  Описание профиля компании

ИТ-компания занимается разработкой порталов, сайтов, информационных систем, работает над научными и образовательными проектами. Компания работает с 2003 года. Сначала это был небольшой творческий коллектив «айтишников», сейчас компания насчитывает около 200 сотрудников.

В 2008г. компания выпустила первую версию CRM, которая изначально разрабатывалась для собственных нужд. В 2010г. компания была зарегистрирована. К этому времени коллектив «наработал» репутацию, стали поступать крупные заказы. В 2011г. компания выпустила свой CRM-продукт на рынок. Развитие продукта продолжается. Часть заказной разработки ведется на платформе данного решения.

Основные направления работы компании:

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

·        Работа над крупными ИТ-проектами для социальной и образовательной областей;

·        Разработка порталов и сайтов;

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

·        Консалтинг в области оптимизации бизнес-процессов, управлении проектами, управлении отношениями с клиентами и маркетинг, управлении персоналом, внедрение информационных систем для управления организацией;

·        Организация и информационное сопровождение мероприятий;

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

·        Дизайн, 3D-графика и полиграфия.

Компания имеет следующие лицензии:

·  Лицензии Минкомсвязи России:

o 87107 (Услуги связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации);

o   87108 (Телематические услуги связи);

o   87110 (Услуги связи по передаче данных для целей передачи голосовой информации).

·  Лицензии ФСБ и ФСТЭК России:

o Лицензия от 01.11.2012г. Центра по лицензированию, сертификации и защите государственной тайны ФСБ России на осуществление разработки, производства, распространения шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем.

o   Лицензия Федеральной службы по техническому и экспортному контролю от 28.11.2012г. на деятельность по технической защите конфиденциальной информации.

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

Компания имеет следующие свидетельства и сертификаты:

·  Сертификат соответствия международной системе менеджмента качества ISO 9001:2008 от 20.09.2011.

·        Свидетельство о членстве в Московской торгово-промышленной палате и Торгово-промышленной палате Российской Федерации.

·        Сертификат члена Ассоциации менеджеров.

·        Свидетельство Почетного члена Фонда поддержки предпринимательских инициатив.

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

На рисунке 8 представлена организационная структура компании.

Рисунок 8 - Организационная структура компании

1.11  Описание типового проекта разработки заказного программного обеспечения

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

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

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

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

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

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

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

Рисунок 9 - Жизненный цикл типового проекта разработки заказного ПО

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

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

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

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

На рисунке 10 представлена типовая организационная структура проекта разработки заказного программного обеспечения.

Рисунок 10 - Организационная структура проекта

Ключевая роль в проектной команде - руководитель проекта. Это всегда один человек. В зависимости от масштабов проекта привлекается 1-2 аналитика. Иногда, в случае, если проект небольшой, то роль аналитика может выполнять руководитель проекта. Также в зависимости от масштабов проекта привлекается как правило от одного до пяти программистов (в среднем 2-3 программиста).

·  Формирование концептуальной модели

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

Выходами данного процесса являются:

o Задаются ключевые характеристики и функции системы;

o   Определяются ограничения для решений;

o   Формируется основа для ведения переговоров и заключения соглашения о разработке продукта;

o   Формируется документ-концепция

·  Сбор требований

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

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

Задачи процесса:

o Идентификация заинтересованных сторон;

o   Идентификация требований;

o   Оценка требований;

o   Согласование требований;

o   Регистрация требований.

Выходы процесса:

o Задаются свойства системы;

o   Задаются ограничения на решения.

·  Анализ требований

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

Задачи:

o Документирование требований;

o   Оценивание требований.

Выходы:

o Устанавливается перечень системных функциональных и нефункциональных требований;

o   Системные требования анализируются на корректность и тестируемость;

o   Требования ранжируются, утверждаются;

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

·  Проектирование системы

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

Цель процесса заключается в определении какие требования и как распределить в относительно элементов системы.

Задачи:

o Формальная документация требований;

o   Создание архитектуры проекта;

o   Оценка архитектуры проекта;

o   Документация проекта.

Выходы:

o Модели программного продукта;

o   Определяется архитектурный проект системы;

o   Требования распределяются по элементам системы;

o   Разработка дополнительных спецификаций;

o   Определяются интерфейсы системы;

o   Техническое задание на разработку.

·  Разработка прототипа системы

Цель: создание прототипа будущего программного продукта.

Задачи:

o Создание прототипа;

o   Согласование прототипа.

Выходы:

o Прототип системы;

o   Согласованные требования к системе.

·  Управление изменениями

Цель процесса:

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

Рисунок 11- Процессы управления требованиями в компании

Задачи:

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

o   Внести изменения в проект, документацию.

Выходы:

o Измененные модели проекта, документация;

o   Авторизованные изменения.

Описанные процессы схематично изображены на рисунке ниже.

1.13  Теоретические основы по разработке показателей эффективности

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

Показатели эффективности должны соответствовать принципу SMART (Specific, Measurable, Achievable, Realistic, Timely - конкретный, измеримый, достижимый, реалистичный, своевременный). Этот набор вопрос должен быть задан для каждого показателя эффективности, чтобы убедиться в его «правильности» [30].

Дадим расшифровку каждого вопроса:

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

·        Измеримый - должна быть возможность измерить/оценить показатель.

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

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

·        Своевременный − срок или точный период измерения - одна из составляющих показателя.

1.14  Состав показателей эффективности процессов управления требованиями

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

Процесс «Формирование концептуальной модели»

Показатели для процесса формирования концептуальной модели представлены в таблицах 3-5.

Табли

Описание показателя A1