Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Организация управления требованиями

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

Определение критериев для сравнения методик управления требованиями. Особенности создания заказного программного обеспечения. Разработка показателей эффективности процессов управления требованиями. Оценка текущих процессов реализации проектов компании.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 31.10.2016
Размер файла 1,7 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

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

Оглавление

  • Введение
    • 1. Сравнительный анализ методик управления требованиями
    • 1.1 Процессы управления требованиями в REBOK
    • 1.2 Процессы управления требованиями в PMBOK
    • 1.3 Процессы управления требованиями в RUP
    • 1.4 Процессы управления требованиями в ITIL
    • 1.5 Процессы управления требованиями в BABOK
    • 1.6 Процессы управления требованиями в SWEBOK
    • 1.7 Особенности разработки заказного программного обеспечения
    • 1.8 Критерии сравнения методик
    • 1.9 Выбор методики для проектов заказной разработки программного обеспечения
    • 2. Разработка показателей эффективности процессов управления требованиями
    • 2.1 Описание профиля компании
    • 2.2 Описание типового проекта разработки заказного программного обеспечения
    • 2.3 Процессы управления требованиями в проектах компании
    • 2.4 Теоретические основы по разработке показателей эффективности
    • 2.5 Состав показателей эффективности процессов управления требованиями
    • 3. Оценка текущих процессов в компании и разработка рекомендаций
    • 3.1 Оценка процессов управления требованиями в реализованных проектах компании
    • 3.2 Рекомендации по повышению качества процессов управления требованиями в компании
    • Заключение
    • Список литературы
    • ПРИЛОЖЕНИЯ

Введение

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

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

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

К наиболее явным причинам сложности задачи управления требованиями [2, 4, 5, 6] можно отнести:

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

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

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

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

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

Типичными причинами срыва сроков и бюджета проектов, как правило, являются [5, 7, 8]:

· плохо сформулированные требования;

· не все требования были выявлены;

· сложности в отслеживании изменений требований.

Широко распространены ситуации, в которых устранение ошибок требований представляет собой достаточно амбициозную задачу, требующих немалых временных и финансовых усилий. Устранение ошибки в требованиях на стадии сопровождения готового программного продукта обходится, как правило, в среднем в 200 раз дороже, нежели на этапе формирования спецификации требований. Это значение можно сравнить со стоимостью ошибки в требованиях, выявляемой на поздних фазах проекта - такая ошибка, как правило, приводит к 30--40% превышению бюджета проекта [9].

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

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

Вопросы формирования, документирования, анализа, управления требованиями были изучены и проанализированы в работах отечественных и зарубежных авторов. Среди них следует отметить труды таких авторов, как: Вигерс К., Коберн А., Халл Э., Леффингуэлл Д., Мацяшек Л., Орлик С., Уидриг Д., Меняев М.Ф., Булуй Ю., Липаев В.В. Так, книга Вигерс К. «Подходы к управлению требованиями» посвящена разработке качественных требований к программному продукту. В ней представлен ряд методов формирования, проверки, анализа, тестирования требований к программному обеспечению. В работе Халл Э. «Подходы к управлению требованиями» рассмотрен процесс разработки и управления требованиями.

На текущий момент существует значительное количество нормативных документов, регламентирующих работу с требованиями к программному продукту. Среди них стоит отметить разработки IEEE: IEEE 1233 «Guide for Developing System Requirements Specifications», IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK, «IEEE Recommended Practice for Software Requirements Specifications». Кроме этого нельзя не упомянуть отечественные стандарты, включая: ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания, ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению, ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы. Вопросы работы с требованиями затронуты в следующих методологиях: Requirements Engineering Body Of Knowledge (REBOK), Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Project Management Body of Knowledge (PMBoK), Agile software development [10].

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

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

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

Набор задач, который был сформирован для достижения обозначенной цели, включает в себя:

· Определение критериев для сравнения методик управления требованиями;

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

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

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

· Оценка проектов компании по разработанным показателям;

· Формирование рекомендаций по повышению качества процессов управления требований в компании.

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

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

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

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

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

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

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

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

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

Ключевые слова

Требования к программному продукту, управление требованиями, управление изменениями, управление проектом, методика, методология, свод знаний, лучшие практики, REBOK, PMBOK, RUP, ITIL, BABOK, SWEBOK, заказное программное обеспечение, метод анализа иерархий, показатель эффективности, принцип SMART

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

1.1 Процессы управления требованиями в REBOK

Работа с требованиями в своде знаний REBOK (Requirements Engineering Body Of Knowledge) представлена в двух процессах: Формирование требований (Requirements Development) и Управление требованиями (Requirement Management).

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

· Выявление требований (Requirements Elicitation). Основные цели: определение всех потребных характеристик, функций будущего программного продукта, детализация требований и подробное описание функций системы.

· Анализ требований (Requirements Analysis). Основные моменты данного этапа: определение и разрешение конфликтов в требованиях, обозначение границ проекта, преобразование пожеланий Заказчика в программные и системные требования.

· Спецификация требований (Requirements Specification). Спецификации содержат такую информацию: пользовательские требования, ограничения проекта, критерии приемки результатов проекта.

· Моделирование (Solution and System Modeling). Базовыми являются такие модели: концептуальная модель, модель решения, модель требований.

· Утверждение и проверка требований (Requirements Validation and Verification). Данные активности должны быть запланированы в начале проекта. Следует выполнять проверку документации требований на соответствие стандартов, а также утверждать разработанные модели на этапах анализа и спецификации [11].

Процесс формирования требований представлен на рисунке 1.

Рисунок 1 - Процесс формирования требований (Process for Requirements Development)

Процесс управления требованиями согласно REBOK состоит из следующих этапов:

· Отслеживание требований (Tracking of Requirements). Данный этап помогает проверить все ли важные цели процесса разработки выполнены;

· Управление изменениями (Change Management). Управление изменениями включает в себя следующие процедуры:

o Идентификация потенциальных изменений;

o Регистрация запроса на изменения;

o Анализ запросов на изменения;

o Оценка изменений;

o Планирование выполнения изменений;

o Реализация изменений;

o Обзор и закрытие изменений.

· Обеспечение качества (Quality Assurance). Основные функции этого этапа:

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

o Проведение аудита и последующих корректирующих действий;

o Оценка и анализ инжиниринга требований;

o Совершенствование процесса инжиниринга требований.

1.2 Процессы управления требованиями в PMBOK

В своде знаний по управлению проектами PMBOK подход к требованиям описан в главе «Общее управление изменениями» [12]. Согласно PMBOK общее управление изменениями включает в себя следующие операции:

· Идентификация изменений;

· Рассмотрение и утверждение изменений;

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

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

· Проверка и одобрение корректирующих и предупреждающих действий;

· Контроль и обновление содержания, стоимости, бюджета, расписания проекта и требований к качеству;

· Документирование выполненных изменений;

· Санкционирование исправлений дефектов;

· Контроль качества проекта по стандартам.

Общий вид процесса управления изменениями согласно PMBOK представлен на рисунке 2.

Рисунок 2 - Общее управление изменениями (входы, выходы, процессы)

1.3 Процессы управления требованиями в RUP

Согласно RUP (Rational Unified Process), управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе [13].

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

· Формирование плана управления требованиями. Данный план описывает общие подходы к управлению требованиями в проекте: как собираются требования, как отслеживаются изменения и т.д.;

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

· Разработка документов концепции (Vision);

· Создание сценариев использования (Use Cases). Сценарии использования - это форма для описания функциональных требований, представляет собой описание системы в терминах последовательности действий. Сценарии использования:

o Инициируются действующим лицом;

o Представляют собой взаимодействие между пользователем и системой;

o Определяют последовательность действий;

o Содержат в себе функциональные требования;

o Имеют некоторое значение для действующего лица;

o Представляют собой имеющий смысл сценарий событий.

Рисунок 3 - Модель процессов управления требованиями в RUP. Источник - Филипп Крачтен «Введение в Rational Unified Process»

· Дополнительная спецификация. Содержит описание нефункциональных требований (удобство работы, надежность, производительность и др.), а также некоторые функциональные требования.

· Создание тестовых сценариев (Test Cases) из сценариев использования (Use Case). Тестовые сценарии показывают тестеровщикам шаги работы в системе для проверки требований.

· Создание тестовых сценариев (Test Cases) из дополнительной спецификации;

· Проектирование системы. Основой процесса являются требования. Проектирование зачастую сопровождается применением Универсального Языка Моделирования - Unified Model Language (UML) [14, 15].

На рисунке 3 можно ознакомиться с моделью управления требованиями согласно RUP.

1.4 Процессы управления требованиями в ITIL

В библиотеке ITIL (IT Infrastructure Library) работа с требованиями представлена в рамках двух процессов: Проектирование услуг (Service Design) и Преобразование услуг (Service Transition) [16]. В первом процессе описана классификация требований и инструменты для их выявления.

Управление изменениями требований представлено в одноименном процессе Управление изменениями (Change Management) и включает в себя следующие шаги [10]:

· Формирование запроса на изменение;

· Рассмотрение запросов и предложений на изменения;

· Анализ и оценка влияния изменений на сервис и активы.

· Авторизация изменений:

o Получение разрешения/отказа на реализацию изменения;

o Оповещение заинтересованных сторон.

· Обновление планов;

· Управление выполнения изменений;

· Рассмотрение и закрытие изменений:

o Рассмотрение изменений и внесение правок в документацию;

o Закрытие документации.

С моделью процесса управления изменениями можно ознакомиться на рисунке 4.

Рисунок 4 - Модель управления изменениями в ITIL. Источник «ITIL Version 3.0. Service Transition»

1.5 Процессы управления требованиями в BABOK

Свод лучших знаний BABOK (Business Analysis Body Of Knowledge) раскрывает вопрос управления требованиями в главе «Управление требованиями и коммуникации». Ниже представлен перечень основных этапов работы с требованиями [17].

· Управление границами решения и их требованиями (Manage Solution Scope&Requirements). Данная задача состоит из обеспечения утверждения требований всех заинтересованных сторон, управления анализом требований. Задача включает в себя:

o Управление рамками решений (Solution Scope Management);

o Управление конфликтами (Conflict and Issue Management);

o Представление требований для обзора (Presenting Requirements For Review);

o Утверждение (Approval).

· Управление прослеживаемостью требований (Manage Requirements Traceability). Целью является создание и поддержка отношений между бизнес-целями, требованиями и компонентами. Задача состоит из следующих шагов:

o Определение отношений (Relationships) между требованиями;

o Анализ влияния (Impact Analysis) изменения;

o Система управления конфигурацией (Configuration Management System).

· Поддержка требований для повторного использования (Maintain Requirements for Re-use) - управление знаниями о требованиях после их выполнения. Шаги задачи:

o Текущие требования (Ongoing Requirements) - требования, которые могут быть использованы на постоянной основе: договорные обязательства, соглашения об уровне обслуживания, бизнес-правила, бизнес-процессы, стандарты качества;

o Удовлетворенные требования (Satisfied Requirements).

· Подготовка пакета требований (Prepare Requirements Package). Цель данной задачи ? выбор и структурирование требований в набор так, чтобы обеспечить эффективные коммуникации, понимание и применение требований всеми заинтересованными сторонами проекта. Шаги задачи:

o Рабочие проекты и результаты (Work Products and Deliverables);

o Формат (Format). В зависимости от типа требований может меняться формат их представления.

· Коммуникация требований (Communicate Requirements). Цель - общее понимание требований всеми заинтересованными участниками. Включает в себя беседы, дискуссии, заметки, документы, презентации.

o Общие коммуникации (General Communication);

o Презентации (Presentations).

В целом процесс управления требований представлен на рисунке 5.

Рисунок 5 - Процесс управления требованиями по BABOK. Источник «A Guide to the Business Analysis Body Of Knowledge. Version 2.0»

1.6 Процессы управления требованиями в SWEBOK

SWEBOK (Guide to the Software Engineering Body of Knowledge) выделяет в работе с требованиями следующие этапы:

· Выявление требований (Requirements Elicitation);

· Анализ требований (Requirements Analysis) - включает в себя выявление и разрешение конфликтов между требованиями, определение границ программного продукта, разработку системных требований. Этап состоит из следующих задач:

o Классификация требований (Requirements Classification);

o Концептуальное моделирование (Conceptual Modeling) - выполняется для понимания сути проблемы;

o Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation);

o Согласование требований (Requirements Negotiation).

· Спецификация требований (Requirements Specification) - документы, полученные в результате сбора и анализа требований, их моделирования и архитектурного проектирования. Чаще всего используются следующие виды спецификации:

o Определение системы (System Definition) - формируется документ, который описывает системные требования, определяет высокоуровневые требования и стратегические цели программного продукта;

o Системные требования (System Requirements) - документ-спецификация описывает действия системных инженеров;

o Программные требования (Software Requirements) -определяются соглашения между Заказчиком и исполнителем в отношении того, что должна делать система.

· Проверка требований (Requirements Validation) [18, 19].

Описанный процесс представлен на рисунке 6.

Рисунок 6 - Работа с требованиями по SWEBOK

В главе «Конфигурационное управление» (Software Configuration Management) SWEBOK рассматриваются вопросы управления изменениями. Описание включает в себя, какие именно изменения должны быть сделаны, какие полномочия необходимы для утверждения изменений, в чем состоит поддержка реализации этих изменений. К данному процессу относятся такие этапы, как [20]:

· Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes). Включает формальные процедуры по предложению и регистрации запросов на изменения, оценки стоимости и влияния предлагаемых изменений, а также утверждение или отказ от внесенных предложений по изменениям.

· Реализация изменений (Implementing Software Changes).

· Отклонения и отказ от изменений (Deviations and Waivers). Отклонение - утверждение изменений с некоторой корректировкой условий и работ.

Описанный процесс представлен на рисунке 7.

Рисунок 7 - Процесс управления изменениями по SWEBOK

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

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

· Для решения поставленной задачи не существует тиражируемого программного обеспечения;

· Тиражируемое программное обеспечение существует, но оно не удовлетворяет в полной мере всем требованиям Заказчика;

· Слишком дорогая лицензия на существующее тиражируемое программное обеспечение [22, 23].

Чаще всего разработка на заказ и внедрение программного продукта используется при решении таких задач [24, 25]:

· Автоматизация уникальных бизнес-процессов;

· Адаптация существующих систем к новым нестандартным требованиям Заказчика;

· Интеграция существующих информационных систем;

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

· Интеграция с информационными системами предприятий-партнеров;

· Интеграция данных из территориально распределенных подразделений компании.

Для удачного завершения проектов заказного программного обеспечения выделяют факторы [22, 24, 25, 26]:

· Четкая ориентация на бизнес-цели Заказчика;

· Активное участие всех заинтересованных сторон;

· Постоянная коммуникация между заинтересованными сторонами;

· Детальная проработка требований на ранних этапах проекта;

· Готовность к изменениям требований на всех этапах проекта, в том числе и на поздних;

· Многократная поставка результатов;

· Тестирование выполняется непрерывно;

· Во главу ставится соответствие готового решения бизнес-требованиям;

· Гибкость к модификациям и масштабируемость системы под требования растущего бизнеса.

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

1.8 Критерии сравнения методик

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

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

Исходя из представленных особенностей заказной разработки ПО совместно с группой экспертов были выделены следующие критерии для сравнения перечисленных выше методик:

· Инструменты и техники выявления требований;

· Описание потребных характеристик требований;

· Выделение и спецификация ролей;

· Инструменты демонстрации результатов на ранних этапов;

· Формализация этапа анализа требований;

· Наличие алгоритма внесения изменений в требования;

· Наличие методики проверки/тестирования требований.

· Ориентация на заказную разработку;

· Степень полезности (определяет, насколько методика полезна в понимании и создании эффективной модели управления требованиями);

· Соответствие этапов методики этапам проекта;

· Нейтральность по отношению к масштабам проекта;

· Степень формализма (наличие документов, представленных в методике. Данный критерий выделен, т.к. формализм в данном случае оказывает влияние на скорость и трудоемкость выполнения разработки).

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

На основе сформированных критериев выполним сравнение методик с помощью метода анализа иерархий (метод Саати). Критерии сравнения и альтернативы выбора представляются в виде иерархии, которая представлена в Приложении 1.

Для определения весов критериев и оценки методик по каждому критерию применяется метод попарного сравнения [27]. Для регистрации результата сравнения пары использовалась шкала, представленная в таблице 1.

Таблица 1

Шкала сравнения пары альтернатив

Значение

Качественная характеристика

1

Равноценные элементы

2

Несущественный приоритет

3

Слабый приоритет

4

Умеренный приоритет

5

Значительный приоритет

6

Существенный приоритет

7

Сильный приоритет

8

Очень сильный приоритет

9

Безусловный приоритет

Результаты парных сравнений заносятся в матрицу. Для каждой матрицы определяется вектор приоритетов. Для определения весов использовался следующий способ: из произведения n элементов каждой строки извлекаем корень n-й степени и нормализуем полученные значения [28, 29].

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

Также проводим расчет показателей согласованности. Отклонение от согласованности называют индексом согласованности (ИС), которое рассчитывается по следующей формуле:

Главное значение матрицы - определяем следующим образом: суммируем произведения векторов приоритетов на суммы элементов каждого столбца. Далее определяем отношение согласованности как

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

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

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

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

Таблица 2

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

Э1

Э2

Э3

Э4

Э5

Итоговый вес

B1

0,12

0,16

0,17

0,16

0,20

0,16

B2

0,09

0,08

0,08

0,07

0,09

0,08

B3

0,25

0,22

0,22

0,23

0,21

0,23

B4

0,18

0,18

0,22

0,22

0,23

0,21

B5

0,22

0,13

0,09

0,14

0,15

0,15

B6

0,14

0,23

0,21

0,19

0,12

0,18

По результатам расчетов наиболее подходящей методикой управления требованиями для проектов заказной разработки программного обеспечения является методология 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 программиста).

1.12 Процессы управления требованиями в проектах компании

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

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

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

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

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

Свойства

Описание

Показатель

Время разработки концептуальной модели

Описание

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

Спецификация

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

Обоснование

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

Аудитория

Руководство компании, руководитель проекта, члены проектной команды

Опасное значение

20 дней

Целевое значение

10 дней

Возможные значения

9999

Приоритет

1

Таблица 4

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

Свойства

Описание

Показатель

Количество замечаний Заказчика к концептуальной модели

Описание

Степень удовлетворенности Заказчика концептуальной моделью системы

Спецификация

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

Обоснование

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

Аудитория

Руководство компании, руководитель проекта, члены проектной команды

Опасное значение

>25

Целевое значение

10

Возможные значения

999

Приоритет

3

Таблица 5

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

Свойства

Описание

Показатель

Затраты на формирование концептуальной модели

Описание

Сколько стоит разработка концептуальной модели системы

Спецификация

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

Обоснование

Показатели затрат имеют важное значение на всех этапах реализации проекта, независимо от того применительно к каким процессам они рассчитываются

Аудитория

Руководство компании, руководитель проекта

Опасное значение

20% бюджета проекта

Целевое значение

5% бюджета проекта

Возможные значения

По согласованию с Заказчиком. Теоретически не ограничены

Приоритет

2

Процесс «Сбор требований»

Показатели для процесса «Сбор требований» представлены в таблицах 6-8.

Таблица 6

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

Свойства

Описание

Показатель

Время сбора требований

Описание

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

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, члены проектной команды

Опасное значение

25 дней

Целевое значение

15 дней

Возможные значения

9999

Приоритет

1

Таблица 7

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

Свойства

Описание

Показатель

Покрытие требованиями предметной области

Описание

Насколько выявленные требования охватывают рассматриваемую предметную область

Спецификация

Экспертная оценка

Обоснование

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

Аудитория

Руководитель проекта, члены проектной команды

Опасное значение

<70%

Целевое значение

100%

Возможные значения

0-100%

Приоритет

3

Таблица 8

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

Свойства

Описание

Показатель

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

Описание

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

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, проектная команда

Опасное значение

>8

Целевое значение

4

Возможные значения

99

Приоритет

2

Процесс «Анализ требований»

Показатели процесса анализа требований представлены в таблицах 9 - 12.

Таблица 9

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

Свойства

Описание

Показатель

Процент подлежащих реализации требований

Описание

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

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, члены проектной команды

Опасное значение

<60%

Целевое значение

80%

Возможные значения

0-100%

Приоритет

4

Таблица 10

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

Свойства

Описание

Показатель

Количество дополнительных требований

Описание

Выявленные требования на этапе анализа

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, проектная команда

Опасное значение

30

Целевое значение

10

Возможные значения

9999

Приоритет

2

Таблица 11

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

Свойства

Описание

Показатель

Процент требований, подлежащих корректировке

Описание

Количество требований с ошибками после завершения стадии анализа

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, проектная команда

Опасное значение

20%

Целевое значение

3%

Возможные значения

0-100%

Приоритет

3

Таблица 12

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

Свойства

Описание

Показатель

Точность планирования аналитических работ

Описание

Насколько точно было спланировано проведение аналитических работ.

Спецификация

(Затраченное время - Запланированное время)/Запланированное время

Обоснование

Повысить качество управления аналитическими работами

Аудитория

Руководство компании, руководитель проекта

Опасное значение

>0,2

Целевое значение

0,05

Возможные значения

9999

Приоритет

1

Процесс «Проектирование системы»

Показатели процесса «Проектирование системы» описаны в таблицах 13-15.

Таблица 13

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

Свойства

Описание

Показатель

Затраты на проектирование системы

Описание

Сколько стоит данный этап разработки программного продукта

Спецификация

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

Обоснование

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

Аудитория

Руководство компании, руководитель проекта

Опасное значение

50% бюджета

Целевое значение

Сделать этап экономически выгодным

Возможные значения

Теоретически не ограничены

Приоритет

2

Таблица 14

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

Свойства

Описание

Показатель

Время проектирования системы

Описание

Время, потраченное проектной командой на проектирование программного продукта

Спецификация

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

Обоснование

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

Аудитория

Руководство компании, руководитель проекта, члены проектной команды

Опасное значение

50%

Целевое значение

30%

Возможные значения

0-100%

Приоритет

1

Таблица 15

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

Свойства

Описание

Показатель

Процент измененных требований

Описание

Процент измененных требований на этапе проектирования

Спецификация

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

Обоснование

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

Аудитория

Руководитель проекта, проектная команда

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены