Не отобразилась форма расчета стоимости? Переходи по ссылке

Не отобразилась форма расчета стоимости? Переходи по ссылке

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

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

Написание диплома за 10 дней

Оглавление

Введение

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

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

3. Оценка текущих процессов в компании и разработка рекомендаций

3.1 Оценка процессов управления требованиями в реализованных проектах компании

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

Заключение

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

ПРИЛОЖЕНИЯ

Введение

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

Широко распространены ситуации, в которых устранение ошибок требований представляет собой достаточно амбициозную задачу, требующих немалых временных и финансовых усилий. Устранение ошибки в требованиях на стадии сопровождения готового программного продукта обходится, как правило, в среднем в 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% причиной провала проектов является плохое управление требованиями.

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

Требования к программному продукту, управление требованиями, управление изменениями, управление проектом, методика, методология, свод знаний, лучшие практики, 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 состоит из следующих этапов:

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

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

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

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

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

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

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

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

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

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

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

o   Совершенствование процесса инжиниринга требований.
1.2 Процессы управления требованиями в PMBOK

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

В библиотеке ITIL (IT <https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8> Infrastructure Library) работа с требованиями представлена в рамках двух процессов: Проектирование услуг (Service Design) и Преобразование услуг (Service Transition) [16]. В первом процессе описана классификация требований и инструменты для их выявления.

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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) изменения;

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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) выделяет в работе с требованиями следующие этапы:

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

·  Выявление требований (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). Включает формальные процедуры по предложению и регистрации запросов на изменения, оценки стоимости и влияния предлагаемых изменений, а также утверждение или отказ от внесенных предложений по изменениям.

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

Рисунок 7 — Процесс управления изменениями по SWEBOK 1.7 Особенности разработки заказного программного обеспечения

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

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

Таблица 1

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

 

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

Модельное значение СИ для таких матриц соответственно равно 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-продукт на рынок. Развитие продукта продолжается. Часть заказной разработки ведется на платформе данного решения.

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

Рисунок 8 — Организационная структура компании
1.11  Описание типового проекта разработки заказного программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

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

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

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

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

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

Задачи:

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

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

Выходы:

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

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

Задачи:

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

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

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

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

Выходы:

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

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

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

Задачи:

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

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

Выходы:

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

Задачи:

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

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

Выходы:

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

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

Описанные процессы схематично изображены на рисунке ниже. 1.13  Теоретические основы по разработке показателей эффективности

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

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

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

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

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

·        Своевременный − срок или точный период измерения — одна из составляющих показателя. 1.14  Состав показателей эффективности процессов управления требованиями

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

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

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

Табли

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

 

Таблица 4

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

 

Таблица 5

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

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

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

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

Таблица 6

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

 

Таблица 7

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

 

Таблица 8

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

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

Таблица 9

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

 

Таблица 10

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

 

Таблица 11

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

 

Таблица 12

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

 

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

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

Таблица 13

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

 

Таблица 14

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

 

Таблица 15

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

 

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

Процесс «Разработка прототипа системы».

Показатели процесса, связанного с разработкой прототипа системы представлены в таблицах 16-18.

Таблица 16

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

 

Таблица 17

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

 

Таблица 18

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

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

Процесс «Управление изменениями»

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

Показатели процесса «Управление изменениями» описаны в таблицах 19-24.

Таблица 19

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

 

Таблица 20

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

 

Таблица 21

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

 

Таблица 22

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

 

Таблица 23

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

 

Таблица 24

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

 

Разработанные показатели эффективности процессов представлены на рисунке ниже.

Рисунок 12 — Показатели эффективности процессов управления требованиями

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

Проект P1 — Автоматизация социальной защиты. ГБУ «Кризисный центр помощи женщинам и детям»

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

·        Ведение электронного документооборота;

·        Система ключевых показателей работы Центра в реальном времени;

·        Формирование расписания всех мероприятий клиентов и специалистов Центра;

·        Учет оказанных услуг;

·        Управление отношениями с клиентами.

Оценка процессов управления требованиями в проекте представлена в Приложении 7.

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

Исходя из показателей, много времени было потрачено на сбор требований, что в основном связано с плохой доступностью заинтересованных сторон для сбора у них требований (значение показателя превышает критический уровень). Но и количество и качество в итоге собранных требований оказалось недостаточным — покрытие предметной области всего на 70%. Качество сбора требований отразилось и на других показателях — большое количество новых выявленных требований и требований подлежащих корректировке на этапе анализа, измененных требований на этапе проектирования системы и значительное количество новых выявленных требований впоследствии.

В итоге стоимость принятых изменений оказалась экономически невыгодной. Имеются неудовлетворительные значения показателей «F5. Количество требований, потерявших актуальность» и «F6. Процент нереализованных требований».

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

Проект P2 — Автоматизация ООО Частное охранное предприятие «Русский Витязь»

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

Разработанная система позволяет:

·  Вести учет сотрудников охранного предприятия, охраняемых объектов;

·        Проводить инспекцию сотрудников и объектов;

·        Включает наглядную систему показателей эффективности работы сотрудников.

Оценка процессов управления требованиями в проекте представлена в Приложении 8.

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

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

Проект P3 — Автоматизация ООО «СПОРТФИШ ТУР»

Разработанная система управления клиентами позволяет не только эффективно взаимодействовать с клиентами:

·  Учет бронирования туров;

·        Автоматическое формирование пакета документов для оформления заказа;

·        Учет оплат и предоплат, отслеживание неоплаченных заказов;

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

·        Интеграция с сайтом.

Оценка процессов управления требованиями в проекте представлена в Приложении 9.

В ходе данного проекта значительная часть времени была потрачена на сбор требований, что в основном было обусловлено несогласованностью заинтересованных сторон в отношении требований к будущей системе. Эта несогласованность прослеживалась на всем этапе реализации проекта, что можно увидеть из значений показателей «E1. Количество замечаний, поступивших от Заказчика», «F1. Количество несогласованных требований», «F3. Количество новых выявленных требований», «F4. Стоимость выявленных изменений», «F5. Количество требований, потерявших актуальность».

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

Проект P4 — Автоматизация Российских студенческих отрядов

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

·  Создание единой информационной среды;

·        Управление работой с партнерами и заказчиками;

·        Координация работы подразделений;

·        Создание единого реестра бойцов;

·        Управление проектами и задачами;

·        Ведение электронного документооборота.

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

Оценка процессов управления требованиями в проекте представлена в Приложении 10.

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

Проект Р5 — Автоматизация открытых R&D центров — ФРИП ТПП

Было разработано приложение на базе комплекса «Простой бизнес» с возможностями социальной сети, которое позволяет:

·  Выявить потребности крупного бизнеса в области инновационного развития;

·        Управлять системой открытых R&D центров с целью применения научно-технического потенциала инновационных предприятий, ВУЗов и НИИ вне зависимости от их географического положения;

·        Наладить диалог между крупным и малым бизнесом.

Оценка процессов управления требованиями в проекте представлена в Приложении 11.

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

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

Рисунок 13 — Общая оценка процессов управления требованиями в компании

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

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

В связи с этим, для повышения качества данных процессов рекомендуется провести изменения, основанные на методологии RUP.

Для процесса «Управление изменениями» предлагается следующий алгоритм управления запросами на изменения [35], который представлен на рисунке ниже в виде диаграммы действий.

Рисунок 14 — Диаграмма действий для запроса на изменение

В Приложении 12 представлено описание задач и роли процесса управления запросами на изменения.

В компании не существует единой формы запроса на внесение изменений, поэтому предлагается использовать форму, представленную в методике RUP (Приложение 13).

Для сбора требований в компании преимущественно используется метод интервьюирования. Рекомендуется в дополнение применение метода анализа вариантов использования [36].

Предлагаемый вариант изменений в процессе сбора требований представлен в виде диаграммы действий на рисунке 15.

Рисунок 15 — Ход процесса сбора требований

Описание задач процесса сбора требований и ролей представлено в Приложении 15.

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

В компании недостаточно эффективно отлажены процессы тестирования. В связи с этим предлагается использовать активности/задачи, связанные с тестированием, предложенные в методике RUP [37]. В целом процесс тестирования представлен на рисунке ниже.

Рисунок 16 — Процесс тестирования

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

Описание задач и ролей процесса тестирования представлено в Приложении 15.

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

Рисунок 17 — Предлагаемые процессу управления требованиями

 

Заключение

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

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

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

·  Ориентация на требования Заказчика;

·        Раннее выявление и постоянное устранение рисков;

·        Постоянное обеспечение качества;

·        Готовность к изменениям в требованиях в ходе реализации проекта.

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Подробнее

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

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

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

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

 

СПИСОК ЛИТЕРАТУРЫ

1. Вигерс Карл. Разработка требований к программному обеспечению / Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2004. -576с.: ил.

2.      Леффингуэлл Дин, Уидриг Дон. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с англ. — М. : Издательский дом «Вильямс», 2002. — 448 с.:ил. — Парал. тит. англ.

3.      IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990.

4. Астелс, Дэвид; Миллер Гранвилл; Новак, Мирослав. Практическое руководство по экстремальному программированию: Пер. с англ. — М.: Издательский дом «Вильямс», 2002. — 320 с.: ил. — Парал. тит. англ.

5.      Алистер Коберн. Современные методы описания функциональных требований к системам. М.: издательство «Лори», 2002. — 263 с.

.        Мацяшек Лешек. Анализ требований и проектирование систем. Разработка информационных :с Диалектика-Вильямс.

.        Элизабет Халл, Кен Джексон, Джереми Дик. Разработка и управление требованиями. Практическое руководство пользователя. 2005.

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

.        Доминик Товассоли. Управление требованиями. Десять шагов на пути к совершенству [Электронный ресурс]

.        Новичков Александр. Роль процесса управления требованиями при разработке сложных программных систем [Электронный ресурс]

10. Роман Алфимов, Елена Золотухина, Светлана Красникова. Управление требованиями на базе стандартов [Электронный ресурс]

11. REQB® REBOK Requirements Engineering Body Of Knowledge. Version 1.0.

12.    Руководство к своду знаний по управлению проектами. Третье издание. (Руководство PMBOK).

13. Технология Rational Unified Process (IBM Rational Software) [Электронный ресурс]

14.    Филипп Крачтен. Принципы управления требованиями в Rational Unified Process.

15. Алексей Закис. RUP и другие методологии разработки ПО [Электронный ресурс]

16.    IT <https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8> Infrastructure Library. Version 3.0

17.    A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0.

.        Guide to the Software Engineering Body of Knowledge (SWEBOK). 2004 Version.

19.    Сергей Орлик, Юрий Булуй. Программная инженерия. Программные требования (Software Requirements). Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge — SWEBOK, 2004. Содержит перевод описания области знаний SWEBOK Software Requirements, с комментариями и замечаниями. 2004 — 2005.

.        Сергей Орлик. Программная инженерия. Конфигурационное управление (Software Configuration Management). Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge — SWEBOK, 2004. Содержит перевод описания области знаний SWEBOK Software Configuration Management, с комментариями и замечаниями. 2004 — 2005.

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

.        Булуй Ю.И. Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.

.        В.В. Липаев. Проектирование и производство сложных заказных программных продуктов. — М.: СИНТЕГ, 2011. — 408 с.

.        Брауде Э. Технологии разработки программного обеспечения. — СПб: Питер, 2004. — 655 с.: ил.

.        Владимир Грудинин. Разработка на заказ. Российский рынок разработки на заказ: тенденции и перспективы [Электронный ресурс]

.        Ольга Мельник. Заказное ПО: спрос растет [Электронный ресурс]

.        Тиражные приложения и заказная разработка. Преимущества для заказчика. [Электронный ресурс]

.        Т. Саати. Принятие решений. Метод анализа иерархий. Пер. с англ. — М.: «Радио и связь», 1993.

.        Петровский А.Б. Теория принятия решений — М.: Издательский центр «Академия», 2009.

.        Саати Т.Л. Decision-making with the AHP: why is the principal eigenvector necessary, European J. Oper. Res., 2003 [Электронный ресурс]

30. Брукс П. Метрики для управления ИТ-услугами; Пер. с англ. — М. Альпина Бизнес Букс, 2008.

.   Система KPI: разработка и применение показателей бизнес-процесса. Показатели эффективности [Электронный ресурс]

32.    Г.М. Шишков, С.С. Зинина. Измерение качества процесса [Электронный ресурс]

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Цена диплома

.        Антипов Д.В. Разработка модели оценочных показателей устойчивого развития организации // Вектор науки Тольятинского государственного университета. — 2010. — №4. — С. 186-189.

.        Балашова Е.С. Показатели оценки организационной эффективности бизнес-процессов / Е.С. Балашова // Научно-технические ведомости СПбГПУ. Экономические науки. — 2014. — №2 (192). — с. 185-190.

35.    Unified Change Management from Rational Software: An Activity-Based Process for Managing Change [Электронный ресурс]

36.    Определение требований как основа эффективности поставки программного обеспечения [Электронный ресурс]

.        Вячеслав Панкратов. Препарируем RUP — задачи и роли в тестировании [Электронный ресурс]

 

ПРИЛОЖЕНИЕ 1

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

ПРИЛОЖЕНИЕ 2

Сравнительный анализ методик экспертом 1

 

 

Нужна помощь в написании диплома?

Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.

Заказать диплом

ПРИЛОЖЕНИЕ 3

Сравнительный анализ методик экспертом 2

 

 

ПРИЛОЖЕНИЕ 4

Сравнительный анализ методик экспертом 3

Средняя оценка 0 / 5. Количество оценок: 0

Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

588

Закажите такую же работу

Не отобразилась форма расчета стоимости? Переходи по ссылке

Не отобразилась форма расчета стоимости? Переходи по ссылке