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

Если требование удалено из какой-то версии ТЗ/SRS, причину этого удаления тоже следует указать в СУТ.

Это может, например, быть использовано в процессе разработки для определения приоритетов требования, определяя, насколько ценно требование для конкретного пользователя. Его также можно использовать после развертывания, когда пользовательские исследования показывают, что функция не используется, чтобы понять, почему она потребовалась в первую очередь. Состав документов, оформляемых для выделенных этапов ЖЦ системы, приведен в таблице 2. Часть документов, создаваемых и сопровождаемых при управлении требованиями, определена в соответствии с ГОСТ, а часть готовится по специальным шаблонам, которые разработаны непосредственно авторами методики и созданы на основе обобщения работ [1-3, 5].

Ценность для бизнеса

Такая структура позволяет размеру моглашения об уровне услуги оставаться в управляемых пределах, предупреждает
ненужное дублирование и снижает потребность в частых обновлениях. Однако это предполагает дополнительные усилия для
поддержания целостности связей в каталоге услуг и в системе управления
конфигурациями. Соглашении об уровне услуги (service level agreement, SLA) – cоглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ- услуг и заказчика. Одно соглашение об уровне услуг может распространяться на множество ИТ-услуг или множество заказчиков. Таким образом, если изменение попадает в категорию стандартных, то оно должно управляться в рамках процесса
управления запросами на обслуживание.

• Требования исходят из различных источников, таких как представитель бизнеса, заказывающий продукт, менеджер по маркетингу или фактический пользователь.
• Однако собрать на ранних стадиях все необходимые данные удается только в исключительных случаях, так как заказчик не всегда способен оценить все нюансы и особенности предстоящей работы в новой системе.
• Логичным шагом могла бы стать интеграция репозитория требований с соответствующими UML-моделями, и RequisitePro поддерживает интеграцию со средствами моделирования (IBM Rational XDE и Rose)…
• Кроме того, необходимо обеспечить сквозные процессы разработки изделия в многодисциплинарной среде, позволив специалистам из разных областей слаженно действовать в поисках инженерных решений.
• Иногда они представляются в виде хронологических этапов, хотя на практике эти виды деятельности в значительной степени переплетаются.

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

Деятельность в рамках процесса управления инцидентами

Сразу следует обратить внимание, что данная схема не является абсолютной истиной и должна дорабатываться (корректироваться) под конкретную организацию. Можно перемещать разные компоненты (блоки) между категориями (группами), удалять, добавлять новые. Но предложенные подходы являются универсальными и применимы для широкого круга задач. В статье рассмотрим структуру (Рис. 1) данной системы и приведём большое количество примеров многих её компонентов. Эта структура показывает, какой полный набор моделей и документов в идеале должен иметь современный ИТ-департамент средней и крупной организации (многих отраслей, особенно самых высокотехнологичных). Как правило, подробные описания возможностей или поведения требуются только для того, чтобы обеспечить переход от текущего состояния предприятия к желаемому будущему состоянию, но после этого это больше не потребуется.

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

Жизненный цикл требования: состояния и процессы

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

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

Управление требованиями на базе стандартов

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

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

Процесс управления инцидентами

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

Похожие темы научных работ по экономике и бизнесу , автор научной работы — Кравченко Т. К.

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